Максим Богук. Postgres-XC
-
Upload
postgresql-consulting -
Category
Documents
-
view
718 -
download
8
description
Transcript of Максим Богук. Postgres-XC
![Page 2: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/2.jpg)
Что такое Postgresql-XC
• Решение для кластеризации PostgreSQL с возможностью наращивания производительности путем добавления новых серверов.
• Поддержка автоматического прозрачного шардинга данных на несколько серверов.
• Честный ACID и честные транзакции в распределенной среде.
![Page 3: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/3.jpg)
Что такое Postgresql-XC
• До разумного количества нод – возможна (при определенных условиях) почти линейная масштабируемость и по чтению и по записи.
• Возможно построение высокодоступных (high-available) конфигураций
• Некоторые запросы могут выполнятся частично параллельно.
![Page 4: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/4.jpg)
Чем не является PostgreSQL-XC
• Хоть Postgresql-XC и выглядит похожим на MultiMaster он им не является. Все сервера кластера должны быть соединены сетью с минимальными задержками (читай воткнуты в один switch), никакое географически-распределенное решение с разумной производительностью построить на нем не возможно (это важный момент).
![Page 5: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/5.jpg)
Масштабируемость
Количество серверов
Пр
ои
зво
ди
тел
ьно
сть
Результаты DBT-1
![Page 6: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/6.jpg)
Архитектура (упрощенно)
![Page 7: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/7.jpg)
Где взять и какие есть версии?
Официальный сайт:
http://postgres-xc.sourceforge.net/
Последняя доступная версия:
1.0.1 на основе Postgresql 9.1.5 (выпущена в сентябре 2012)
Версия в разработке:
1.1 на основе PostgreSQL 9.2 (ожидается в мае 2013)
![Page 8: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/8.jpg)
Минимальная конфигурация:
• Минимальная конфигурация PostgreSQL-XC содержит 4 независимых подсистем (администрировать это все достаточно весело): 2 сервиса с данными, сервис-координатор, GTM (global transaction manager).
• В принципе это все можно завести на 2 физических серверах или виртуалках.
![Page 9: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/9.jpg)
Как это выглядит?
![Page 10: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/10.jpg)
Транзакции и ACID
• Приложение присоденившееся к любому из координаторов видит одинаковое (между всеми координаторами) и целостное представление данных.
• Честный ACID без необходимости вносить правки в приложение.
• Единые snapshots и видимость транзакций обеспечиваются специальным отдельным приложением GTM.
![Page 11: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/11.jpg)
А как же печальноизвестная CAP теорема?
• PostgreSQL-XC попадает в CA угол этого треугольника. Таким образом всегда есть согласованность данных и доступность (HA требует дополнительной настройки но в целом возможен). В общем как и любое другое кластерное решение для классических баз данных.
![Page 12: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/12.jpg)
Обеспечение транзакционой целостности между нодами.
• Для обеспечения транзакционной целостности операций затрагивающих более одной ноды – используется классический механизм 2PC (two-phase commit).
• После сбоя для разбора ситуации с 2PC есть специальная утилита pgxc_clean для приведения кластера в согласованное состояние.
![Page 13: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/13.jpg)
Распределение данных в кластере
• Два в общем то стандартных варианта: таблица целиком хранися на всех базах кластера или шардинг (про это потом подробнее)
• Так как PostgreSQL-XC умеет проводить joins прямо на нодах с данными таблицы с которым часто идут Joins лучше реплицировать целиком.
![Page 14: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/14.jpg)
Шардинг. В каких случаях?
• Таблицы логов (завершенные операции, посещения)
• Таблицы с временными данными (например корзина заказа в интернет магазине)
• Пользователи и их данные (шардинг по id пользователя).
![Page 15: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/15.jpg)
Синтаксис шардинга:
• CREATE TABLE tab (…) DISTRIBUTE BY HASH(col) | MODULO(col) | REPLICATE
Просто и удобно.
На практике – надо очень внимательно думать о том как делать так как переделывать большую таблицу на другой режим шардинга до 1.1 очень неудобно.
![Page 16: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/16.jpg)
Что не надо шардить?
• Таблицы-справочники и прочие глобальные данные с которыми постоянно производятся Joins (join большого обьема данных с таблицей разбитой на нескольких нодах будет весьма неэффективен).
• В общем то любые статические или редкоизменяемые таблицы с большим потоком чтения.
![Page 17: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/17.jpg)
План простого запроса:
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)
![Page 18: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/18.jpg)
План простого запроса 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)
![Page 19: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/19.jpg)
Подсчет агрегата 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
![Page 20: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/20.jpg)
Подсчет агрегата 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
--получаем частичные суммы с каждой из нод
![Page 21: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/21.jpg)
А что на счет JOINS:
• Joins между и с участием реплицированных таблиц, а также Joins между распределенными по одному и тому же полю в таблицах – выполняются на data-нодах напрямую.
• Joins с участием распределенных таблиц по другим ключам – будут выполнены на ноде-координаторе и скорее всего это будет медленно.
![Page 22: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/22.jpg)
Известные ограничения.
• не поддерживаются триггеры (обещают доделать в 1.1).
• Нет удобной системы репартиционирования при добавлении или удалении нод (тоже обещают доделать в 1.1 но даже тогда это будет означать downtime)
![Page 23: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/23.jpg)
Известные ограничения часть 2.
• Нет глобальных UNIQUE на распределенных таблицах.
• Не поддерживаются курсоры (обещают в версии 1.1)
• Не поддерживаются foreign keys между нодами (т.е. FK стого должен вести на данные расположенные на той же ноде).
![Page 24: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/24.jpg)
Известные ограничения часть 3:
• Не поддерживается INSERT … RETURNING (опять же обещается поддержка в 1.1)
• Невозможно удаление и добавление нод в кластер без полной реинициализации кластера (обещают в 1.1 тоже исправить).
![Page 25: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/25.jpg)
А оно надежно?
• Много подсистем – много потенциальных точек отказа. Архитектура PostgreSQL-XC с самого начала предусматривает возможность дублирования всех компонентов.
• Ноды с данными и ноды-координаторы представляют из слегка изменнеый PostgreSQL и поддерживают streaming репликацию для избыточности.
![Page 26: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/26.jpg)
Обеспечение высокой доступности:
• GTM это отдельный процесс и может быть точкой отказа, поэтому для него разработан отдельный механизм синхроннго standby.
• Все ноды с данными и ноды координаторы должны иметь синхронные streaming реплики.
• GTM всегда используется в связке с GTM-standby.
![Page 27: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/27.jpg)
Backup и восстановление:
• Pg_dump/pg_dumpall работают фактически так же как и для обычного PostgreSQL.
• Hot-backup – требует вызова специальной команды CREATE BARRIER ‘barrier_id’ (фактически аналог вызова select pg_start_backup(‘label’); ) далее для всех нод с данными и координаторов так же как для обычного PostgreSQL.
![Page 28: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/28.jpg)
А зачем оно надо?
• При росте проекта может сложится ситуация когда обьем данных или нагрузка доходит до того уровня когда один сервер (или даже мастер + N реплик) не справляются с нагрузкой или по причине высокого интенсивности записи в базу или по причине роста объема данных.
![Page 29: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/29.jpg)
А зачем оно надо?
• Тогда есть вариант или делать слабосвязанную систему из многих серверов (ручной шардинг) и переписывать проект почти заново.
• Или попробовать использовать PostreSQL-XC как временное или постоянное решение оставив почти 100% совместимость с single-database версий на уровне запросов.
![Page 30: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/30.jpg)
А зачем оно надо?
• Вторая целевая группа для PostgreSQL-XC это Data Warehousing и системы аналитики: параллельное выполнение запросов на распределенных таблицах позволяет резко ускорить тяжелые аналитических запросы.
• Заодно и обьем данных на каждой из нод будет поменьше.
![Page 31: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/31.jpg)
А стоит ли оно того?
• Решать вам. Администрирование PostgreSQL-XC заметно сложнее и более трудоемкое чем администрирование простого PostgreSQL (но в общем не принципиально сложнее чем администрирование PostgreSQL в связке с Slony или Londiste).
• Далеко не любой проект можно смигрировать без переделок. Но их понадобится заметно меньше чем при использовании шардинга.
![Page 32: Максим Богук. Postgres-XC](https://reader031.fdocuments.net/reader031/viewer/2022020207/5558ea5bd8b42ab8168b50a9/html5/thumbnails/32.jpg)
Использованные материалы:
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/