Масштабируемость очереди

Оценить
(0 голоса)

Если вы намерены развернуть огромную базу данных DSS в большой SMP-системе либо с DB2, либо с XPS, то, вероятно, придется решать, что более эффективно: логические узлы с разделенными данными или один узел с единственным образом данных. Абсолютного ответа на этот вопрос не существует; эффективность параллелизма очередей в каждом случае будет во многом зависеть от оптимизатора.

Главные задачи оптимизатора - минимизировать время выполнения очереди, а также минимизировать активность процессора и диска, необходимых для выполнения очереди. Если предположить, что оптимизатор выбирает рациональный план, масштабируемость будет зависеть от следующих факторов:

•             Степень параллелизма, до которой может быть доведена каждая фаза плана очереди.

•             Содержимое, на которое практически можно будет разделить задание между процессорами и дисками, включенными в выполнение плана очереди. Представьте себе обработку вех имен телефонного справочника: на субагента или поток, с трудом продирающийся сквозь "Smiths", будет возложено больше, чем на субагента или поток, работающий с "Entwhistles" (редкая фамилия).

•             Вероятность своевременной доставки необходимых данных и индексных страниц субагентам или потокам.

•             Размещение узкого места производительности. В данном контексте узкое место - это компонент системы, ограничивающий производительность по причине его 100% занятости в то время, как остальные компоненты системы простаивают или относительно простаивают.

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

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

Однако, забудьте о пари, если выполняете объединения многочисленных таблиц. Намного сложнее предсказать как масштабируемость очереди при добавлении вами процессоров, так и степень параллелизма различных фаз очереди. Наш тест производительности БД на платформе Sun, не предусматривающей совместное использование, предполагает, однако, что параллелизм внутри одного логического узла недостаточно хорошо масштабируется при более чем 8-12 процессоров, в то время как масштабируемость параллелизма через узлы может быть расширена далеко за эти пределы. С другой стороны, сложные многотабличные объединения на множестве логических узлов могут включать другой процесс - перемещение данных между разделами - задачу, не являющуюся необходимой для единственного образа данных. Перемещение данных описано в разделе "Системы МРР" текущей главы.

Делить на разделы или нет?
Архитектура аппаратных средств и базы данных
SMP-системы
Системы NUMA
Системы МРР

Добавить комментарий


Защитный код
Обновить