Аналитические массивно-параллельные СУБД предназначены для хранения и обработки больших объемов данных, исчисляемых сотнями терабайт, и обычно используются в приложениях прогнозной аналитики, для формирования регулярной отчетности, анализа оттока клиентов и построения корпоративных хранилищ. Для построения корпоративных хранилищ и систем анализа больших данных давно используется СУБД Greenplum Database — это решение взяли на вооружение NYSE, NASDAQ, Boeing, At&T, Sony и еще около тысячи компаний, включая «Тинькофф», Sberbank CIB и «Ростелеком». Однако обычно речь шла о закрытых коммерческих решениях для состоятельных корпоративных заказчиков.

Открытие исходного кода GPDB запустило процесс демократизации аналитических массивно-параллельных СУБД. В частности, это позволило компании Arenadata начать открытый проект Arenadata DB (ADB) по созданию реляционной СУБД с массово-параллельной архитектурой без разделения ресурсов (Shared Nothing), предназначенной для хранения, обработки и анализа больших объемов структурированных и слабоструктурированных данных. Используя вычислительную мощность сотен серверов, усовершенствованный оптимизатор запросов и гибкую систему резервирования данных, ADB позволяет повысить производительность и надежность обработки, сохраняя унаследованным приложениям ANSI SQL, в частности полностью поддерживаемым в СУБД PostgreSQL, доступ к данным.

Архитектура ADB представляет собой классический кластер: несколько серверов-сегментов, один сервер-мастер и один резервный, соединенные между собой быстрыми (10-Gigabit Ethernet или Infiniband) сетями (рис. 1). Каждый сервер-сегмент содержит несколько сегментов («инстансов») PostgreSQL, содержащих данные. В случае отказа одного или нескольких сегментов они помечаются как сбойные и вместо них запускаются их зеркальные сегменты, репликация данных для которых происходит с помощью используемой в СУБД PostgreSQL технологии опережающей записи (Wright Ahead Log, WAL — все изменения таблиц и индексов записываются в файл только после их занесения в журнал).

Открытая аналитическая СУБД
Рис.1. Архитектура ADB

Использование нескольких интерконнектов позволяет повысить пропускную способность канала взаимодействия сегментов между собой и обеспечить отказоустойчивость кластера за счет перераспределения трафика. Распределение сегментов по сетевым интерфейсам выбирается индивидуально и может подстраиваться под задачи кластера: например, все основные сегменты можно заставить использовать один сетевой интерфейс, а резервные сегменты будут использовать второй.

В ADB реализуется классическая схема разделения («шардирования») данных — каждая таблица состоит из N таблиц, размещаемых на N сегментах кластера. Логика разбиения таблицы на сегменты задается ключом (полем) дистрибуции. Для каждой отдельной колонки в таблице можно задать свой тип и уровень сжатия. Помимо изначально доступных в Greenplum типов компрессии — zlib (одна из наиболее популярных библиотек сжатия) и RLE delta compression (хранение изменений между значениями полей в колонке), в ADB доступен алгоритм zstandard, разработанный компанией Facebook и обеспечивающий вчетверо более высокую производительность по сравнению с zlib.

В ADB используется полиморфное хранение данных: например, одну таблицу можно разделить на вертикальные разделы (партиции), часть из которых будет храниться в виде строк, а часть...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF