Partilhar via

Построение индексов – Часть 4.

  • Artigo

????????????, ?????????? ?????????? ??????????????????? ??????? (Offline, Parallel, No Partitioning).

?????????? 3 ???????? ????????? ?????????? ?????? ?????????? ???????:

1) ???????????? ??????????????? (??? ????? ????? ????????);

2) ???????????? ??????????????? (??? ?????????????????????? ?????);

3) ???? ??? ?????????????? ????????????? ??? ????????? (No histogram Indexed view).

???????????? ???????????????* (??? ????? ????? ????????).

?????????? ???????????? ???? ?????????? ??????? ??? ????? ????? ???????? ????? ??????????? ????????? ???????:

      X

                     /                |                \

???????????… ??????????? …  ??????????? …  

                   |                  |                 |

??????????… ?????????? …  ?????????? …

                    \                 |                /

       ???????????? (??? ??????? ??????????? (worker))

???? ???? ????????????? ?????????? ???????? ?????????? ???????????? ???????? ????? ??????????? ????????? ???????:

1) ??????? ???????????? (DOP – Degree of parallelism) – ????? ???????????, ??????? ????? ???? ????????????? ??? ?????????? ??????? < 8

??? DOP > 8, ?? ?????? ????????? ??? ????????? ??????? ????????? ???????????? % ????? ????????? ??????????? ???????? ?????? (??. ? ???????? ????? - ???????????? ??????????????? (??? ?????????????????????? ?????));

2) ???????? ?????????? (? ?????-??, ??? ??????, ????? ???????????????? ?????????????, ???? ??????????? ???????? ??????????; ???? ??? ?? ?????????? ?? ?????? ???????? ???????, ??? ????? ?????????????).

????????? ????????? ?????????? ?????????? ???????? ???????????? ?????? ?? N ?????????, ??? N = DOP * 3. ???? ????????? ????? ????? ??? ??????? ???????? ????? ????? ??????? ?? DOP ?????? ????? ????????????? – ?? ????? ?????? ?? ??????????? (??? ???????? ??? ???????????? ????????). ????????? ?????????? ???????????? ?????? ??????????? ???????? ?????? ????????????? ? ??? ??????, ???? ??? ????? ? ?????????? ??????????? ??? ?????? ??? ??????? ???????????, ?.?., ????, ????????, DOP = 4, ??? ??????? ????? ?????????????? 4 ????.

?????? ??????????? ?????? ???? ??????????? ?????? ????????? ?????? ????? ??????, ????? ??????? ?????? ??????????? ????? ????? ???? ??????????? ????????????? ????????? ??????????.

????? ?????????? ???????? ?????? ????????????, ?????????????? ??????? ???????????? «??????» ???? ???????? ? ????? ?????? ???????. ????? «??????» ???????????? ?????? ?????????? ??? ?????? ??????? ? ??????? ???????????.

* ?? ???????, ??????????, «???????????? ??????????????? (Range partition)» - ??? ????????????? ????? ?????????? ??????? ? «???????????????? ?????? (Partitioned Index)» - ??? ???????.

? ????????? ??????????:

- ???????????? ??????????????? (??? ?????????????????????? ?????);

- ???? ??? ?????????????? ?????????????;

- ?????????? ? ?????? ??? ??????????? ?????????? ????????;

...

Comments

  • Anonymous
    January 01, 2003
    Еще один вопрос касается упомянутой ранее  предварительной сортировки. Это "полноценная" сортировка в классическом понимании, или грубая сортировка, т.е. разбиение элементов на группы (сегменты, кластеры и т.п.)

  • Anonymous
    January 01, 2003
    Что понимается под "для машин малой мощности"? Насколько малой мощности?

  • Anonymous
    January 01, 2003
    >> Определенно меньше, чем в два (для двух исполнителей). Дык...

  • Anonymous
    January 01, 2003
    По ряду причин время предварительной сортировки соизмеримо со временем построения дерева индекса, а иногда и может значительно превышать его. Таким образом, сократив время сортировки или избавившись от нее, можно увеличить скорость построения индекса в два и более раз. В каких случаях сортировка не приносит ощутимого эффекта? Ну, например, когда затрагиваемая часть дерева индекса целиком умещается в кеше. Еонечно, при этом увеличивается фрагментация индекса, но 100%-заполнение имеет смысл только для необновляемых баз данных, а случайное обновление индекса уже дает 75% заполнения. На практике размер дерева индекса значительно превышает размер кеша, но и здесь остаются пути для повышения эффективности за счет упрощения сортировки. Предположим, в индексе хранятся текстовые строки в алфавитном порядке, и в кеше помещается не все дерево индекса, а только его часть, которая содержит строки, начинающиеся на букву "А" ("Б", "В", и т.д.). Кстати, что значит "...если она не существует на момент создания индекса, она будет сгенерирована"? На основе каких данных выполняется генерация?

  • Anonymous
    January 01, 2003
    Скажите, пожалуйста о каких объемах данных идет речь. Так как промежуточные результаты надо хранить на диске, то, вероятно это десятки мегабайт и более. Но могут ли это быть гигабайты?

  • Anonymous
    January 01, 2003
    Давно не заходила в свой журнал - не было времени. А тут уже столько вопросов  По порядку... [Что понимается под "для машин малой мощности"?] В данном случае - < 8 процессоров либо - >= 8 процессоров, но недостаточно памяти (построение индекса может потребовать >3% достпной обработчику запросов памяти). [Скажите, пожалуйста о каких объемах данных идет речь. Так как промежуточные результаты надо хранить на диске, то, вероятно это десятки мегабайт и более. Но могут ли это быть гигабайты?] Могут быть и гигабайты. Зависит от Вашего конкретного индекса. Размер индекс можно очень грубо представить как размер ключа*число строк. Более подробно можно почитать здесь (на английском):  ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/c183b0e4-ef4c-4bfc-8575-5ac219c25b0a.htm и здесь: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/2b5137f8-98ad-46b5-9aae-4c980259bf8d.htm По-русски эти статьи имеются в online документации к русскому SQL Server -у 2005. [какой примерно размер кеша в ОП используется при построении дерева индекса?] Зависит от того, сколько может выделить внутренний (SQL Server-ный) распределитель памяти. Исполнитель запросов всегда постарается запросить памяти достаточно для проведения сортировки в памяти целиком, но это, на самом деле скорее редкий случай, когда индекс действительно маленький. Распределитель памяти будет учитывать остальные исполняющиеся в это время процессы и общий размер памяти. Здесь только стоит помнить, что если распределитель памяти не сможет выделить для процесса построения индекс 40 страниц (3200Kb), то Create Index вернет ошибку - 40 страниц это абсолютный минимум, который необходим даже для построения индекса меньшего размера. [Это "полноценная" сортировка в классическом понимании] Да, полноценная сортировка. По поводу предварительной сортировки против построения дерева из неотсортированных данных… Добавление случайных (неотсортированных) данных в btree требует поиска по дереву при каждом добавлении – это, в общем, далеко не оптимальное решение. [Предположим, в индексе хранятся текстовые строки в алфавитном порядке, и в кеше помещается не все дерево индекса, а только его часть, которая содержит строки, начинающиеся на букву "А" ("Б", "В", и т.д.)] Вы здесь говорите о уже существующем индексе? Я не совсем поняла. Как эти строки попали в индекс в алфавитном порядке? [Кстати, что значит "...если она не существует на момент создания индекса, она будет сгенерирована"? На основе каких данных выполняется генерация?] Если у нас нет статистики, то перед началом построения индекса мы строим т.н. выборочную статистику, а в процессе построения строим полную,  параллельно с построением самого индекса.

  • Anonymous
    January 01, 2003
    Выше я имел в виду объем данных, идущих в индекс. Второй вопрос: какой примерно размер кеша в ОП используется при построении дерева индекса?

  • Anonymous
    January 01, 2003
    Интересно узнать ответы еще на такие вопросы:

  • Всегда ли число исполнителей равно числу просессоРов?

  • Запускаются ли несколько исполнителей в однопроцессорной системе?

  • Приведите, пожалуйста грубую оценку: во сколько раз сокращается время построения индекса если вместо одного исполнителя работают два (три) исполнителя?

  • Сколько процентов от общего времени уходит на каждый из этапов: сканирование / сортировка / построение / слияние? Заранее спасибо.

  • Anonymous
    January 01, 2003
    В предыдущем посте я забыл поставить знак вопроса :) Обсуждаемая тема интересует меня потому, что мне приходиться заниматься решением аналогичных задач для словарной базы данных в своем shareware-проекте ( http://www.jardicpro.com ). Пытаюсь достичь скорости построения полнотекстового индекса равной 1,000,000 строк в минуту на 1.6 Мгц процессоре (индекс с ключам переменой длины, Unicode collation, сжатие страниц индекса, суммарный объем индексов - 1-15 млн элементов).

  • Anonymous
    January 01, 2003
    >>Неоптимальным этот процесс окажется в случае вынужденных обращений к диску. Да, именно. А это и есть наиболее частый случай. Те случаи, когда мы можем провести сортировку в памяти, как правило, не нуждаются в дополнительной оптимизации - выполняются достаточно быстро. Узкое место - построени больших (и относительно больших) индексов, когда обращений к диску не избежать. >>Всегда ли число исполнителей равно числу просессоРов Не всегда. См. мой сегодняшний пост про параллельное построение индексов; плюс - при гиперсрединге число исполнителей может быть больше числа физических процессоров (не очень рекомендуемый путь). >>Приведите, пожалуйста грубую оценку: во сколько раз сокращается время построения индекса если вместо одного исполнителя работают два (три) исполнителя? Не готова так сходу ответить. Определенно меньше, чем в два (для двух исполнителей). >>Сколько процентов от общего времени уходит на каждый из этапов: сканирование / сортировка / построение / слияние? Очень зависит от типа построения индекса (я еще буду об этом писать в дальнейшем).

  • Anonymous
    January 01, 2003
    >> Добавление случайных (неотсортированных) данных в btree требует поиска по дереву при каждом добавлении – это, в общем, далеко не оптимальное решение. Поиск в дереве выполняется быстрее чем, соответствующая сортировка, т.к. дерево уже построено и потребуется даже не N*LogN, а просто LogN операций. Неоптимальным этот процесс окажется в случае вынужденных обращений к диску. ========== Итак, предположим, что в кеше помещается (поместится) часть дерева индекса, которая содержит строки, начинающиеся на букву "А" ("Б", "В" и т.д.). Тогда достаточно сортировать исходные строки только по первой букве, т.к. если мы подадим на вход сразу все строки, начинающиеся с буквы "А", то кеш будет использоваться эффективно (без обращений к диску) и вставка соответствующего блока строк в индекс может занять даже меньшее количество времени, чем полная сортировка этого блока строк (опять же, потому, что дерево уже частично построено в явном виде). Собственно, я хотел в общих чертах упомянуть о возможных способах оптимизации. Описанный выше метод можно переформулировать, заменив фразу "на букву А" фразой "1000 ключей" и т.п. Хотел узнать, используется ли у вас что-то подобное и применить это у себя ;) Спасибо.