Процесор запитів Microsoft SQL Server. Частина 2, Інші СУБД, Бази даних, статті

2. Внутрізапросний паралелізм


На відміну від межзапросного паралелізму ([14]), що означає одночасне виконання різних запитів на декількох потоках (threads) операційної системи, внутрізапросний (intraquery) паралелізм був реалізований в SQL Server 7.0 вперше. Внутрізапросний паралелізм, як випливає з його назви, є можливість розпаралелювання процесу обробки одного запиту по декількох потоків, що дозволяє ефективно використовувати багатопроцесорні архітектури при обробці складних запитів. Використання внутрізапросного паралелізму не вимагає спеціального розбиття даних при їх зберіганні, а також внесення будь-яких змін в їх структуру або текст запиту. Процесор запитів розглядає паралелізм поряд з іншими етапами стратегії побудови оптимального плану. Основними критеріями при прийнятті рішення про паралельно виконання запиту виступають кількість активних користувачів, доступна пам'ять і можливий обсяг даних, що обробляються запитом. Очевидно, що паралельне виконання простого запиту за порівняно малій кількості записів невигідно, тому що зажадає більше пам'яті, ніж послідовне. При цьому доводиться забирати потоки, які в іншому випадку могли б бути використані для підтримки більшої числа користувачів. Загальне правило можна сформулювати так: в OLTP-системах, що характеризуються великою кількістю користувачів, які обстрілюють SQL Server численними короткими транзакціями, він буде віддавати перевагу послідовним планам, витрачаючи потоковий пул (див. опцію max worker threads) на користувальницькі з'єднання. У OLAP-додатках, для яких, навпаки, характерні масивні довгограючі транзакції, а число користувачів відносно невелике, процесор запитів вдасться до паралельним планам. Наприклад, запит
select * from sales_fact_1997 union select * from sales_fact_1998 (Кількість записів у таблиці, як ми пам'ятаємо, 86837) виконується за таким планом:

/-Parallelism(Gather Streams)

/-Hash Match(Union)

/-Parallelism(Repartition Streams, PARTITIONCOLUMNS:

(Sales_fact_1997.product_id, sales_fact_1997.time_id, sales_fact_1997.customer_id,

sales_fact_1997.promotion_id, sales_fact_1997.store_id, sales_fact_1997.store_sales,

sales_fact_1997.store_

/ /-Table Scan(FoodMart..sales_fact_1997)

/-Sort (DISTINCT ORDER BY: (sales_fact_1998.product_id asc, sales_fact_1998.time_id asc,

sales_fact_1998.customer_id asc, sales_fact_1998.promotion_id asc,

sales_fact_1998.store_id asc, sales_fact_1998.store_sales asc,

sales_fact_1998.store_cos

/-Parallelism (Repartition Streams, PARTITIONCOLUMNS: (sales_fact_1998.product_id,

sales_fact_1998.time_id, sales_fact_1998.customer_id, sales_fact_1998.promotion_id,

sales_fact_1998.store_id, sales_fact_1998.store_sales, sales_fact_1998.s

/-Table Scan(FoodMart..sales_fact_1998)

Ліст.2.1


Паралельне виконання запиту досягається введенням в план спеціальних операторів паралелізму, до яких відносяться Distribute (зробити розбиття даних на кілька потоків (streams)), Gather (зібрати результати обробки даних c попередніх кроків на декількох потоках) і Repartition (перерозподілити дані за потоками). Запити на оновлення (UPDATE / INSERT / DELETE) виконуються послідовно, проте подчітка даних у них може здійснюватися в паралельному режимі. Специфіка динамічних курсорів припускає строго послідовний план виконання. У той же час для заповнення статичних і keyset-курсорів може використовуватися межзапросний паралелізм.


У змішаних додатках може виникнути необхідність провести кількісну грань між поняттями простого й складного запиту. Це робиться за допомогою конфігураційного параметра cost threshold for parallelism, який характеризує порогову вартість запиту, починаючи з якої оптимізатор починає розглядати можливість використання паралельного плану виконання. Запити, чия вартість не перевищує порогової величини, завжди будуть виконуватися послідовно. Значення цієї опції за замовчуванням дорівнює 5. Її також можна модифікувати з меню Server Properties (закладка Processor) в SQL Enterprise Manager.


Ключовим поняттям паралельного виконання є ступінь паралелізму (Degree of Parallelism, або DOP), іншими словами, кількість процесорів, які будуть задіяні для одночасної обробки запиту. Зазначимо, що ефект внутрізапросного паралелізму буде проявлятися тільки на машинах, де для роботи SQL Server відведено два і більше процесорів (див. опцію affinity mask ([1])). Для налаштування DOP використовується конфігураційний параметр max degree of parallelism, який може приймати значення від 0 до 32: 1 забороняє внутрізапросний паралелізм, 0 (за умовчанням) означає, що при побудові паралельних планів процесор запитів буде використовувати максимально доступне на даний момент число процесорів. Кількість потоків, на яких починається виконання запиту в паралельному режимі запит, залишається незмінним до моменту його закінчення. Разом з тим, необхідно мати на увазі, що оптимальний план може змінюватися в залежності від конфігурації і завантаження SQL Server, так що той же самий запит через деякий час може виконуватися з іншого DOP, зокрема, послідовно. Перегляд DOP здійснюється за допомогою відповідного підкласу події в SQL Profiler.


Поряд зі звичайними потоками SQL Server 7.0 має можливість використовувати волокна (fibers) Windows NT – особливий вид легковагих потоків, з яких може складатися thread. Легковажність полягає в особливостях планування (scheduling). Переключення між потоками вимагає переходу в режим ядра операційної системи, що само по собі є досить дорогою операцією, в той час як перемикання волокон відбувається в контексті програми. SQL Server використовує волокна замість потоків, якщо конфігураційний параметр lightweight pooling встановлений в 1.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*