Автор: Curt Monash
Дата публикации оригинала: 2008-09-05
Перевод: Олег Кузьменко
Источник: Блог Курта Монаша

Я общаюсь со многими поставщиками СУБД, которые созданы для систем с массивно-параллельной обработкой (MPP-системы) и которые используются для построения хранилищ данных. Мне рассказали о весьма разных подходах к реализации архитектуры MPP, и мне кажется, что было бы интересным сравнить некоторые из них.

В базовом варианте архитектуры таких СУБД имеются два типа узлов:

  • Узел-«босс», который отвечает за:
    • Получение и разбор запросов
    • Оптимизацию запросов, генерацию планов выполнения, и отсылку планов узлам системы
    • Получение результатов и их отсылку пользователю/приложению
  • Узлы-«работники», которые делают свою работу по выполнению запроса и затем отсылают данные «боссу»

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

Решения, предлагаемые компаниями Vertica и Exasol, являются исключением по отношению к базовому варианту, описанному выше. В их системах на всех узлах выполняется одинаковое программное обеспечение. Другой крайностью являются те поставщики, которые используют выделенные узлы для специальных задач. Например, компания Aster Data известна тем, что в ее системах есть специальные узлы для массовой загрузки и выгрузки данных. Компания Greenplum на логическом уровне разделяет узлы на те, что выполняют запросы, и те, что общаются с системой хранения. Greenplum рассматривает возможность предложения в будущем релизе опции по физическому разделению таких узлов.

Основной компромисс между этими схемами заключается в следующем:

  • Если имеется больше разновидностей выделенных узлов, то труднее осуществлять балансировку нагрузки в реальном времени; больше вероятность того, что некоторые узлы будут простаивать.
  • Если имеется больше разновидностей выделенных узлов, то вы можете добиться более оптимальной конфигурации аппаратного обеспечения путем использования различных вариантов «железа» для различных типов узлов. Потенциально, это является более значительным фактором в том случае, если какие разновидности узлов имеют выделенные диски, а какие-то нет.

Система компании Calpont, которая пока еще в действительности не поставила ни одной СУБД, имеет интересную особенность. Calpont создает СУБД с хранением данных по столбцам, в которой работа по выполнению запроса разделена между узлом-«работником», который обрабатывает запрос, и узлом, который работает с системой хранения и который общается с дисками. Эти узлы не связаны жестко между собой отношением «один к одному»; любой узел-«работник» может общаться с любым узлом, отвечающим за систему хранения. Компания Calpont считает, что в будущем какая-то часть логики, выполняемая узлами, общающимися с системой хранения, может мигрировать в сами системы хранения, почти подобно той стратегии, которой следует Netezza, но с использованием более стандартного оборудования.

На самом деле, такое решение может иметь больше смысла для сетей хранения данных (storage area networks) с разделяемыми дисками, чем для MPP-систем без разделения ресурсов, но это тема для другого поста.

Ссылки на статьи Курта по следующим категориям (на английском языке):
Aster Data, Calpont, Exasol, Greenplum, Parallelization, Theory and architecture, Vertica Systems


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: