Embed Size (px)
DESCRIPTION
Доклад на PGDay в рамках конференции Highload
Citation preview
Что такое Postgresql-XC
• Решение для кластеризации PostgreSQL с возможностью наращивания производительности путем добавления новых серверов.
• Поддержка автоматического прозрачного шардинга данных на несколько серверов.
• Честный ACID и честные транзакции в распределенной среде.
Что такое Postgresql-XC
• До разумного количества нод – возможна (при определенных условиях) почти линейная масштабируемость и по чтению и по записи.
• Возможно построение высокодоступных (high-available) конфигураций
• Некоторые запросы могут выполнятся частично параллельно.
Чем не является PostgreSQL-XC
• Хоть Postgresql-XC и выглядит похожим на MultiMaster он им не является. Все сервера кластера должны быть соединены сетью с минимальными задержками (читай воткнуты в один switch), никакое географически-распределенное решение с разумной производительностью построить на нем не возможно (это важный момент).
Масштабируемость
Количество серверов
Пр
ои
зво
ди
тел
ьно
сть
Результаты DBT-1
Архитектура (упрощенно)
Где взять и какие есть версии?
Официальный сайт:
http://postgres-xc.sourceforge.net/
Последняя доступная версия:
1.0.1 на основе Postgresql 9.1.5 (выпущена в сентябре 2012)
Версия в разработке:
1.1 на основе PostgreSQL 9.2 (ожидается в мае 2013)
Минимальная конфигурация:
• Минимальная конфигурация PostgreSQL-XC содержит 4 независимых подсистем (администрировать это все достаточно весело): 2 сервиса с данными, сервис-координатор, GTM (global transaction manager).
• В принципе это все можно завести на 2 физических серверах или виртуалках.
Как это выглядит?
Транзакции и ACID
• Приложение присоденившееся к любому из координаторов видит одинаковое (между всеми координаторами) и целостное представление данных.
• Честный ACID без необходимости вносить правки в приложение.
• Единые snapshots и видимость транзакций обеспечиваются специальным отдельным приложением GTM.
А как же печальноизвестная CAP теорема?
• PostgreSQL-XC попадает в CA угол этого треугольника. Таким образом всегда есть согласованность данных и доступность (HA требует дополнительной настройки но в целом возможен). В общем как и любое другое кластерное решение для классических баз данных.
Обеспечение транзакционой целостности между нодами.
• Для обеспечения транзакционной целостности операций затрагивающих более одной ноды – используется классический механизм 2PC (two-phase commit).
• После сбоя для разбора ситуации с 2PC есть специальная утилита pgxc_clean для приведения кластера в согласованное состояние.
Распределение данных в кластере
• Два в общем то стандартных варианта: таблица целиком хранися на всех базах кластера или шардинг (про это потом подробнее)
• Так как PostgreSQL-XC умеет проводить joins прямо на нодах с данными таблицы с которым часто идут Joins лучше реплицировать целиком.
Шардинг. В каких случаях?
• Таблицы логов (завершенные операции, посещения)
• Таблицы с временными данными (например корзина заказа в интернет магазине)
• Пользователи и их данные (шардинг по id пользователя).
Синтаксис шардинга:
• CREATE TABLE tab (…) DISTRIBUTE BY HASH(col) | MODULO(col) | REPLICATE
Просто и удобно.
На практике – надо очень внимательно думать о том как делать так как переделывать большую таблицу на другой режим шардинга до 1.1 очень неудобно.
Что не надо шардить?
• Таблицы-справочники и прочие глобальные данные с которыми постоянно производятся Joins (join большого обьема данных с таблицей разбитой на нескольких нодах будет весьма неэффективен).
• В общем то любые статические или редкоизменяемые таблицы с большим потоком чтения.
План простого запроса:
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)
План простого запроса 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)
Подсчет агрегата 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
Подсчет агрегата 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
--получаем частичные суммы с каждой из нод
А что на счет JOINS:
• Joins между и с участием реплицированных таблиц, а также Joins между распределенными по одному и тому же полю в таблицах – выполняются на data-нодах напрямую.
• Joins с участием распределенных таблиц по другим ключам – будут выполнены на ноде-координаторе и скорее всего это будет медленно.
Известные ограничения.
• не поддерживаются триггеры (обещают доделать в 1.1).
• Нет удобной системы репартиционирования при добавлении или удалении нод (тоже обещают доделать в 1.1 но даже тогда это будет означать downtime)
Известные ограничения часть 2.
• Нет глобальных UNIQUE на распределенных таблицах.
• Не поддерживаются курсоры (обещают в версии 1.1)
• Не поддерживаются foreign keys между нодами (т.е. FK стого должен вести на данные расположенные на той же ноде).
Известные ограничения часть 3:
• Не поддерживается INSERT … RETURNING (опять же обещается поддержка в 1.1)
• Невозможно удаление и добавление нод в кластер без полной реинициализации кластера (обещают в 1.1 тоже исправить).
А оно надежно?
• Много подсистем – много потенциальных точек отказа. Архитектура PostgreSQL-XC с самого начала предусматривает возможность дублирования всех компонентов.
• Ноды с данными и ноды-координаторы представляют из слегка изменнеый PostgreSQL и поддерживают streaming репликацию для избыточности.
Обеспечение высокой доступности:
• GTM это отдельный процесс и может быть точкой отказа, поэтому для него разработан отдельный механизм синхроннго standby.
• Все ноды с данными и ноды координаторы должны иметь синхронные streaming реплики.
• GTM всегда используется в связке с GTM-standby.
Backup и восстановление:
• Pg_dump/pg_dumpall работают фактически так же как и для обычного PostgreSQL.
• Hot-backup – требует вызова специальной команды CREATE BARRIER ‘barrier_id’ (фактически аналог вызова select pg_start_backup(‘label’); ) далее для всех нод с данными и координаторов так же как для обычного PostgreSQL.
А зачем оно надо?
• При росте проекта может сложится ситуация когда обьем данных или нагрузка доходит до того уровня когда один сервер (или даже мастер + N реплик) не справляются с нагрузкой или по причине высокого интенсивности записи в базу или по причине роста объема данных.
А зачем оно надо?
• Тогда есть вариант или делать слабосвязанную систему из многих серверов (ручной шардинг) и переписывать проект почти заново.
• Или попробовать использовать PostreSQL-XC как временное или постоянное решение оставив почти 100% совместимость с single-database версий на уровне запросов.
А зачем оно надо?
• Вторая целевая группа для PostgreSQL-XC это Data Warehousing и системы аналитики: параллельное выполнение запросов на распределенных таблицах позволяет резко ускорить тяжелые аналитических запросы.
• Заодно и обьем данных на каждой из нод будет поменьше.
А стоит ли оно того?
• Решать вам. Администрирование PostgreSQL-XC заметно сложнее и более трудоемкое чем администрирование простого PostgreSQL (но в общем не принципиально сложнее чем администрирование PostgreSQL в связке с Slony или Londiste).
• Далеко не любой проект можно смигрировать без переделок. Но их понадобится заметно меньше чем при использовании шардинга.
Использованные материалы:
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/
