Архитектура Greengage DB

Мастер (master) — это единая точка доступа ко всем базам данных кластера Greengage DB. Он является единственной точкой подключения клиентов: все запросы, управление объектами базы данных и административные операции выполняются через мастер.

Мастер представляет собой экземпляр PostgreSQL, который хранит метаданные кластера Greengage DB, включая системные каталоги и встроенные административные схемы. Эти метаданные описывают конфигурацию кластера, структуру и свойства пользовательских объектов. Когда пользователь создает таблицу, мастер фиксирует информацию о ней: структуру данных, права доступа, распределение, схему партиционирования и другие атрибуты. Сами данные хранятся на сегментах.

Мастер выполняет следующие основные функции:

Резервный мастер (standby master) — это запасной узел, который может заменить основной мастер в случае сбоя. Этот компонент является опциональным, но настоятельно рекомендуется для production-кластеров во избежание простоя при отказе мастера. Для отказоустойчивости резервный мастер должен работать на отдельном хосте, чтобы один аппаратный сбой не затронул оба экземпляра.

Когда в кластере есть резервный мастер, Greengage DB непрерывно синхронизирует его с основным мастером с помощью репликации журнала предзаписи (Write-Ahead Log, WAL). Реплицируется только каталог данных мастера; сегменты в процессе не участвуют. Таким образом, резервный мастер хранит актуальную копию системного каталога и состояния метаданных мастера.

Переключение на резервный мастер при сбое выполняется вручную администратором в соответствии с регламентами восстановления. После активации резервный мастер применяет операции, записанные в WAL, восстанавливает состояние системного каталога и принимает роль основного мастера. Подробнее о переключении мастера см. Восстановление мастера после сбоев.

Сегменты (segment) хранят пользовательские данные в кластере Greengage DB. Каждый сегмент — независимый экземпляр PostgreSQL, который хранит часть данных каждой таблицы и участвует в выполнении запросов. Сегменты взаимодействуют с мастером и друг с другом, когда выполнение запроса требует перераспределения данных или межсегментных операций.

Сегменты работают на сегментных хостах кластера. На одном сегментном хосте могут работать несколько сегментов, обычно от 2 до 8 в зависимости от аппаратных ресурсов и операционных требований.

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

Сегменты бывают двух типов:

Если основной сегмент выходит из строя, его зеркало автоматически принимает на себя нагрузку, обеспечивая доступность данных. Подробнее см. Проверка и восстановление сегментов.

Зеркальные сегменты работают на сегмент-хостах кластера и располагаются на разных хостах с соответствующими основными сегментами. В этом случае один аппаратный сбой одного хоста не выведет их из строя одновременно. Точное расположение зеркал на сегмент-хостах определяется используемой в кластере политикой зеркалирования: group или spread. При включенном зеркалировании каждый сегмент данных хранится на двух разных хостах. Следовательно, кластер должен включать четное число сегмент-хостов для сбалансированной загрузки.

Когда мастер получает SQL-запрос от клиента, он формирует распределенный план выполнения, используя метаданные о распределении данных. Затем он передает части плана сегментам. Каждый сегмент выполняет назначенные шаги с помощью собственного процесса-исполнителя запросов (Query Executor, QE). Некоторые операции могут требовать обмена данными между сегментами. Такой обмен выполняется с помощью операции перемещения данных (motion). После выполнения сегменты возвращают промежуточные или финальные результаты мастеру.

Производительность кластера определяется параллельным выполнением на сегментах. Система работает лучше всего, когда:

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

Интерконнект (interconnect) — это сетевой слой, обеспечивающий обмен данными между сегментами во время выполнения запросов. Он используется для операций, таких как перераспределение, широковещательная передача (broadcasting) и объединение промежуточных результатов.

Для поддержки распределенного выполнения необходима сеть с высокой пропускной способностью и низкой задержкой. Рекомендуется использовать сеть минимум 10 Гбит/с; для нагрузок с интенсивным обменом данными рекомендуются сети 25 или 100 Гбит/с.

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

Каждый экземпляр — мастер и сегменты — хранит свои данные локально, используя файловую структуру PostgreSQL. Это включает:

Модель shared-nothing подразумевает, что сегменты не используют общие диски или другие хранилища. Все операции ввода-вывода — сканирование таблиц, поиск по индексам, запись WAL и другие — выполняются локально на каждом сегмент-хосте. Такая изоляция обеспечивает горизонтальное масштабирование, но требует аккуратного распределения данных, чтобы избежать дисбаланса хранилища.

Greengage DB использует такую же реляционную модель данных, что и PostgreSQL, с иерархией объектов: база данных, схема, таблица и столбец. В этой иерархии базы данных, схемы и столбцы не отличаются от модели данных PostgreSQL. На уровне таблиц Greengage DB расширяет модель данных для поддержки распределенного хранения и параллельного выполнения запросов:

Greengage DB поддерживает синтаксис SQL, совместимый с PostgreSQL. Поддерживаются стандартные конструкции DDL, DML и запросов, включая:

Некоторые функции реализованы иначе для поддержки распределенного хранения. Например, последовательные сканирования выполняются параллельно на всех сегментах, а часть операций требует перераспределения данных через интерконнект. Тем не менее в большинстве случаев пользователи могут писать запросы так же, как в PostgreSQL.

Многие административные функции PostgreSQL доступны в Greengage DB. Однако они модифицированы таким образом, чтобы выполняться на всех экземплярах кластера согласованно. Примеры: