Доклад на PGDay в рамках конференции Highload

1. Postgresql XC
Что это и с чем его есть.
Maxim.Boguk@PostgreSQL-Consulting.com

2. Что такое Postgresql-XC
• Решение для кластеризации PostgreSQL с
возможностью наращивания
производительности путем добавления
новых серверов.
• Поддержка автоматического прозрачного
шардинга данных на несколько серверов.
• Честный ACID и честные транзакции в
распределенной среде.

3. Что такое Postgresql-XC
• До разумного количества нод – возможна
(при определенных условиях) почти
линейная масштабируемость и по чтению и
по записи.
• Возможно построение высокодоступных
(high-available) конфигураций
• Некоторые запросы могут выполнятся
частично параллельно.

4. Чем не является PostgreSQL-XC
• Хоть Postgresql-XC и выглядит похожим на
MultiMaster он им не является. Все сервера
кластера должны быть соединены сетью с
минимальными задержками (читай
воткнуты в один switch), никакое
географически-распределенное решение с
разумной производительностью построить
на нем не возможно (это важный момент).

5. Масштабируемость
Результаты DBT-1
Производительность
Количество серверов

6. Архитектура (упрощенно)

7. Где взять и какие есть версии?
Официальный сайт:
http://postgres-xc.sourceforge.net/
Последняя доступная версия:
1.0.1 на основе Postgresql 9.1.5 (выпущена в
сентябре 2012)
Версия в разработке:
1.1 на основе PostgreSQL 9.2 (ожидается в мае 2013)

8. Минимальная конфигурация:
• Минимальная конфигурация PostgreSQL-XC
содержит 4 независимых подсистем
(администрировать это все достаточно
весело): 2 сервиса с данными, сервис-
координатор, GTM (global transaction
manager).
• В принципе это все можно завести на 2
физических серверах или виртуалках.

9. Как это выглядит?

10. Транзакции и ACID
• Приложение присоденившееся к любому из
координаторов видит одинаковое (между
всеми координаторами) и целостное
представление данных.
• Честный ACID без необходимости вносить
правки в приложение.
• Единые snapshots и видимость транзакций
обеспечиваются специальным отдельным
приложением GTM.

11. А как же печальноизвестная CAP
теорема?
• PostgreSQL-XC попадает в CA угол этого
треугольника. Таким образом всегда есть
согласованность данных и доступность (HA
требует дополнительной настройки но в
целом возможен). В общем как и любое
другое кластерное решение для
классических баз данных.

12. Обеспечение транзакционой
целостности между нодами.
• Для обеспечения транзакционной
целостности операций затрагивающих
более одной ноды – используется
классический механизм 2PC (two-phase
commit).
• После сбоя для разбора ситуации с 2PC есть
специальная утилита pgxc_clean для
приведения кластера в согласованное
состояние.

13. Распределение данных в кластере
• Два в общем то стандартных варианта:
таблица целиком хранися на всех базах
кластера или шардинг (про это потом
подробнее)
• Так как PostgreSQL-XC умеет проводить joins
прямо на нодах с данными таблицы с
которым часто идут Joins лучше
реплицировать целиком.

14. Шардинг. В каких случаях?
• Таблицы логов (завершенные операции,
посещения)
• Таблицы с временными данными
(например корзина заказа в интернет
магазине)
• Пользователи и их данные (шардинг по id
пользователя).

15. Синтаксис шардинга:
• CREATE TABLE tab (…) DISTRIBUTE BY
HASH(col) | MODULO(col) | REPLICATE
Просто и удобно.
На практике – надо очень внимательно
думать о том как делать так как переделывать
большую таблицу на другой режим шардинга
до 1.1 очень неудобно.

16. Что не надо шардить?
• Таблицы-справочники и прочие глобальные
данные с которыми постоянно
производятся Joins (join большого обьема
данных с таблицей разбитой на нескольких
нодах будет весьма неэффективен).
• В общем то любые статические или
редкоизменяемые таблицы с большим
потоком чтения.

17. План простого запроса:
CREATE TABLE tab1 (val int, val2 int)
DISTRIBUTE BY REPLICATION TO NODE datanode_1, datanode_2;
-- полная копия данных на обоих нодах
EXPLAIN VERBOSE SELECT * FROM tab1 WHERE val2 = 5;
-- Решаем где выполнять запрос
-> Data Node Scan on tab1
Output: val, val2
-- выбрали одну из нод
Node/s: datanode_1
Remote query: SELECT val, val2 FROM ONLY tab1 WHERE (val2 = 5)

18. План простого запроса v2:
CREATE TABLE tab1 (val int, val2 int)
DISTRIBUTE BY HASH(val) TO NODE datanode_1, datanode_2;
-- таблица раскидана на 2 ноды
EXPLAIN VERBOSE SELECT * FROM tab1 WHERE val2 = 5;
-- поиск по всем нодам
-> Data Node Scan on "__REMOTE_FQS_QUERY__«
Output: tab1.val, tab1.val2
-- собираем данные со всех нод
Node/s: datanode_1, datanode_2
-- операции на всех нодах идут параллельно!
Remote query: SELECT val, val2 FROM tab1 WHERE (val2 = 5)

19. Подсчет агрегата sum():
CREATE TABLE tab1 (val int, val2 int)
DISTRIBUTE BY REPLICATION TO NODE datanode_1, datanode_2;
-- полная копия данных на обоих нодах
EXPLAIN VERBOSE SELECT sum(val) FROM tab1 GROUP BY val2;
HashAggregate
--подсчет суммы на ноде-координаторе
Output: sum(val), val2
-> Data Node Scan on tab1
Output: val, val2
--вытаскиваем таблицу целиком с одной из нод
Node/s: datanode_1
Remote query: SELECT val, val2 FROM ONLY tab1 WHERE true

20. Подсчет агрегата sum() v2:
CREATE TABLE tab1 (val int, val2 int)
DISTRIBUTE BY HASH(val) TO NODE datanode_1, datanode_2;
-- таблица раскидана на 2 ноды
EXPLAIN VERBOSE SELECT sum(val) FROM tab1 GROUP BY val2;
HashAggregate
Output: pg_catalog.sum((sum(tab1.val))), tab1.val2
--суммируем подитоги на координаторе
->Data Node Scan on "__REMOTE_GROUP_QUERY__"
Output: sum(tab1.val), tab1.val2
Node/s: datanode_1, datanode_2
Remote query: SELECT sum(group_1.val), group_1.val2
FROM (SELECT val, val2 FROM ONLY tab1
WHERE true) group_1 GROUP BY 2
--получаем частичные суммы с каждой из нод

21. А что на счет JOINS:
• Joins между и с участием реплицированных
таблиц, а также Joins между
распределенными по одному и тому же
полю в таблицах – выполняются на data-
нодах напрямую.
• Joins с участием распределенных таблиц по
другим ключам – будут выполнены на ноде-
координаторе и скорее всего это будет
медленно.

22. Известные ограничения.
• не поддерживаются триггеры (обещают
доделать в 1.1).
• Нет удобной системы
репартиционирования при добавлении или
удалении нод (тоже обещают доделать в
1.1 но даже тогда это будет означать
downtime)

23. Известные ограничения часть 2.
• Нет глобальных UNIQUE на распределенных
таблицах.
• Не поддерживаются курсоры (обещают в
версии 1.1)
• Не поддерживаются foreign keys между
нодами (т.е. FK стого должен вести на
данные расположенные на той же ноде).

24. Известные ограничения часть 3:
• Не поддерживается INSERT … RETURNING
(опять же обещается поддержка в 1.1)
• Невозможно удаление и добавление нод в
кластер без полной реинициализации
кластера (обещают в 1.1 тоже исправить).

25. А оно надежно?
• Много подсистем – много потенциальных
точек отказа. Архитектура PostgreSQL-XC с
самого начала предусматривает
возможность дублирования всех
компонентов.
• Ноды с данными и ноды-координаторы
представляют из слегка изменнеый
PostgreSQL и поддерживают streaming
репликацию для избыточности.

26. Обеспечение высокой доступности:
• GTM это отдельный процесс и может быть
точкой отказа, поэтому для него разработан
отдельный механизм синхроннго standby.
• Все ноды с данными и ноды координаторы
должны иметь синхронные streaming
реплики.
• GTM всегда используется в связке с GTM-
standby.

27. Backup и восстановление:
• Pg_dump/pg_dumpall работают фактически
так же как и для обычного PostgreSQL.
• Hot-backup – требует вызова специальной
команды CREATE BARRIER ‘barrier_id’
(фактически аналог вызова select
pg_start_backup(‘label’); ) далее для всех
нод с данными и координаторов так же как
для обычного PostgreSQL.

28. А зачем оно надо?
• При росте проекта может сложится
ситуация когда обьем данных или нагрузка
доходит до того уровня когда один сервер
(или даже мастер + N реплик) не
справляются с нагрузкой или по причине
высокого интенсивности записи в базу или
по причине роста объема данных.

29. А зачем оно надо?
• Тогда есть вариант или делать
слабосвязанную систему из многих
серверов (ручной шардинг) и переписывать
проект почти заново.
• Или попробовать использовать PostreSQL-
XC как временное или постоянное решение
оставив почти 100% совместимость с single-
database версий на уровне запросов.

30. А зачем оно надо?
• Вторая целевая группа для PostgreSQL-XC
это Data Warehousing и системы аналитики:
параллельное выполнение запросов на
распределенных таблицах позволяет резко
ускорить тяжелые аналитических запросы.
• Заодно и обьем данных на каждой из нод
будет поменьше.

31. А стоит ли оно того?
• Решать вам. Администрирование PostgreSQL-
XC заметно сложнее и более трудоемкое чем
администрирование простого PostgreSQL (но в
общем не принципиально сложнее чем
администрирование PostgreSQL в связке с
Slony или Londiste).
• Далеко не любой проект можно смигрировать
без переделок. Но их понадобится заметно
меньше чем при использовании шардинга.

32. Использованные материалы:
PostgreSQL-XC tutorial from PGCon2012 by
Koichi Suzuki
Michael Paquier
Ashutosh Bapat
http://www.pgcon.org/2012/schedule/attachments/224_Postgres-XC_tutorial.pdf
Официальная документация продукта:
http://postgres-xc.sourceforge.net/docs/1_0/