Blogs

Построение индексов – часть 6: построение секционированного индекса (Продолжение - Параллельное построение)

  • Comments 2
  • Likes

Параллельное построение выровненных секционированных индексов 

 

В случае параллельного построения индекса, сканирование и сортировка секций осуществляется параллельно и реальное число промежуточных структур сортировки существующих одновременно зависит от числа исполнителей работающих одновременно. Секции выбираются для сканирования и сортировки одна за другой и, когда один исполнитель заканчивает работу с очередной секцией, он выбирает следующую секцию, еще не взятую ни одним исполнителе��. Каждый исполнитель, таким образом, строит 0 – N секций (одна секция не может быть распределена между несколькими исполнителями).  Почему может быть 0? Если  DOP (уровень параллелизма) > числа секций,  то не все исполнители получат секцию для работы над ней. Над какой секцией будет работать определенный исполнитель?  Это не детерминистическое решение.

Так как одна секция не может быть распределена между несколькими исполнителями, то самая большая секция становится «узким местом» в построении индекса. Возможна ситуация, когда все исполнители, кроме одного, закончили работу со своими секциями, а один продолжает сортировать самую большую секцию. Это значит, что ресурсы, задействованные в этом запросе (память и потоки) не будут доступны для других запросов, пока последний исполнитель не закончит свою работу.

 

Для построения секционированного индекса не нужна финальная «сшивка»  - каждая секция таково индекса существует как отдельное b-дерево.

 

Как это влияет на требования к свободному дисковому пространству:

-         В случае сортировки в пользовательской базе данных (установка по умолчанию) требования такие же, как и в случае последовательного построения (см. предыдущий пост).

-         В случае сортировки в tempdb (SORT_IN_TEMPDB = ON) мы не получим того же преимущества в использовании дискового пространства как в случае последовательного построения, так как несколько промежуточных структур сортировки могут существовать одновременно. Кроме того, так как распределение данных между секциями изначально не известно, считаем, что нам может потребоваться все те же 2.2*(Размер индекса) свободного дискового пространства в tempdb.

 

Некоторые соображения об использовании памяти:

 

Так как в одно и тоже время существует несколько промежуточных структура сортировки (реальное количество, существующих одновременно, структур будет зависеть от #DOP (уровня параллелизма) и количества секций), и каждая структура требует 40 страниц памяти, чтобы начать построение индекса, минимальная необходимая память составит - #DOP*40страниц.

Общее объем памяти = минимально требуемая память + дополнительная память.

 

* дополнительная память высчитывается как размер строки умноженный на  предполагаемое количество строк, предоставленное оптимизатором запросов.

 

Читайте в следующих постах о построении не выровненного секционированного индекса J

Comments
  • А что представляют собой исполнители? Я имею в виду "Каждый исполнитель, таким образом, строит 0 – N секций (одна секция не может быть распределена между несколькими исполнителями).". Может я что-то упустил. Спасибо, очень интересно.

  • Worker (worker thread) – процесс - в общем случае может рассматриваться как обычный Windows процесс.

    В случае если включена опция lightweight pooling – так называемый облегченный процесс, который требует меньше ресурсов, чем обычный Windows процесс.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment