Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Что такое Postgresql (Максим Богук)

3,028 views

Published on

  • Be the first to comment

Что такое Postgresql (Максим Богук)

  1. 1. Postgresql XC Что это и с чем его есть.Maxim.Boguk@PostgreSQL-Consulting.com
  2. 2. Что такое Postgresql-XC• Решение для кластеризации PostgreSQL с возможностью наращивания производительности путем добавления новых серверов.• Поддержка автоматического прозрачного шардинга данных на несколько серверов.• Честный ACID и честные транзакции в распределенной среде.
  3. 3. Что такое Postgresql-XC• До разумного количества нод – возможна (при определенных условиях) почти линейная масштабируемость и по чтению и по записи.• Возможно построение высокодоступных (high-available) конфигураций• Некоторые запросы могут выполнятся частично параллельно.
  4. 4. Чем не является PostgreSQL-XC• Хоть Postgresql-XC и выглядит похожим на MultiMaster он им не является. Все сервера кластера должны быть соединены сетью с минимальными задержками (читай воткнуты в один switch), никакое географически-распределенное решение с разумной производительностью построить на нем не возможно (это важный момент).
  5. 5. Масштабируемость Результаты DBT-1Производительность Количество серверов
  6. 6. Архитектура (упрощенно)
  7. 7. Где взять и какие есть версии?Официальный сайт: http://postgres-xc.sourceforge.net/Последняя доступная версия:1.0.1 на основе Postgresql 9.1.5 (выпущена всентябре 2012)Версия в разработке:1.1 на основе PostgreSQL 9.2 (ожидается в мае 2013)
  8. 8. Минимальная конфигурация:• Минимальная конфигурация PostgreSQL-XC содержит 4 независимых подсистем (администрировать это все достаточно весело): 2 сервиса с данными, сервис- координатор, GTM (global transaction manager).• В принципе это все можно завести на 2 физических серверах или виртуалках.
  9. 9. Как это выглядит?
  10. 10. Транзакции и ACID• Приложение присоденившееся к любому из координаторов видит одинаковое (между всеми координаторами) и целостное представление данных.• Честный ACID без необходимости вносить правки в приложение.• Единые snapshots и видимость транзакций обеспечиваются специальным отдельным приложением GTM.
  11. 11. А как же печальноизвестная CAP теорема?• PostgreSQL-XC попадает в CA угол этого треугольника. Таким образом всегда есть согласованность данных и доступность (HA требует дополнительной настройки но в целом возможен). В общем как и любое другое кластерное решение для классических баз данных.
  12. 12. Обеспечение транзакционой целостности между нодами.• Для обеспечения транзакционной целостности операций затрагивающих более одной ноды – используется классический механизм 2PC (two-phase commit).• После сбоя для разбора ситуации с 2PC есть специальная утилита pgxc_clean для приведения кластера в согласованное состояние.
  13. 13. Распределение данных в кластере• Два в общем то стандартных варианта: таблица целиком хранися на всех базах кластера или шардинг (про это потом подробнее)• Так как PostgreSQL-XC умеет проводить joins прямо на нодах с данными таблицы с которым часто идут Joins лучше реплицировать целиком.
  14. 14. Шардинг. В каких случаях?• Таблицы логов (завершенные операции, посещения)• Таблицы с временными данными (например корзина заказа в интернет магазине)• Пользователи и их данные (шардинг по id пользователя).
  15. 15. Синтаксис шардинга:• CREATE TABLE tab (…) DISTRIBUTE BY HASH(col) | MODULO(col) | REPLICATEПросто и удобно.На практике – надо очень внимательнодумать о том как делать так как переделыватьбольшую таблицу на другой режим шардингадо 1.1 очень неудобно.
  16. 16. Что не надо шардить?• Таблицы-справочники и прочие глобальные данные с которыми постоянно производятся Joins (join большого обьема данных с таблицей разбитой на нескольких нодах будет весьма неэффективен).• В общем то любые статические или редкоизменяемые таблицы с большим потоком чтения.
  17. 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. 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. 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. 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;HashAggregateOutput: 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. 21. А что на счет JOINS:• Joins между и с участием реплицированных таблиц, а также Joins между распределенными по одному и тому же полю в таблицах – выполняются на data- нодах напрямую.• Joins с участием распределенных таблиц по другим ключам – будут выполнены на ноде- координаторе и скорее всего это будет медленно.
  22. 22. Известные ограничения.• не поддерживаются триггеры (обещают доделать в 1.1).• Нет удобной системы репартиционирования при добавлении или удалении нод (тоже обещают доделать в 1.1 но даже тогда это будет означать downtime)
  23. 23. Известные ограничения часть 2.• Нет глобальных UNIQUE на распределенных таблицах.• Не поддерживаются курсоры (обещают в версии 1.1)• Не поддерживаются foreign keys между нодами (т.е. FK стого должен вести на данные расположенные на той же ноде).
  24. 24. Известные ограничения часть 3:• Не поддерживается INSERT … RETURNING (опять же обещается поддержка в 1.1)• Невозможно удаление и добавление нод в кластер без полной реинициализации кластера (обещают в 1.1 тоже исправить).
  25. 25. А оно надежно?• Много подсистем – много потенциальных точек отказа. Архитектура PostgreSQL-XC с самого начала предусматривает возможность дублирования всех компонентов.• Ноды с данными и ноды-координаторы представляют из слегка изменнеый PostgreSQL и поддерживают streaming репликацию для избыточности.
  26. 26. Обеспечение высокой доступности:• GTM это отдельный процесс и может быть точкой отказа, поэтому для него разработан отдельный механизм синхроннго standby.• Все ноды с данными и ноды координаторы должны иметь синхронные streaming реплики.• GTM всегда используется в связке с GTM- standby.
  27. 27. Backup и восстановление:• Pg_dump/pg_dumpall работают фактически так же как и для обычного PostgreSQL.• Hot-backup – требует вызова специальной команды CREATE BARRIER ‘barrier_id’ (фактически аналог вызова select pg_start_backup(‘label’); ) далее для всех нод с данными и координаторов так же как для обычного PostgreSQL.
  28. 28. А зачем оно надо?• При росте проекта может сложится ситуация когда обьем данных или нагрузка доходит до того уровня когда один сервер (или даже мастер + N реплик) не справляются с нагрузкой или по причине высокого интенсивности записи в базу или по причине роста объема данных.
  29. 29. А зачем оно надо?• Тогда есть вариант или делать слабосвязанную систему из многих серверов (ручной шардинг) и переписывать проект почти заново.• Или попробовать использовать PostreSQL- XC как временное или постоянное решение оставив почти 100% совместимость с single- database версий на уровне запросов.
  30. 30. А зачем оно надо?• Вторая целевая группа для PostgreSQL-XC это Data Warehousing и системы аналитики: параллельное выполнение запросов на распределенных таблицах позволяет резко ускорить тяжелые аналитических запросы.• Заодно и обьем данных на каждой из нод будет поменьше.
  31. 31. А стоит ли оно того?• Решать вам. Администрирование PostgreSQL- XC заметно сложнее и более трудоемкое чем администрирование простого PostgreSQL (но в общем не принципиально сложнее чем администрирование PostgreSQL в связке с Slony или Londiste).• Далеко не любой проект можно смигрировать без переделок. Но их понадобится заметно меньше чем при использовании шардинга.
  32. 32. Использованные материалы: PostgreSQL-XC tutorial from PGCon2012 by Koichi Suzuki Michael Paquier Ashutosh Bapathttp://www.pgcon.org/2012/schedule/attachments/224_Postgres-XC_tutorial.pdfОфициальная документация продукта:http://postgres-xc.sourceforge.net/docs/1_0/

×