Автор: Curt Monash
Дата публикации оригинала: 2007-10-23
Источник: Блог Курта Монаша

Один из наиболее долгоживущих технологических споров, о которых я знаю, это спор приверженцев нормализованных хранилищ данных с приверженцами кубов, схем «звезда» (star schema) и «снежинка» (snowflake schema). Teradata, например, является флагманом первого лагеря; Microstrategy уверенно относится к последнему. (Однако это не удерживает множество розничных компаний от работы на Microstrategy поверх машин Teradata.) Attensity (хороший партнёр Teradata) принадлежит к первому лагерю; соперник по text mining компания Clarabridge (вроде бы, отпочковавшийся от Microstrategy) относится к последнему. И так далее.

Vertica также явно принадлежит к лагерю схем звезда/снежинка. Я спросил их об этом, и CTO компании Vertica Майк Стоунбрейкер (Mike Stonebraker) прислал мне ответ по email. Я привожу его ниже с лёгкими исправлениями, выделение также моё. Ключевые положения включают:

  • Почти все (кого видит Vertica) хотят звёзды и снежинки, поэтому для них Vertica и делает оптимизацию.
  • Репликация маленьких таблиц измерений по узлам замечательно сказывается на производительности.
  • И несмотря на это, Vertica также расширяет поддержку более общих схем.

Замечательный вопрос. Об этом мы много думали и провели серьёзные исследования на эту тему с большими корпоративными клиентами. … вот короткий ответ:

Vertica поддерживает схемы звезда и снежинка, поскольку они являются желательными структурами для хранилищ данных. Подавляющее большинство схем, с которыми мы встречаемся имеют эту форму, и мы сильно оптимизированы для этого случая.

Это включает горизонтальное секционирование таблицы фактов и реплицирование таблиц измерений. Это позволяет генерировать планы запросов с максимальным параллелизмом и минимальным временем выполнения.

Иногда бывают и схемы, которые не являются схемами снежинка. Например, один клиент настоял на том, чтобы Vertica работала со схемой, которую они использовали для своего текущего строкового хранилища. Для того чтобы повысить производительность строкового хранения, им пришлось разбить свою таблицу фактов пополам,* и пользоваться тем, что мы называем схемой “усач”, и они не хотели прилагать усилия для изменения дизайна. Очевидно, в строковых СУБД не надо платить за «толстые» таблицы фактов. Соответственно, клудж клиента был характерен для строкового хранения. Тем не менее, они захотели оставить свою существующую схему.

*Прим. ред.: Я полагаю, что это означает, что разные столбцы хранились в разных таблицах, а не то, что были разделены строки. Иначе, это не имело бы смысла.

По этой причине, мы теперь расширяем движок Vertica, и включаем поддержку схем не-звезда/снежинка, и предоставим эту функциональность через несколько месяцев.

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

В соответствии с тем, что говорят наши клиенты, цель – это намного лучшая производительность на схемах звезда/снежинка, а это то, что Vertica предоставляет.

Ссылки на статьи Курта по следующим категориям (на английском языке):
Analytic technologies, Columnar database management, Data models and architecture, Data warehousing, Theory and architecture, Vertica Systems


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

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