Автор: Константин Лисянский

Продолжая серию знакомств с “альтернативными” технологиями для хранилищ данных (DWH), я решил посмотреть на СУБД Vertica Analytical Database компании Vertica Systems. Вашему вниманию предлагаются основные моменты, которые я почерпнул из документов, предоставленных компанией.

Общая информация

Компания Vertica Systems является производителем колоночной СУБД (columnar database) для хранилищ данных. Одним из основателей компании является Майк Стоунбрейкер (Stonebraker), что уже говорит о многом. Информация о продукте доступна на сайте компании. Прототипом для коммерческой СУБД Vertica послужила академическая СУБД C-Store, которая разрабатывалась под руководством Стоунбрейкера.

Продукт можно причислить к классу software only, но, как и в случае с другими вендорами этого класса, Vertica в партнёрстве с HP и Red Hat предлагают комплекс для хранилищ данных (data warehouse appliance). Помимо этого, Vertica в партнёрстве с Amazon предлагает свою СУБД в режиме cloud computing.

Gartner позиционирует Vertica как нишевого игрока.

Документацию по продукту мне пока почитать не удалось (оказалось, что для знакомства с ней требуется подписание соглашения о неразглашении информации, что не имеет смысла, поскольку моё намерение заключается именно в её разглашении). Тем не менее, я ознакомился с большим количеством материалов и почитал блог отцов-основателей Vertica.

Технология

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

Основные технологические моменты, на которых делает акцент производитель:

  • высокая производительность на аналитических запросах за счёт хранения данных по столбцам и сильной компрессии (data compression), а также за счёт избыточности данных (data redundancy)
  • масштабируемость (scalability) за счёт архитектуры MPP
  • загрузка данных с одновременным выполнением запросов
  • возможность загружать данные в режиме trickle feed (за счёт использования промежуточных буферов в памяти)
  • высокая надёжность без избыточности оборудования (за счёт большой избыточности данных, компенсируемой их сжатием)
  • программноое обеспечение работает на общедоступном оборудовании и масштабируется добавлением опять-таки недорогого оборудования
  • автоматический дизайн базы данных (physical database design) - честно говоря, я пока не до конца понял, что под этим имеется в виду, разберусь попозже

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

Заявляется поддержка загрузки данных в режиме, близком к реальному времени (trickle feed), являющейся одним из типов смешанной нагрузки (mixed workload) в хранилищах данных. Достигается это созданием специальных буферов в памяти, куда поступают загружаемые данные. Время от времени накопившиеся данные переписываются в статические структуры на диске. Очевидно, при такой организации для обеспечения отказоустойчивости необходимо хранить копии загружаемых в реальном времени данных на других узлах системы. Оптимизатор (query optimizer) также должен уметь работать с двумя типами структур данных.

Что касается оптимизатора, то информация о нём в документах весьма скудная (возможно, в каких-то публикациях освещаются вопросы построения оптимизаторов для клоночных СУБД, но я их пока не нашёл). Очевидно, что одной из задач оптимизатора в случае Vertica является выбор правильно отсортированной проекции (индекса) для фильтрации и выполнения соединений. Видимо, массовый параллелизм не так критичен, как в случае со строковыми СУБД, однако, мне кажется на больших объёмах данных, оптимизатор, всё-таки, должен уметь правильно распараллеливать запросы. В документах упоминается, что Vertica разработана для работы со схемой “звезда” (star schema). Очевидно, оптимизатор ещё не так продвинут, чтобы работать с более сложными структурами.

В то время, как Greenplum и Aster Data пропагандируют поддержку MapReduce как одно из ключевых преимуществ для аналитических СУБД, создатели Vertica считают MapReduce большим шагом назад. Здесь и здесь приводится их агрументация.

Позиционирование

Vertica позиционируется как высокопроизводительная аналитическая СУБД с высокой надёжностью. Довольно большой упор делается на поддержку cloud computing как новой модели использования приложений.

Помимо позиционирования как реляционной СУБД для хранилищ данных, Vertica позиционируется также для поддержки семантического веба (semantic web) и RDF. Статью на эту тему можно почитать здесь.

Стоимость

Точной информации о стоимости найти мне не удалось. Вот, что пишет Gartner:

СУБД недорограя, модель ценообразования основана на количестве данных, извлекаемых из систем-источников, не зависит от количества пользователей, серверов, процессоров или ядер

Как я уже писал, компания имеет предложение для cloud computing. На момент написания статьи они предлагают начальную стоимость аренды (по специальному предложению) 500 долларов в месяц.

Клиенты

На момент написания этой статьи в разделе “Клиенты” на сайте Vertica числится довольно много компаний. Gartner пишет, что их у компании около 60, отмечая, что Vertica достаточно быстро набирает клиентскую базу.

Заключение

Более близкое знакомство с колоночными СУБД на примере Vertica показало, что это интересная и, несомненно, перспективная технология (о чём также свидетельствует появление достаточно большого количества стартапов на эту тему). У меня появилась вот такая мысль - некоторые производители (например, Oracle) добавляют поддержку OLAP прямо в ядро базы данных. Не возникало ли у кого-то идеи добавить вместо OLAP колоночную СУБД в добавок к строковой чтобы совместить преимущества и того и другого способа хранения данных?

У меня появилось желание посмотреть и на продукты других производителей колоночных СУБД. Что, скорее всего, я и сделаю в ближайшее время.

Между тем, напомню, что колоночным СУБД на нашем сайте посвящена отдельная категория.


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

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