Максим Богук. Postgres-XC
1 like1,102 views
PostgreSQL-XC - это решение для кластеризации PostgreSQL, обеспечивающее автоматическое шarding и поддержку честной ACID-транзакций. Он позволяет почти линейную масштабируемость и высокую доступность при ограниченных условиях, но не является мультимастером и требует минимального количества нод с низкими задержками. Хотя его администрирование сложнее и трудоемще, он может существенно улучшить производительность при нагрузке или большом объеме данных.
Максим Богук. Postgres-XC
- 1. Postgresql XC Что это и с чем его есть. [email protected]
- 2. Что такое Postgresql-XC • Решение для кластеризации PostgreSQL с возможностью наращивания производительности путем добавления новых серверов. • Поддержка автоматического прозрачного шардинга данных на несколько серверов. • Честный ACID и честные транзакции в распределенной среде.
- 3. Что такое Postgresql-XC • До разумного количества нод – возможна (при определенных условиях) почти линейная масштабируемость и по чтению и по записи. • Возможно построение высокодоступных (high-available) конфигураций • Некоторые запросы могут выполнятся частично параллельно.
- 4. Чем не является PostgreSQL-XC • Хоть Postgresql-XC и выглядит похожим на MultiMaster он им не является. Все сервера кластера должны быть соединены сетью с минимальными задержками (читай воткнуты в один switch), никакое географически-распределенное решение с разумной производительностью построить на нем не возможно (это важный момент).
- 5. Масштабируемость Результаты DBT-1 Производительность Количество серверов
- 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 физических серверах или виртуалках.
- 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/