Tantor Polar

Tantor Polar — это распределенная СУБД на базе PostgreSQL, построенная на архитектуре разделения вычислений и хранилища. Она происходит от PolarDB, open-source форка PostgreSQL от Alibaba, и включает значительные улучшения от Tantor Labs в областях производительности, консистентности, репликации и высокой доступности.

Tantor Polar сохраняет 100% совместимость с PostgreSQL — приложения, утилиты и расширения работают без модификаций.

Проблема: масштабирование монолитных баз данных

Традиционные монолитные базы данных объединяют вычисления и хранилище на одном узле. Их масштабирование дорого и операционно сложно:

  • Масштабирование чтения требует полных копий данных на каждом резервном сервере. Клонирование сервера медленное и дорогое. Синхронная репликация замедляет запись, а асинхронная приводит к задержке и риску каскадного распространения проблем из резервного сервера в основной.

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

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

Архитектура Shared-Storage

База данных переходит от традиционной архитектуры Shared-Nothing (N копий вычислений + N копий хранилища) к архитектуре Shared-Storage (N копий вычислений + 1 копия хранилища).

Shared-Storage Architecture

Ключевые характеристики:

  • Основной узел пишет WAL и страницы данных в общее блочное устройство по сети (EBS, Ceph, NBD, SAN и т.д.).

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

  • Пропускная способность хранилища масштабируется независимо от вычислений — число реплик масштабируется независимо от емкости хранения.

В отличие от других распределенных БД, дезагрегированное хранилище в Tantor Polar — это доступное по сети блочное устройство. Само блочное устройство может быть распределено по нескольким узлам, но обработка данных на уровне хранилища не происходит.

Есть много способов реализовать хранилища. В настоящее время рекомендуется использовать Linux MD Cluster поверх NVMe-oF с поддержкой RDMA. Подробнее смотрите в разделе Архитектура синхронного кластера хранения.

PolarFS

Доступ к одному и тому же блочному устройству с нескольких вычислительных узлов требует координации, чтобы все узлы видели согласованное состояние файлов и их метаданных. Эту функцию реализует PolarFS — распределенная файловая система, специально разработанная для PolarDB.

PolarFS предоставляет:

  • POSIX-подобный API для операций файловой системы

  • Небуферизованный (O_DIRECT) ввод-серверный процесс process), libpfs (низкоуровневая библиотека) и libpfsd (IPC-интерфейс между PFSD и ядром БД)

Tantor Labs внесла существенные улучшения в PolarFS:

  • Реализована функция fsync(): исходный PolarFS не включал функцию fsync() (полагаясь на гарантии хранилища Alibaba Cloud). Tantor Polar реализует надежный fsync() для произвольных блочных устройств.

  • Переписан IPC-механизм: исходный IPC плохо масштабировался под высокой нагрузкой. Новая реализация поддерживает устройства с миллионами операций ввода-вывода при меньших накладных расходах CPU.

  • Оптимизированы POLL-запросы: реплики используют POLL для проверки согласованности метаданных. Исходная реализация вызывала задержку реплик, в Tantor Polar POLL-запросы группируются (по аналогии с групповой фиксацией), что устраняет эту проблему.

  • Общие исправления ошибок и улучшения производительности: многочисленные исправления корректности и стабильности в PolarFS, а также настройка производительности для реальных рабочих нагрузок на стандартном оборудовании.

Эти улучшения привели к ускорению записи до 7 раз, а чтения до 10.9 раз.

Подробнее смотрите в разделе PolarFS.

Репликация

Tantor Polar переосмысляет репликацию PostgreSQL для модели shared-storage:

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

  • На реплики отправляются только кортежи метаданных <PageID, LSN> — этого достаточно поскольку реплики могут считывать фактические данные из общего хранилища.

  • Реплики отправляют обратно подтверждения LSN, основной узел считает данные «реплицированными» на основе подтвержденных LSN.

  • Используется стандартный протокол репликации PostgreSQL, что важно для совместимости с инструментами управления и мониторинга.

  • Репликация может быть как синхронной, так и асинхронной.

Подробно смотрите в разделе Репликация.

Модели согласованности

Изначально PolarDB обеспечивал только конечную согласованность — без гарантий актуальности данных на репликах. Tantor Polar добавляет два более строгих уровня согласованности:

  • Согласованность сессии («чтение ваших записей»): гарантирует, что сессия всегда видит свои собственные записи, даже когда запросы направляются на разные узлы. Реализовано с помощью пользовательского форка ProxySQL и расширение _polar_proxy_send_lsn для клиент-серверного протокола PostgreSQL.

  • Глобальная согласованность (сильная сериализуемость): гарантирует, что все сессии видят глобально согласованное представление данных. Построено на CSN (Commit Sequence Number) — монотонно возрастающем номере, присваиваемом каждой транзакции в момент фиксации. Требуется доработка на стороне сервера и интеграция с ProxySQL. Подробнее смотрите в разделе CSN.

HTAP: гибридная транзакционная/аналитическая обработка

Tantor Polar поддерживает облегченные аналитические рабочие нагрузки наряду с OLTP на одном и том же наборе данных, не требуя ETL и отдельных аналитических копий:

  • Эластичный параллельный запрос (Elastic Parallel Query, ePQ) обеспечивает массовую параллельную обработку (MPP) одних и тех же данных, ориентированных на строки.

  • Планировщик и исполнитель запросов адаптированы на основе Greenplum, предоставляя знакомые концепции: узлы-координаторы, сегменты, срезы и группы.

  • Координатором запросов может служить любой вычислительный узел.

  • Благодаря общему хранилищу отсутствует сегментирование или повторное размещение — разделение данных по узлам является чисто логическим, устраняя перекос в распределении.

Динамическое масштабирование позволяет настраивать:

  • Количество рабочих точек (процессорных ядер) на узел — вертикальное масштабирование (увеличение масштаба)

  • Количество вычислительных узлов, участвующих в аналитике — горизонтальное масштабирование (уменьшение масштаба)

Высокая доступность

PolarDB реализует shared-storage архитектуру, но не имеет встроенной автоматизации HA. Стандартный Patroni предполагает независимое локальное хранилище на каждом узле, что несовместимо с shared storage. Кроме того, Tantor Polar вводит типы узлов сверх стандартных PostgreSQL (первичный, реплика, резервный, DataMax).

Tantor Polar решает это с помощью:

  • Новый обработчик MPP в Patroni с доработками ядра Patroni

  • Поддержки всех типов узлов Tantor Polar, включая конфигурацию shared-storage:

polardb:
  storage_mode: pfsd
  instance_role: replica
  shared_data_path: /nvme1n1/shared_data

Disaster Recovery

Кросс-датацентровая репликация представляет собой классический компромисс: синхронная репликация гарантирует RPO=0, но повышает задержку записи, а асинхронная сохраняет производительность, но несет риск потери данных.

Tantor Polar решает эту проблему с помощью узлов DataMax — выделенных узлов ретрансляции WAL, которые:

  • Находятся в том же датацентре, что и основной кластер

  • Используют собственный локальный диск вместо общего хранилища

  • Синхронно получают WAL от основного кластера (гарантируя RPO=0)

  • Асинхронно ретранслируют WAL на резервные кластеры в удаленных датацентрах

Кроме того, резервные узлы в удаленных датацентрах поддерживают полностью независимые копии данных и могут быть повышены, если основной датацентр откажет. Повышение происходит только после полной синхронизации WAL, что гарантирует RPO=0.

Интеграция с Patroni охватывает все типы узлов, задействованных в аварийном восстановлении, включая резервные узлы и узлы DataMax.

Типы узлов

Tantor Polar поддерживает четыре типа узлов:

Тип узла

Роль

Основной

Единственный узел чтения-записи. Пишет WAL и страницы данных в общее хранилище..

Реплика

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

Резервный

Традиционные резервные серверы PostgreSQL с собственной копией в локальном хранилище. Используется для аварийного восстановления между центрами обработки данных.

DataMax

Узлы ретрансляции WAL с локальным хранилищем. Синхронно получают WAL от основного и асинхронно пересылают его удаленным резервным узлам, обеспечивая RPO=0 без влияния на задержку записи.

Итог

Возможности

Описание

Совместимость с PostgreSQL

100% — приложения, утилиты и расширения работают без изменений

Эластичность облака

Независимое масштабирование вычислений и хранилища, реплики добавляются за считанные минуты

HTAP

Аналитические запросы к оперативным данным без ETL с помощью эластичного параллельного запроса (ePQ)

Высокая доступность

Автоматизация на базе Patroni с быстрым переключением/отработкой отказа

Аварийное восстановление

RPO=0 за счет DataMax-узлов, поддержка резервирования между датацентрами