Мы уже рассматривали Shardman подробно, а сегодня расскажем о  горизонтальном масштабировании СУБД Postgres Pro с помощью Shardman и Citus.

Коротко о масштабировании для тех, кто ещё с ним не сталкивался.

Масштабироваться можно как горизонтально, так и вертикально. 

Вертикальное масштабирование повышает производительность сервера за счёт увеличения его ресурсов: замены процессора, наращивания и/или изменения типа памяти, установки более быстрых жёстких дисков большего объёма. Как вариант можно купить более мощный сервер и перевезти на него СУБД — это тоже будет вертикальным масштабированием.

Решение не идеальное, потому что рано или поздно вы снова столкнётесь с проблемами нехватки серверных мощностей.

Горизонтальное масштабирование предполагает добавление новых серверов той же мощности к уже существующим — это позволяет перераспределить нагрузку и линейно масштабироваться. К такому виду масштабирования относятся шардинг и репликация.

Репликация позволяет создать несколько реплик данных на других узлах, чтобы уменьшить нагрузку на основной сервер и направить её на чтение реплики. Подход полезен только для масштабирования по чтению.

На рисунке выше представлены узлы мастера и реплики. Между узлами настроена физическая потоковая репликация, которая синхронизирует реплику с мастером, — можно перераспределить нагрузку на чтение данных между двумя узлами. Такой подход масштабирует нагрузку только по чтению данных.

При шардировании данные, хранящиеся на одном мастер-узле, перераспределяются на другие, и каждый узел хранит часть данных. Узлы такого кластера могут взаимодействовать через настроенные межузловые соединения (интерконнект). Приложения могут работать с любым из этих узлов для чтения и записи данных.

На рисунке выше представлено горизонтальное масштабирование с помощью шардирования: данные распределяются между несколькими параллельно работающими узлами. Каждый узел хранит свой фрагмент данных. Такой подход позволяет перераспределять нагрузку не только на чтение, но и на запись. 

В нашем примере два узла выступают в роли мастера и принимают запросы на чтение и запись. На каком узле размещены нужные данные, может быть известно и приложению, и шардированной СУБД, но ещё нужно обеспечить интерконнект для межузлового взаимодействия.

Шардирование полезно, когда:

• уже есть большая и нагруженная СУБД, использующая все доступные ресурсы сервера;

• вертикальное масштабирование экономически или технически невозможно;

• невозможно изменить архитектуру доступа и работы с данными;

• планируется строить КХД с массивно-параллельной архитектурой;

• реализуется встроенное горизонтальное масштабирование;

• нужно логически изолировать данные на разных узлах (мультитенантность).

Варианты шардирования в Postgres Pro:

• Shardman. Патч к ядру на основе Postgres Pro, реализованный по принципам массивно-параллельной архитектуры, обеспечивающий горизонтальное масштабирование.

• Citus. Внешнее расширение для Postgres Pro, предоставляющее горизонтальное масштабирование и колоночное хранение

Особенности Shardman и Citus собраны в таблице. Как видите, варианты дополняют друг друга.

Архитектура

Архитектура Shardman включает несколько компонентов, например, кластер DCS, в роли которого выступает кластер ETCD. Как правило, в продакшен-решениях он состоит из трёх узлов, которые хранят информацию о состоянии всех узлов кластера Shardman и его топологию. 

Кластер Shardman состоит из шардов, на нодах которых запущен демон shardmand — он обеспечивает кластеризацию шарда и управляет экземплярами Postgres. Каждый шард доступен на чтение и запись. Между шардами настроен мультиплексор, который позволяет узлам взаимодействовать и обмениваться данными. Это собственная разработка Postgres Professional, которая оптимизирует межузловое взаимодействие в распределенных транзакциях от пользователя и позволяет не множить количество соединений между шардами. 

Единую точку входа в кластер можно обеспечить на стороне приложения, с помощью технологий проксирования или обращения к конкретному узлу. 

Чтобы добавить новый шард:

1. Подготовьте новый сервер.

2. Установите набор пакетов для Shardman.

3. Запустите службу shardmand.

4. Добавьте новый узел в кластер с помощью утилиты shardmactl nodes add.

Узел появится в кластере, данные будут перераспределены с помощью логической репликации.

Архитектура Citus несколько отличается от Shardman: в Citus нет кластера DCS для хранения состояний, а архитектура включает отдельный узел-координатор, через который настраиваются другие узлы и создаются воркеры — структуры данных, распределённые на других шардах. 

Соответственно, пользователь может обращаться к любому шарду для DML-запросов, а каждый узел будет выступать в роли координатора и перераспределять запросы на другие шарды. DDL-запросы нужно выполнять непосредственно на координаторе.

Особенности шардирования на основе строк в Shardman

• Шардированная таблица состоит из набора секций, которые физически находятся на разных узлах кластера.

• Число секций фиксируется при создании таблицы, изменить его нельзя.

• На каждом узле содержится только часть данных таблиц.

• Взаимодействие между партициями обеспечивает FDW.

• Данные равномерно распределяются по HASH-значению определённых полей таблицы.

Допустим, вы распределяете строки таблицы по HASH определённого атрибута, например, по UserID. Для одного пользователя данные будут размещаться на шарде 1, для другого — на шарде 2, а вы делаете условный запрос к координатору.

В Citus применяется шардирование, которое позволяет разделять данные таблиц на уровне схемы. Поэтому можно использовать search_path, который указывается при подключении пользователя к кластеру, и обращаться к соответствующей схеме, в которой есть определённые наборы данных (для каждой схемы они свои). Таким образом можно хранить данные определённой компании на отдельном узле.

В распределенной таблице ниже при добавлении новой шарды часть партиций переезжает на новый узел. Данные переливаются посредством логической репликации. За счет этого каждый узел начинает обрабатывать меньше данных, что линейно увеличивает общую производительность кластера.

Отказоустойчивость

Как и планировали, в 17-й версии Shardman начали использовать BiHA: каждый шард представляет собой трёхузловой кластер BiHA.

В Citus отказоустойчивость не встроена, но её можно обеспечить с помощью внешних решений:

• Patroni, который управляет топологией кластера и синхронизирует данные. Каждый шард — это отказоустойчивый кластер Patroni, точку входа можно реализовать на стороне пользователя или внешними компонентами (НaProxy). 

• pg_autofailover (предварительно установить dev-пакет Postgres Pro Enterprise и собрать расширение из исходников).

Резервное копирование

В Shardman резервные копии создаются с учетом согласованности данных на уровне всего кластера, а восстановление происходит на синхронизированной точке — всё это c помощью утилиты pg_probackup, в состав которой входит shardmanctl.

Резервное копирование в Citus не автоматизировано, но его можно выполнить вручную:

• Вести архив WAL и делать резервную копию для каждого узла с помощью, например, pg_basebackup. 

• Восстанавливать каждый узел с помощью глобальной именованной точки citus_create_restore_point().

Итоги

Shardman базируется на ядре PostgreSQL Pro Enterprise 17, что позволяет использовать дополнительные функции, совместимые с распределенными СУБД: CFS-сжатие данных, инкрементальное резервное копирование (PTRACK), 64-битный счетчик транзакций (XID) и адаптивный планировщик запросов (AQO). А еще отказоустойчивость из коробки (BiHA), доработанные средства диагностики, включая пакеты pgpro_pwr, pgpro_stats.

исп