Поделиться
Релиз Postgres Pro Shardman 18.3.2: катастрофоустойчивость DRS и высокопроизводительная маршрутизация на стороне клиента
Компания Postgres Professional объявила о выходе новой версии распределённой СУБД Postgres Pro Shardman 18.3.2. Основной фокус релиза — обеспечение непрерывности бизнеса в географически распределённых кластерах, радикальное ускорение высоконагруженных OLTP-операций и качественное улучшение опыта администрирования (UX).
Начиная с 14 версии, в Postgres Pro Shardman существовал механизм георезервирования, однако ранее он был доступен лишь отдельным клиентам. В версии 18 DRS становится полноценной функцией, открытой для всех пользователей, с расширенными возможностями многорегиональной топологии.
Георезервирование работает по следующему принципу: в основном ЦОД функционирует продуктивный кластер, в резервном — его реплика в режиме standby. Кластер в автоматическом режиме создает точки восстановления, которые асинхронно реплицируются на резервный ЦОД по каждой ноде отдельно. При сбое система восстанавливается в резервном ЦОД на указанную точку.
Ключевые характеристики DRS:
Архитектура. Кластер развёртывается на базе двух дата-центров в рамках одного региона (основная единица). Обработка данных ведётся в одном активном регионе, остальные находятся в режиме Hot Standby.
Сетевые параметры. Решение оптимизировано для работы с задержками 5 мс внутри региона и до 50 мс между регионами.
Автовосстановление. После устранения сбоя прежний регион автоматически «докатывается» до состояния активного региона без ручного вмешательства.
Гарантии надёжности: внутри кластера: RPO = 0, RTO < 30 сек. (при потере одного дата-центра); между регионами: RPO = 1–5 мин, RTO < 30 сек. (при ручном переключении).
Реплика может быть слабее по серверным мощностям, но должна быть той же топологии, что и исходный кластер.
Для систем с нагрузкой от 30 млн транзакций в сутки время, затрачиваемое на межсерверные взаимодействия и расчёты внутри баз данных, становится критическим. В новом релизе оптимизирован механизм определения местонахождения данных.
Оптимизирована функция get_partition_for_value(), которая на больших объёмах могла занимать значительное время, сейчас время взаимодействия сокращено на 20%.
В 18.3.2 значительно переработан планировщик и транспортный слой Postgres Pro Shardman, что особенно заметно на CPU-ограниченных окружениях:
Fast Path — оптимизация одношардовых OLTP-запросов, не требующих межнодовой коммуникации. Прирост производительности составляет в среднем 15–20%, что особенно критично для сред, где ресурсы CPU являются узким местом.
Динамические воркеры чтения — пул воркеров на чтение теперь масштабируется динамически. Это позволяет системе эффективнее справляться с тяжёлыми читающими нагрузками в условиях высокой конкуренции за блокировки.
Async-Merge Append — переработан параллелизм операций сортировки. Запросы вида ORDER BY / LIMIT на распределённых таблицах (сценарий с множественными Foreign Scan по всем узлам) теперь выполняются значительно эффективнее. Это радикально ускоряет работу Keyset-пагинации, которая базируется именно на этих операторах.
Ускорение планирования — на таблицах с большим числом секций (тысячи партиций) время планирования существенно сокращено. Сравнительные тесты на 4096 партициях показывают троекратное ускорение планирования относительно 14-й версии Shardman.
В новой версии Postgres Pro Shardman стандартизирована работа с объектами данных внутри Postgres Pro Shardman. Это ключевое архитектурное изменение мажорного релиза.
«В версиях 14 и 17 граница между объектами уровня кластера и локальными объектами была частично размыта, что иногда приводило к усложнению эксплуатации системы в одной схеме и базе. Понимая, что возможность гибридного использования этих объектов в различных сценариях является одной из сильных сторон нашего продукта, мы решили ее стандартизировать, основываясь на опыте эксплуатации системы у наших крупных клиентов», – сказал Михаил Сумской, руководитель продуктового направления Shardman компании Postgres Professional.
В версии 18 введена четкая иерархия. Объекты уровня кластера управляются и контролируются Shardman, состоят из стандартных объектов Postgres на каждом шарде и метаданных к ним. Прямая модификация их составных частей запрещена. При этом локальные объекты по-прежнему доступны без ограничений: пользователь может создавать собственные схемы (например, для staging-зон при миграции или интеграции потоков данных) и любые объекты на отдельных узлах.
Таким образом объекты фактически разведены по схемам. Поддерживается два вида схем – распределенные и локальные. Распределенные схемы могут содержать в себе привязанные локальные объекты, жизненный цикл которых контролируется распределенной системой. Локальные схемы ничем не ограничены, но не могут содержать в себе распределенные объекты. Знание схемы позволяет понимать поведение объекта и модель его взаимодействия с другими объектами на уровне DDL. При этом, в выполнении запросов (например, одновременно к распределенным и локальным объектам) пользователи никак не ограничены.
В новом релизе сделан ряд шагов, упрощающих эксплуатацию продукта для администраторов и разработчиков. В частности, реализован отказ от etcd: система хранения конфигурации переработана для повышения надёжности и упрощения архитектуры кластера. Также проведена реорганизация команд. В утилите shardmanctl все кластерные операции теперь сгруппированы в логические блоки: shardmanctl cluster * (status, rebalance, upgrade, start/stop/restart) и shardmanctl config * (set, unset, update). Реализована стратегия Rolling Upgrade: команды обновления и перезагрузки штатно поддерживают «катящийся» режим для минимизации влияния на доступность.
В релиз 18.3.2 также вошел патч для облегчения проблемы «распухания» таблиц (bloating) и интегрирована поддержка pg_probackup 3 — полностью переработанного инструмента резервного копирования.
Новая версия уже доступна в репозиториях Postgres Professional.
Короткая ссылка
