Производительность запросов к хранилищу данных SQL Server 2008 - Параллелизм секционированных таблиц

 

Параллелизм секционированных таблиц

Чтобы ускорить обработку запросов в больших хранилищах данных, администраторы часто секционируют большие таблицы фактов по дате. Данные разделяются на группы файлов, уменьшая объем данных, который нужно просмотреть при обработке строк в определенном диапазоне; также это позволяет одновременно использовать производительность подлежащей дисковой системы, когда группы фалов расположены на многих физических дисках.

В SQL Server 2005 была добавлена возможность секционировать большие соотношения на меньшие логические фрагменты, чтобы улучшить управление и администрирование больших таблиц. Это также успешно применялось для улучшения обработки запросов, особенно в больших приложениях поддержки решений.

К сожалению, некоторые клиенты, использующие SQL Server 2005, столкнулись с проблемами производительности, особенно при работе на многопроцессорных компьютерах с параллельной совместно используемой памятью. При обработке параллельных запросов на секционированных таблицах в SQL Server 2005, может возникать ситуация, при которой только часть доступных потоков используется для выполнения запросов.

Возьмем 64-разрядный комьютер, где запросы могут использовать до 64 потоков одновременно. Запрос при этом затрагивает две секции. В SQL Server 2005 он получит только 2 из 64 потоков, используя, таким образом, только 2/64 (3.1 процента) мощности ЦП компьютера. Для некоторых запросов сообщалось о десятикратном ухудшении производительности при секционировании по сравнению с выполнением того же запроса на том же компьютере на несекционированной версии той же таблицы фактов.

Следует отметить, что SQL Server 2005 был оптимизирован для работы с запросами, затрагивающими одну секцию. В этом случае процессор запросов передаст все доступные потоки для выполнения сканирования. Эта особая оптимизация привела к значительному увеличению производительности односекционных запросов на многоядерных компьютерах, поэтому клиенты, естесственно, ожидали того же от запросов, затрагивающих несколько секций.

Новая функция в SQL Server 2008, параллелизм секционированных таблиц (PTP), улучшает производительность запросов в случае секционирования, лучше используя вычислительные мощности имеющегося оборудования, независимо от того, сколько секций затрагивает запрос, или каков относительный размер отдельных секций. В типичном случае хранилища данных с секционированной таблицей фактов, пользователи смогут заметить значительное улучшение запросов, выполняющихся параллельно, особенно если количество доступных ядер процессора больше числа секций, затрагиваемых запросом. И эта новая функция работает сразу, без дополнительной настройки или изменений.

Пусть у нас есть таблица фактов, представляющая данные продаж, разделенные по дате продажи на четыре секции. Представить себе это поможет диаграмма на рис. 5. Заметьте, что вместо одного кластеризованного индекса для всего диапазона данных, как в случе без секционирования, обычно есть кластеризованный индекс в столбце данных для каждой секции таблицы фактов. Предположим, что запрос Q суммирует продажи за последние семь дней. Так как новые данные о продажах постоянно добавляются в таблицу фактов через последнюю секцию (обозначенную как P4), запрос будет затрагивать различные секции, в зависимости от того, когда он выполняется. Это показано в первом ряду диаграммы, где запрос Q1 затрагивает только одну секцию, а запрос Q2 -- две, так как соответствующие данные во время выполнения находятся в секциях P3 и P4.

Рис 5 Новыя функция PTP в работе

Теперь предположим, что доступно восемь потоков. Выполнение Q1 и Q2 под SQL Server 2005 может привести к неожиданному поведению. SQL Server 2005 устроен так, что оптимизатор знает во время компиляции, что запросом будет затронута только одна секция, что секция будет считаться одной несекционированной таблицей и что будет создан план, получающий доступ к таблице через все имеющиеся потоки.

В результате для Q1, затрагивающего одну секцию (P3), возникнет план, обрабатывающийся восемью потоками (не показано на рисунке). В случае Q2, который затрагивает две секции, исполнитель передает каждой секции по одному потоку, даже если оборудование имеет дополнительные свободные потоки. Поэтому Q2 будет использовать только малую часть мощности ЦП и наверняка будет выполняться значительно медленнее, чем Q1.

При выполнении Q1 и Q2 под SQL Server 2008 доступное оборудование будет использоваться полнее, что обеспечит лучшую производительность и предсказуемое поведение. В случае Q1, исполнитель снова передает все восемь доступных потоков обработке данных в P2 (не показано на рисунке). Q2, тем временем, вызовет параллельный план, в котором исполнитель передаст все доступные потоки и P3 и P4 циклическим способом, эффект чего можно видеть в нижнем ряду диаграммы, где обе секции получают по четыре потока. ЦП занять полностью, а производительность Q1 и Q2 сравнима.

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

Выигрыш в производительности SQL Server 2008 по сравнению с SQL Server 2005 для случая многоядерного компьютера проиллюстрирован еще на рис. 6. Этот характерный график демонстрирует производительность сканирования для секционированных таблиц. Для этого теста, который проводился в системе с 64 ядрами и 256 ГБ оперативной памяти, мы разделили одну таблицу размером 121 ГБ на 11 секций по 11 ГБ. Для набора тестов на этом рисунке мы организовали файлы в структуру сортирующего дерева, как с холодным, так и с горячим запуском. Все запросы производят простые сканирования данных.

Рис 6 Производительность сканирования для SQL Server при включении новой функции PTP 

По оси ординат отложено время (в секундах), а по оси абсцисс – степень параллелизма (DOP), которая аналогична количеству потоков, отданных запросу. Можно видеть, что и при горячем, и при холодном запусках время отклика уменьшается до тех пор, пока DOP не достигнет 22. В этот момент для случая холодного запуска насыщается система ввода-вывода. Это связано с тем, что запрос в этом примере зависим от ввода-вывода. Для более ЦП-ориентированных нагрузок это ограничение может не наступить или наступить при более высокой DOP.

Кривая, представляющая случай горячего запуска, тем не менее, продолжает показывать уменьшение времени отклика с увеличением уровня DOP. В SQL Server 2005 обе кривые начали бы падать примерно на DOP 11, потому что при работе с несколькими секциями количество потоков на секцию было бы ограничено 1.

Важно отметить, что на практике уменьшение времени отклика при увеличении числа DOP не бывает линейным. Ожидаемое поведение скорее напоминает пошаговое движение, потому что запрос ждет самой медленной части. Например, если добавить еще один поток к сканированию, общее время не уменьшится, если только не добавиь по потоку к остальным сканированиям, чтобы они тоже могли ускориться.

Мы провели дополнительные эксперименты, чтобы проверить поведение PTP для других конфигураций оборудования и файлов. При этом мы отметили сходное поведение – увеличение пропускной способности при уровне DOP большем, чем один поток на секцию.

Наконец, что немаловажно, новая функция PTP в SQL Server 2008 улучшает удобочитаемость планов запросов и позволяет лучше понять выполнение некоторых рабочих нагрузок. Например, благодаря функции PTP, улучшилось то, как представлены в Showplan XML параллельные и серийные планы, также усовершенствовано предоставление информации о секционировании для планов при компиляции и планов при выполнении.