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