Архитектура ADB
Arenadata DB (ADB) — это база данных, реализующая подход массивно-параллельной архитектуры (Massively Parallel Processing, MPP), основанная на Greengage DB.
В основе архитектуры MPP — кластер, состоящий из узлов, работающих одновременно. В ADB это реализовано как кластер отдельных экземпляров базы данных PostgreSQL.
ADB использует подход shared-nothing, при котором каждый сегмент содержит свою часть данных. Несколько сегментов могут работать на одном хосте, но обрабатывают свои данные независимо. Система масштабируется горизонтально — путем добавления новых физических хостов в кластер.
ADB состоит из трех ключевых компонентов:
Мастер
Мастер (master) — это точка входа в базу данных. Пользователи подключаются к мастеру для отправки запросов.
В число функций мастера входят:
-
Аутентификация клиентских подключений. Мастер управляет доступом к системе, используя стандартный файл pg_hba.conf. Сегменты принимают клиентские SQL-подключения только от мастера.
-
Парсинг запросов. Мастер проверяет SQL-запрос на корректность синтаксиса. ADB использует синтаксис PostgreSQL с некоторыми изменениями, которые сделаны для поддержки распределенной архитектуры.
-
Оптимизация. Оптимизатор определяет наиболее эффективный способ выполнения SQL-запроса, оценивая потенциальные планы выполнения запроса (query plan) и выбирая план с наименьшей расчетной стоимостью.
-
Координирование. Мастер распределяет рабочую нагрузку между обработчиками запросов на всех сегментах.
-
Получение результатов. Мастер собирает результаты, сформированные сегментами (отфильтрованные строки, агрегированные значения или объединенные данные) и возвращает итоговый результат клиенту.
-
Административные функции. Помимо собственно обработки запросов, мастер осуществляет управление и обслуживание баз данных. Например, он обновляет системные каталоги после получения DDL-команд (таких как
CREATE TABLE).
Мастер не хранит пользовательские данные; они размещаются только на сегментах.
Мастер хранит глобальный системный каталог (в виде таблиц pg_database, pg_authid и т.п.), который содержит метаданные о самой базе данных, ее структуре и свойствах пользовательских данных.
Когда пользователь создает таблицу, мастер сохраняет информацию о ее схеме, владельце и типе распределения, а фактическое содержимое таблицы хранится на сегментах.
Резервный мастер
Резервный мастер (standby master) выполняет функции теплого резерва: он поддерживается в актуальном состоянии и готов к включению, но не обрабатывает запросы, пока не будет активирован. Хотя резервный мастер является опциональным, он крайне рекомендуется к использованию.
При отказе основного мастера резервный мастер не становится основным автоматически — действие по переключению должен выполнить администратор кластера. Вы можете использовать действие Activate Standby, доступное в веб-интерфейсе Arenadata Cluster Manager (ADCM).
Целостность и восстановление данных обеспечиваются механизмом write-ahead logging (WAL), унаследованным от PostgreSQL. WAL гарантирует, что все изменения данных сначала записываются в журнал WAL и сохраняются в постоянное хранилище до фактической модификации данных на диске. Это обеспечивает восстановление базы данных даже после сбоя путем повторного применения записей WAL.
Сегменты
Сегмент (segment) — это экземпляр PostgreSQL, хранящий и обрабатывающий свою часть данных. ADB распределяет пользовательские данные между сегментами на основе ключа распределения (distribution key), выбранного при создании таблицы. Равномерное распределение данных и рабочей нагрузки по сегментам — ключевое условие для достижения максимальной производительности ADB.
|
РЕКОМЕНДАЦИЯ
Рекомендуется, чтобы все хосты сегментов имели идентичные аппаратные ресурсы и конфигурации. Это связано с тем, что мастер агрегирует результаты только после завершения работы всеми сегментами. Следовательно, производительность ADB будет определяться скоростью самого медленного хоста сегментов в кластере. Если один сегмент работает значительно медленнее остальных, это задержит выполнение всего запроса. |
Основные сегменты
Основные сегменты (primary segment) — это активные сегменты, которые хранят пользовательские данные, получают планы запросов и реализуют их. Они выполняют локальные SQL-операции только со своей частью данных и отправляют результаты мастеру.
Зеркальные сегменты
Зеркальные сегменты (mirror segment) обеспечивают отказоустойчивость для основных сегментов. При недоступности основного сегмента система автоматически переключается на его зеркальный сегмент. Зеркальный сегмент начинает функционировать как основной сегмент, а недоступный сегмент становится зеркальным сегментом. Администратор должен восстановить недоступный сегмент и вернуть сегменты в их исходные (preferred) роли.
Зеркальный сегмент всегда должен размещаться на отдельном от соответствующего основного сегмента хосте. Существует две конфигурации зеркалирования:
Групповое зеркалирование
При групповом зеркалировании (group mirroring) все зеркальные сегменты основных сегментов одного хоста размещаются вместе на другом хосте.
На рисунке, приведенном ниже, сегменты Primary 0 и Primary 1 располагаются на хосте Segment host 1, а их зеркальные сегменты Mirror 0 и Mirror 1 располагаются на хосте Segment host 2.
Основные свойства группового зеркалирования:
-
Это наиболее дешевый вариант конфигурации, так как он может быть осуществлен с помощью всего двух хостов.
-
В случае отказа такая конфигурация приводит к неравномерной нагрузке на хосты. Если один хост становится недоступным, его резервный хост получает двойную нагрузку, так как помимо собственных основных сегментов (
Primary 2иPrimary 3на рисунке ниже) его зеркальные сегменты (Mirror 0иMirror 1) тоже начинают работать в режиме основных сегментов. Производительность хоста снижается на 50% и более.
Распределенное зеркалирование
При распределенном зеркалировании (spread mirroring) зеркальные сегменты для основных сегментов каждого хоста размещаются на разных резервных хостах — по количеству сегментов на хост.
На рисунке ниже сегменты Primary 0 и Primary 1 находятся на хосте Segment host 1, а их зеркальные сегменты распределены по разным хостам: Mirror 0 на Segment host 2, а Mirror 1 на Segment host 3.
Основные свойства распределенного зеркалирования:
-
Повышенная отказоустойчивость. Сбой хоста приводит к активации только одного зеркального сегмента на каждом другом хосте, что снижает влияние на производительность. В примере на рисунке ниже если
Segment host 1становится недоступным, на хостеSegment host 2активируется сегментMirror 0, а на хостеSegment host 3активируется сегментMirror 1. Нагрузка на каждый хост возрастает на 50%, при этом эта дополнительная нагрузка равномерно распределяется между хостами. -
Более высокая стоимость. Такая конфигурация требует, чтобы количество хостов было как минимум на один больше, чем количество сегментов на одном хосте.
Интерконнект
Интерконнект — это высокоскоростная сеть, обеспечивающая обмен данными между сегментами во время выполнения запросов. Рекомендуется использовать сеть 10 Гбит/с или быстрее.
Большинство запросов в базе данных выполняются параллельно на всех сегментах и требуют перемещения данных (data motion) между сегментами. Для такого перемещения данных используется интерконнект. Медленный интерконнект может привести к задержке в выполнении всего запроса.
Интерконнект не требуется для запросов, выполняемых на одном сегменте (targeted query), особенно в случае если запрос отфильтрован по ключу распределения и все необходимые данные находятся на одном сегменте.
По умолчанию в качестве протокола интерконнекта используется User Datagram Protocol with flow control (UDPIFC).
Вы можете выбрать тип интерконнекта (udpifc, tcp или proxy) в конфигурационных параметрах ADB.
Использование ADB для ETL
Для выполнения процессов ETL (Extract, Transform, Load) можно использовать выделенные серверы вне кластера ADB.
Внешние серверы могут подключаться к кластеру через стандартные протоколы: ODBC, JDBC или libpq.
Для передачи больших объемов данных используйте утилиту gpfdist, реализующую File Distribution Protocol.
Ее можно запускать непосредственно на ETL-серверах, где размещены внешние файлы.
Такая архитектура гарантирует, что ETL-операции и собственно SQL-запросы в кластере не конкурируют за ресурсы.
Чтобы загрузить данные с помощью gpfdist, создайте внешнюю таблицу с указанием gpfdist в качестве источника. При выборке данных с помощью такой таблицы сегменты подключаются напрямую к gpfdist и параллельно загружают данные.
Данные не проходят через мастер, он только координирует процесс.
Интеграция с другими системами
Для интеграции с разнообразными источниками и форматами данных ADB использует Platform Extension Framework (PXF) и специализированные коннекторы.
PXF — это фреймворк доступа к данным, позволяющий выполнять запросы напрямую к внешним системам.
Он позволяет выполнять федеративные запросы (federated queries), при которых можно получать и объединять данные из разных источников в одном запросе.
PXF также поддерживает технологию pushdown, позволяющую передать фильтрацию данных для условия WHERE внешним источникам. Такой подход снижает объем данных, которые в итоге передаются в ADB.
PXF обеспечивает работу с такими форматами данных, как Avro, OCF, CSV, Text, ORC и JSON.
На основе PXF разрабатываются коннекторы для подключения и передачи данных между кластером и отдельными внешними системами (такими, как файловые хранилища, базы данных и потоковые платформы).
Встроенные в PXF коннекторы поддерживают интеграцию с Oracle Database, S3, HBase, Hadoop, HDFS, Hive и JDBC-источниками. В Enterprise-версии ADB доступны дополнительные коннекторы: ADB ClickHouse Connector, ADB to Kafka Connector и Kafka to ADB Connector, ADB Spark 3 Connector и ADB to ADB Connector.
Кроме того, для дополнения возможностей базы данных ADB предоставляет расширения SQL, например PostGIS для поддержки географических объектов или plpgsql для поддержки языка PL/pgSQL. Полный список доступных расширений приводится в статье Поддерживаемые расширения.
Дополнительные инструменты по управлению кластером
В составе ADB Enterprise доступны также следующие компоненты для администрирования кластера:
-
Arenadata DB Control (ADB Control) — система мониторинга, позволяющая в режиме реального времени проводить мониторинг SQL-операций и транзакций, сессий, ресурсных групп, системных метрик и т.д.
-
Arenadata DB Backup Manager (ADBM) — отказоустойчивая система для управления бинарными бэкапами ADB.