§ Postgres-XC: Кластеризованый постгрес

Postgres-XC - read/write-scalable multi-master symmetric cluster based on PostgreSQL.

Postgres-XC представляет собой PostgreSQL  кластер, внутри которого обеспечивается возможность горизонтального масштабирования, сохраняя при этом синхронную симметричность размещения данных и прозрачность доступа к данным для приложений. Кластер представляет собой набор тесно связанных компонентов базы данных которые могут быть установлены как на один сервер так и на несколько серверов. 

Возможность масштабирования означает, что Postgres-XC может быть настроен для предоставления большей производительности чем может обработать один сервер. Производительность наращивается путем добавления новых серверов. При добавлении новых узлов, возможна (при определенных условиях) почти линейная масштабируемость по чтению и по записи. 

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

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

Кластер Postgres-XC можно запустить на нескольких серверах, которые будут хранить данные в распределенном виде, т.е. таблицы могут быть распределены или реплицированы в зависимости от нашего выбора. При выполнении запроса, Postgres-XC самостоятельно определяет где находятся необходимые данные и отправляет запросы на сервера с данными.

Цели Postgres-XC.

Конечная цель проекта предоставить синхронный мульти-мастер кластер PostgreSQL с возможностью read/write масштабирования. Таким образом Postgres-XC предоставляет следующие возможности:

• Postgres-XC способен предоставлять несколько серверов способных принимать транзакции и запросы от клиентских приложений, которые будут представлять собой "мастер" сервера;
• Postgres-XC должен предоставлять больше одного т.н. "мастера";
• Любой "мастер" должен в любой момент времени отображать консистентное  представление данных (вцелом по кластеру). Любое изменение данных на одном из мастеров должно быть видимо в реальном времени как будто бы это сделано на единичном сервере PostgreSQL;
• Postgres-XC предоставляет совместимый PostgreSQL API для клиентских приложений;
• Postgres-XC должен предоставлять единое и унифицированное представление низлежащих PostgreSQL серверов таким образом чтобы выполнение SQL запросов не зависело от того как и где размещены данные.

Архитектурные особенности.

Как было сказано выше, Postgres-XC представляет собой набор тесно связанных компонентов:

Глобальный менеджер транзакций (GTM) - компонент предоставляющий контроль над видимостью данных и непротиворечивое управление транзакциями. За счет менеджера транзакций обеспечивается соблюдение ACID в распределенной среде.

Координатор - предоставляет собой интерфейс взаимодействия клиентских приложений с базой данных. Координатор не хранит в себе каких-либо данных. Координатор принимает SQL запросы, при необходимости запрашивает идентификатор транзакции (Global Transaction Id - GXID) и глобальный снимок (Global Snapshot), определяет на каком узле лежат необходимые данные и запрашивает выполнение запроса (или его части) на этом узле. При выполнении запроса на узле данных, запрос всегда ассоциируется с GXID и глобальным снимком, таким образом узел данных может выполнять запросы от разных координаторов. Приложение подключившееся к любому из координаторов всегда видит одинаковое (между всеми координаторами) и целостное представление данных.

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

Для обеспечения транзакционной целостности между нодами используется механизм two-phase commit, что предъявляет высокие требования к сети передачи данных. Данные в кластере можно хранить двумя способами. Первый вариант это репликация - когда таблица хранится на всех узлах кластера. И второй вариант - распределение, когда таблица разбивается на части по отдельным серверам.

Учитывая роли узлов в кластере (GTM, Coordinator, Datanode), наилучшим способом реализации будет отдельное размещение каждого компонента на отдельном сервере. Выход любого узла из строя никак не должен влиять на общую работу кластера. Тем не менее, нормальным вариантом является размещение координатора и узла данных на одном сервере, т.к. нет необходимости балансировать нагрузку между ними. Можно иметь любое количество серверов на которых запущены два этих компонента. Но учитывая что оба компонента в сущности являются простыми постгрес базами данных PostgreSQL, следует настроить их таким образом чтобы не было конфликта за ресурсы (shared memory). Также следует отметить что они должны работать в разных рабочих директориях и на разных портах.

Postgres-XC не исключает возможности работы нескольких координаторов, которые в свою очередь принимают запросы от приложений. Любое изменение в данных в любом координаторе, становится видимым другими координаторами. Таким образом они выступают как единая база данных. Роль координатора сводится к тому чтобы принять запрос, определить нужные узлы с данными, при необходимости декомпозировать запрос для каждой из нод с данными, спроксировать запрос на узел с данными, собрать результаты и отдать их обратно в приложение (этакий MapReduce). Координатор не хранит каких-либо важных данных. Координатор лишь хранит метаданные в виде каталога с информацией которые необходимы для декомпозиции запроса и определении целевых узлов с нужными данными. Таким образом выход координатора из строя не является серьезной аварией. В случае падения координатора можно переключиться на другой координатор и продолжить работу.

Единой точкой отказа (SPOF) в кластере может быть менеджер транзакций GTM. Для резервирования менеджера транзакций следует запустить еще один менеджер в Stand-by режиме. В случае краха основного менеджера, его роль может взять на себя запасной менеджер. Если же в кластере участвует GTM-Proxy, то переключение на запасного менеджера может осуществляться с помощью него.

Хранение данных.

Postgres-XC предоставляет две возможности хранения данных:
Распределенные (Distributed) таблицы: Содержимое таблиц распределяется между указанными узлами или группами узлов по определенной стратегии распределения (HASH, MODULO, ROUND-ROBIN). Каждая запись распределенной таблицы хранится только на одном узле кластера. Множество записей могут быть добавлены или изменены на нескольких узлах в параллельном режиме, также можно и читать данные параллельно с нескольких узлов. По заявлению разработчиков, такой подход значительно увеличивает производительность. 

Реплицируемые (Replicated) таблицы: Таблица реплицируется на указанное число узлов используя репликацию на уровне запросов (statement-level), которая в данном случае лучше чем репликация на основе WAL-журналов, поскольку объем передаваемых журналов, гораздо больше чем размер запроса. В случае реплицируемой таблицы, данные в таблице находятся на каждом из узлов куда реплицируется таблица. Любое изменение, дублируется в каждую реплицируемую копию. Таким образом, все данные в таблице, доступны как бы с одного узла, координатор может взять все необходимые ему данные с одного узла, и в некоторых случаях может выступать в качестве прокси между приложением и узлом данных. Также такой способ позволяет направить множественные запросы на разные узлы и тем самым сбалансировать нагрузку и увеличить пропускную способность по чтению.

Надежность.
Множество подсистем подразумевают множество точек отказа, в случае Postgres-XC с самого начала предусматривается дублирование всех компонентов (GTM + GTM Stand-by; несколько координаторов, несколько узлов с данными). Тем более что узлы с данными и координаторы представляют собой слегка измененный PostgreSQL и там доступна потоковая репликация для обеспечения избыточности.

Обеспечение высокой доступности (High-Availability).
Для достижения высокой доступности требуется избыточность данных, избыточность компонентов и автоматическое переключение в случае сбоя. В Posxtgres-XC избыточность данных можно достигнуть с помощью потоковой репликации и Stand-by узлов, доступных в обычной поставке PostgreSQL. Так как координатор является мастером (с точки зрения что лишь он способен делать запись) и может мгновенно читать запись выполненную с других координаторов, то каждый координатор способен заменить собой любой другой координатор вышедший из строя. Менеджер транзакций GTM дублируется таким компонентом как GTM-Standby. Однако для автоматического переключения всех компонентов, требуется сторонний инструмент.

Оценка производительности.
Начальная оценка производительности выполненная с помощью DBT-1 тестирования показывает значительную масштабируемость производительности при добавлении новых узлов.

Заключение.
Postgres-XC является расширением оригинального PostgreSQL и наследует большинство его возможностей: позволяет работать со сложными запросами, поддерживаются внешние ключи (с некоторыми ограничениями), доступны представления (views). Также как и PostgreSQL, в Postgres-XC можно добавлять свои типы данных, функции и операторы, агрегатные функции и индексные методы, процедурные языки.

Существующие ограничения на текущий момент (v1.0.2):

• не поддерживаются триггеры*;
• нет удобной системы перераспределения данных при изменении числа узлов с данными*;
• нет глобальных UNIQUE на распределенных таблицах;
• не поддерживаются курсоры*;
• не поддерживаются внешние ключи между таблицами на разных узлах;
• не поддерживается INSERT .. RETURNING*;
• невозможно изменение числа узлов без полной реинициализации кластера*.

* - поддержка заявлена в версии 1.1 (примерная дата релиза - май 2013)

Официальная страница проекта Postgres-XC

На главную "Virtualizing Linux"