В статье — обзор доклада Алексея Копытова (автора sysbench) на конференции PG BootCamp, прошедшей 19 марта 2026 года.
Введение
Доклад заинтересовал меня тем, что докладчик работал в MySQL AB (High Performance group within the MySQL Support Team), Percona, позже в Huawei. В мире MySql есть разработчики, которые хорошо понимают архитектуру реляционных баз данных, то есть могут довольно быстро внести в мир PostgreSQL программные решения из MySQL, которые смогут повысить производительность и отказоустойчивость PostgreSQL.
Когда я слушал доклад на конференции, мне были непонятны термины, которых я до сих пор не встречал в PostgreSQL и Oracle Database. Вероятно, использовалась терминология, принятая в MySQL/Percona.
Доклад Алексея Копытова шёл за докладом Вадима Яценко, чей доклад представил слушателям новую СУБД Tantor Polar. На момент доклада, за две недели до конференции, была опубликована статья, где подробно описывалась новая архитектура, поэтому выступление Яценко вызвало особый интерес и, по сути, послужило публичной презентацией этих наработок. Если кратко — Tantor Polar основана на технологиях Alibaba, доработана командой Tantor в том числе посредством реверс-инжиринга, планируется к выпуску в open source, при этом 100% совместима с PostgreSQL.
От оригинального PolarDB унаследовано главное: архитектура с разделением Compute и Storage. Ядром этого подхода является высокопроизводительная файловая система PolarFS, которая работает поверх протокола RDMA и NVMe-oF, позволяя узлам кластера обращаться к общему хранилищу с задержками, сопоставимыми с локальным SSD. Благодаря этому Tantor Polar может работать как в обычном режиме, так и в режиме разделения, где один мастер-узел (RW) отвечает за запись, а несколько реплик (RO) — только за чтение.
Доклады Вадима и Алексея друг друга не повторяют: в первом представлены результаты, а во втором — отдельные технические подробности новшеств.
Зачем разделять Compute и Storage?
Идея разделения compute и storage для меня была непонятна тем, что администратор СУБД видит смонтированные директории или, как в Oracle RAC, нарезку блочных устройств, объединяет их в том (дисковую группу) и форматирует. Подсоединением блочных устройств в операционную систему занимается администратор СХД (систем хранения данных).
Если диски подключаются к интерфейсам ввода-вывода на материнской плате, то разделения compute и storage нет. Так как PostgreSQL использует только один экземпляр для обслуживания кластера баз данных (директория PGDATA), то прямое подсоединение дисков к материнской плате — простое и часто используемое решение, так как задержки минимальны.
Tantor Polar позволяет работать нескольким экземплярам с одной директорией PGDATA. Если диски подсоединены локально к одному из хостов, то нужен софт, который позволит давать доступ к дискам или файловым системам другим хостам. Это возможно, но имеет недостатки:
1) надо учитывать, что один из узлов имеет меньшую задержку при доступе, чем остальные;
2) экспортирование файловых систем или блочных устройств нагружает центральные процессоры хостов, на которых работают экземпляры PostgreSQL. Под большой нагрузкой задержки доступа непредсказуемы.
Более разумно использовать отдельные узлы (устройства), к которым подключаются диски и которые экспортируют блочные устройства или файловые системы хостам, на которых работают экземпляры PostgreSQL. Для связи можно использовать сетевые интерфейсы, так как они быстрые, недорогие и с низкой задержкой. Первый набор узлов можно назвать storage nodes, второй набор можно назвать compute nodes. Получается разделение compute и storage.
В Tantor XData Gen.3 в упрощённой конфигурации три storage и несколько compute узлов, связанных двумя коммутаторами RDMA. Для связи узлов используется NVMe-oF, который, в свою очередь, работает поверх RDMA. Число узлов можно увеличивать независимо друг от друга. В Oracle Exadata для quarter (четверть) rack — 2 compute и 3 storage; half (половина) rack — 4 compute и 6 storage; full rack — 8 compute и 12-14 storage. На узлах Exadata storage установлен linux, оптимизированный («обрезанный») для обслуживания доступа к дискам, кэширования их содержимого.
Классификация существующих технологий в докладе
В начале доклада Алексей классифицировал СУБД по точке разделения Compute и Storage. Вероятно, чтобы снять вопрос: чем отличается технология PolarDB от других технологий, так как есть много реализаций распределения по хостам (узлам, системным блокам, виртуальным машинам) СУБД.
Классификация может быть интересна, если делается выбор между Polar и другими технологиями. Классифицировать можно разными способами. Например, параметры конфигурации PostgreSQL можно классифицировать по уровням, контекстам, категориям.
Для меня достаточно того, что:
1) альтернативные технологии технически сложнее и дальше от PostgreSQL, чем Polar;
2) Oracle Databaseиспользует RAC, аналогичный Polar, а не те альтернативные технологии (на слайде от Greenplum до AlloyDB).
Шардинг, Greenplum, Citus — независимые СУБД. Разделение выполняется на точке входа. Например, на балансировщике нагрузки. У Алексея точка разделения — выше SQL, но это путает. Балансировщик просматривает SQL-запрос, вычленяет оттуда названия таблиц и определяет на какой кластер баз данных PostgreSQL послать этот запрос или трансформированный запрос. У Greenplum этим занимается часть кода планировщика (GPORCA, Greenplum Open Resource Coordinator/Optimizer).
Скрытый текст
На хабре были статьи про SPQR. Я считал SPQR балансировщиком нагрузки, таким как как pgbouncer/HAproxy. В статьях его описывали, как софт для шардинга. Приходится разбираться в изложении, чтобы понять, что имеют в виду. С SPQR оказалось, что он «встаёт между приложением и кластерами PostgreSQL, парсит SQL‑запросы, определяет на какой «шард» (то есть кластер PostgreSQL) их отправить, и возвращает результат.» То есть когда-то была потребность в балансировщике, балансировщик написали, назвали SPQR. Как балансировщик он не получил успеха, так как не смог конкурировать с pgbouncer, у которого меньше задержка. Чтобы не отправлять в корзину труд, добавили функционал и назвали решением по шардингу. Довольно умная трансформация концепции и позиционирования продукта.
У решений «Шардинг, Greenplum, Citus» обеспечить согласованность на один момент времени проблематично. Технический аналог времени — номер транзакции (xid, transaction identifier) в PostgreSQL, системный номер изменения (SCN, system change number) в Oracle Database). Greenplum, Citus — для аналитики и долгих запросов и для них согласованность некритична. Шардинг же подразумевает использование в OLTP и обслуживание коротких запросов и проблема согласованности для него актуальна. Самое простое — не поддерживать соединения строк, находящихся в разных шардах (кроссшардовые соединения), при этом писать, что кроссшардовые запросы поддерживаются.
В технологиях шардинга, No-SQL (YDB и других) надо «следить за руками», то есть пробираться через дебри терминов и выяснять в конце, что более, чем весь функционал работает «своеобразно», а не так, как в реляционных базах данных. Транзакции там не ACID (Atomicity, Consistency, Isolation, Durability), а BASE (Basically Available, Soft-state, Eventual consistency).
Алексей сказал, что в «Шардинг, Greenplum, Citus» разделения compute и storage нет. У Spanner, YugabyteDB, YDB, CockroachDB, TiDB транзакции уходят на storage узел. У Amazon Aurora, Neon, AlloyDB реализуется идея «LOG is DB». Журнал изменений первичен и уходит на storage узлы, на которых журнал изменений обрабатывается, формирует версии блоков данных (страниц) на разные моменты времени. Блоки данных затем предоставляются compute узлам. Алексей провёл линию раздела где-то на уровне buffer pool и wal buffers.
Для Tantor Polar линию раздела Алексей провёл ниже, сразу над Storage. Storage обеспечивает только хранение, а не сложную обработку, что обеспечивает лучшую совместимость с PostgreSQL и меньший объем доработок. В отличие от SPQR, где тоже доработок не так много, нет ограничений по кросшардовым запросам, необходимости разделения данных. Совместимость Tantor Polar c PostgreSQL подтвердили тем, что продукты 1С работают с Tantor Polar так же, как с Tantor SE 1C, только быстрее.
Архитектура Tantor Polar
Используется общее устройство хранения, одновременно доступное всем compute узлам. Устройства хранения доступны compute узлам, как блочные устройства по сети и могут быть любыми системами хранения — Ceph, NBD, SAN, EBS.
После долгих экспериментов, для системы хранения выбрали Linux MD Cluster поверх протокола NVMe-oF, который, в свою очередь, работает поверх RDMA.
Начиная с 19 версии, OracleRAC тоже может использовать NVMe-oF.
Oracle RAC также может использовать и кластерную файловую систему ocfs2, которую открыла под лицензией GPL. OCFS2 была интегрирована в ядро linux 2.6.16. Пометка «experimental» была убрана начиная с в версии ядра linux 2.6.19. Однако, ocfs2 не стала востребованной даже для Oracle RAC. Несмотря на то, что ASM имеет закрытый код, она преимущественно и используется с Oracle RAC. Доработанный Tantor PolarFS и остальные доработки будут выложены в свободный доступ по свободной лицензии, как и все доработки Тантор, которые выкладываются на гитхабе. Это полезно и позволяет желающим оценить качество кода тех продуктов, которые продаются.
Как показывает пример с ocfs2, которому предпочитают ASM, открытый исходный код не основная причина выбора продукта пользователями. По моему мнению, основная причина — беспроблемность в эксплуатации и перспективы развития. Тантор Лабс входит в группу компаний Астра, что делает положение компании устойчивым и развивает все продукты. Я вижу, что развитие продуктов идёт с ускорением. Когда я прочёл первую статью про Tantor Polar, я подумал: к Тантор переходит технологическое лидерство в технологиях СУБД. Серьёзный подход демонстрирует также то, что технологии Tantor Polar доступны в XData, так как рассчитаны на компании и организации, которым нужно обрабатывать большие объемы данных под большой нагрузкой. Такой же подход использует и Oracle, делая часть новшеств доступными только для инженерных систем (Exadata) или на своём оборудовании (Oracle Cloud).
PolarFS
На compute узлах работают экземпляры PostgreSQL, которые имеют доступ к одной и той же директории кластера баз данных (PGDATA) и директориям табличных пространств. В отличие от Oracle RAC, пишущим является только один экземпляр — мастер. В качестве файловой системы используется PolarFS, которая работает с блочными устройствами, как и Oracle Database, в режиме O_DIRECT (direct i/o, минуя страничный кэш Linuх). Файловая система использует многопоточность. PostgreSQL же использует многопроцессную модель и потоки не использует. Для стыковки используется многопоточный процесс-демон PFSD. Процессы экземпляров взаимодействуют с PFSD через IPC. PFSD взаимодействует с блочными устройствами через библиоткеку libpfs. libpfs преобразует запросы от PFSD в стандартные POSIX-вызовы, которые понимает блочное устройство.
PolarFS изначально создавалась под MySQL, а эта СУБД многопоточная. С MySQL PolarFS интегрируется бесшовно — поток к потоку. А при работе с PostgreSQL непонятно, как назначать потоки PolarFS процессам PostgreSQL. Поэтому и понадобилась прослойка в виде PFSD.
Благодаря direct i/o, нет двойного кэширования (в обычном PostgreSQL есть двойное кэширование), под страничный кэш linux не нужно отдавать много памяти и в Tantor Polar оперативная память используется более экономно. Под структуры памяти экземпляров можно отдать больше памяти.
Поскольку PolarFS может использовать любое блочное устройство для хранения, в том числе, использующие обычный Ethernet(TCP/IP), то можно территориально разнести Compute и Storage. Сетевые задержки будут высоки. Alibaba использует свой проприетарный территориально разнесённый Storage. В Tantor PolarFS был доработан в части отказоустойчивости: использования fsync и fdatasync. Это понадобилось для универсальности, чтобы можно было использовать не только с устройствами хранения Alibaba, но и с любыми устройствами и обеспечивать при этом гарантированное сохранение данных при любых сбоях, даже при внезапном отключении питания.
Также Tantor заменил RPC и pooling, который использовался Alibaba PolarFS на IPC с callback, что позволило убрать ненужные задержки и снять ограничение на IOPS при работе с высокоскоростными устройствами хранения типа NVME. Алексей перечислил и другие доработки. В сумме, доработки ускорили работу со Storage на порядок. Tantor PolarFS (кластерная файловая система) на тестах показал 1,2 миллиона IOPS для чтения и 700 тысяч IOPS на запись на стандартно используемых устройствах хранения TantorXData, обеспечивая при этом отказоустойчивость.
Репликация между экземплярами Polar
Пишущий экземпляр (мастер) и читающие (реплики) работают с одной и той же PGDATA. В WAL пишет мастер, на экземпляры WAL по сети не передаются, читающие экземпляры сами прочтут журнальные записи с диска. Однако, пишущий экземпляр передаёт на реплики поток «метаданных», состоящий из (PageID, LSN). У читающих экземпляров в их буферных кэшах находится часть блоков данных файлов PGDATA. Метаданные нужны для оптимизации, чтобы читающий экземпляр читал только нужные ему LSN и применял к блокам, находящимся в своём буферном кэше. Если блок не в буферном кэше, то он будет прочитан с диска, куда его записал пишущий экземпляр.
Читающие передают мастеру LSN write/flush, apply, чтобы мастер знал, какие данные получены и применены репликами.
Подтверждения могут возвращаться синхронно или асинхронно. При синхронном возврате мастер и реплики Tantor Polar согласованы и выдают одинаковые данные. Благодаря меньшему объему передаваемых по сети метаданных, по сравнению с обычной физической репликацией, в которой передаются сами журнальные записи, задержки не зависят от объема журнальных записей.
В Alibaba PolarDB согласованность данных при обращении к репликам не гарантировалась. Для гарантий согласованности использовался функционал липких сессий балансировщика (прокси). В Tantor Polar добавлен уровень с гарантией чтения собственных изменений для сессии при обращении к любому экземпляру и бескомпромиссная согласованность, для которой пришлось реализовать CSN. В скором времени будет добавлена бескомпромиссная согласованность (global consistency). Реализация близка к завершению, оптимизируется согласование выполнения DDL команд, которые затрагивают не только изменения строк таблиц системного каталога, но и файлов данных.
Из MySQL была взята концепция мини-транзакций:
Скрытый текст
На закрытии PgConf 2026 Олег Бартунов сказал: «Дорогие мои постгресисты. Мне очень приятно видеть, как выросло наше сообщество с той самой ещё первой встречи. А я хочу сказать, что самая первая встреча на самом деле была ещё тогда, когда компаний не было. Когда мы собирались на Highoade маленькой группкой постгресистов. А до этого, я помню, как у нас был баттл «MySQL против постгресистов». И там было двое на двое: я, Федя Сигаев, а со стороны MySQL был Костя Осипов и ещё кто-то. Ну, в общем, понятно, да? Почему я вспомнил, потому что мы победили. По́стгрес forever! Спасибо всем за участие!«
MySQL не забыт! Технологии MySQL нашли себя в PostgreSQL, интегрируются с PostgreSQL и улучшают производительность.
Data Max (аналог Far Sync)
Также из MySQL взяли концепцию binblog серверов и назвали реализацию как Data Max. Стоит сказать, что в Oracle Database есть аналог — Far Sync. Алексей и разработчики Polar пришли из мира MySQL, а не Oracle Database. Суть всех трёх технологий: экземпляр (не хранящий данные) получает WAL, сохраняет их на диск и ретранслирует другим экземплярам по стандартному протоколу репликации PostgreSQL.
Высокая доступность
Для работы с Tantor Polar был доработан Patroni. В Patroni был интерфейс для работы с Citus, через него и реализованы несложные доработки, примерно в сотню строк кода.
Поддерживается резервная конфигурация, которая, обычно, располагается в другом ЦОД (центре обработки данных). Между основной конфигурацией хостов Tantor Polar и резервной, репликация идёт как в обычном PostgreSQL — WAL передаются по репликационному протоколу.
Для полной защиты от потери транзакций в Tantor Polar используется экземпляр DataMax. С помощью DataMax реализуется уровень защиты от полной потери основной конфигурации, как Oracle Maximum Protection/Availability с Zero Data Loss. DataMax присутствовал в 11 версии Alibaba PolarDB и был портирован из этой версии. Доработанный Patroni распознаёт экземпляр DataMax и выполняет перключение (promotion) резервной конфигурации только после передачи WAL с DataMax, чтобы исключить потери транзакций — Zero Data Loss (он же RPO=0).
Экземпляр Data Max принимает WAL на свой диск и располагается ближе к основной конфигурации, так как сетевая задержка между Primary и DataMax экземплярами влияет на TPS — WAL передаются в синхронном режиме и DataMax подтверждает транзакции. То есть часть DataMax, принимающая WAL работает аналогично pg_recevewal (walreceiver).
Вопросы после доклада
Поддерживается ли Kubernetes? Ограничений нет. Если будет спрос, то будет реализовано.
Есть ли сжатая файловая система? Технология Polar работает с блочными устройствами и если СХД сжимает, то будет работать с ним.
Скрытый текст
По моему мнению, сжатие более эффективно на уровне PostgreSQL, и оно уже есть для TOAST, а реализация сжатия чисто на уровне файловой системы не оправдается. Oracle реализовал сжатие HCC на Exadata, и нельзя сказать, что это сильно востребовано.
С Oracle HCC возникал вопрос: тип сжатия HCC возможен только на файлах табличных пространств, расположенных на железе Oracle (Exadata, Pillar Axiom). А что, если скопировать файл данных с железа Oracle на обычное железо, неужели данные будут потеряны? Oracle сделал следующее: данные, сжатые HCC, надо разжать и тогда с ними можно будут работать. То есть разжатие по этому алгоритму работает и на обычном железе. Конечно, все «поверили», что на обычном железе HCC сжимает как-то не так (например, медленно), именно поэтому алгоритм программно отключили для обычного железа.
Диалоги про сжатие на уровне файловой системы, обычно, заканчиваются так:
«- а кто-то в продакшене использует postgres на btrfs с compress=zstd:1 ? на тестах выглядит круто, как бы понять, тащить это в прод или не стоит
— Что показывают тесты? Как изменилась нагрузка на CPU и размер данных?
— на pgbench двукратная деградация по производительности по сравнению с ext4. пока на паузе»
Какая версия PostgreSQL? Работает на 15 версии. Выполняется ребейзинг на 17 версию.
Вопрос от СКАЛА-Р. Есть ли глобальный pg_stat_activity? То есть аналоги GV$ (Global View, показывающие данные со всех экземпляров) представлений в Oracle Database. Статистики были доработаны.
Отдаются ли исходники в open source? Да, планируется отдать, рисков конкуренции Тантор не видит.
На хостах storage есть ли софт? Нет, storage узлы обычные, которые отдают только доступ к блочным устройствам и обработки данных не выполняет.
Клиент libpq модифицированный? Не модифицирован, так как есть 100% совместимость с ванильным PostgreSQL, всеми клиентскими библиотеками и расширениями. Но если использовать клиентскую библиотеку libpq от Tantor Polar, то она может отдавать клиентам дополнительные атрибуты, например, отражающие работу балансировщика.
У каждого экземпляра свой кэш буферов. Насколько они синхронизированы и на что это влияет? Кэши буферов экземпляров не синхронизируются (т.е. аналога Oracle Cache Fusion нет). Экземпляр с непрогретым кэшем буферов будет давать задержки по сравнению с прогретым. Можно использовать прогрев кэша стандартным расширением pg_prewarm.
В оригинальном PolarDB реализован PBP – Persistent Buffer Pool. Когда кластер PolarDB for PostgreSQL неожиданно перезапускается или отключается, shared_buffers очищается и инициализируется заново — происходит «холодный старт». Восстановление после «холодного старта» требует повторного воспроизведения журналов предварительной записи (WAL) и загрузки данных с диска, что влияет на доступность кластера и вызывает колебания производительности после перезапуска.
Функция постоянного буферного пула (PBP) исключает «холодные старты», сохраняя shared_buffers при перезапусках. Кластер запускается с «теплым» состоянием, с немедленно доступными кэшированными данными, что сокращает время восстановления после сбоя и стабилизирует производительность после перезапуска.
Функционал пока доступен только в PolarDB 11, но команда Tantorпланирует его портировать в более свежие версии Tantor Polar.
Скрытый текст
Oracle Cache Fusion — это передача образа блока из буферного кэша одного экземпляра в буферный кэш другого экземпляра по сети, через сетевой интерфейс, по которому общаются экземпляры (cluster interconnect). До появления Cache Fusion в Oracle RAC блоки передавались через диск: один экземпляр скидывал грязный блок на диск, а второй экземпляр, которому понадобился блок, его читал с диска. В то время сетевые интерфейсы работали с меньшей задержкой, чем интерфейсы storage и Cache Fusion ускорило работу Oracle RAC. Технология рекламировалась как: можно считать, что кэши буферов всех экземпляров работают как единое целое — буферный кэш размером с суммарный объем кэшей экземпляров. Однако, потом появились твердотельные диски (SSD) и задержки при передаче блоков через диск стали существенно меньше. А при передаче по сети — накладные расходы на многошаговую процедуру поиска блока и его передачу с множеством глобальных блокировок в Cache Fusion присутствовали. Cache Fusion отошел на второй план и при обслуживании тяжелых запросов, больший эффект давало распределение блоков по экземплярам при выполнении параллельных запросов.
Есть ли статистика, какая пропорция compute и storage в общем response time? Алексей ответил, что это зависит от запроса. Одно дело Seq Scan — задержка на storage будет больше и другое дело сортировка. В Tantor Polar есть расширение polar_monitor, которое предоставляет множество метрик, в том числе покажет такие задержки именно ввода-вывода. Для этого реализованы представления polar_stat_io_info и polar_stat_io_latency.
Есть ли защита от повреждений дисков в системе хранения данных shared storage? Storage можно сделать дублированным. В Tantor XData поддерживается конфигурация дублирования и детально прописаны действия в случае выхода из строя компонент системы хранения (дисков). То есть аналогично Oracle ASM, в котором есть external redundancy (без зеркалирования и отказоустойчивости), normal redundancy (двойное зеркало), high redundancy (тройное зеркало), failure group (диски, подключенные к одному контроллеру, которые при отказе контроллера могут совместно отвалиться). Зеркалирование требует дополнительное место. Также, для защиты WAL используются диски DataMax.
ПАКи (программно-аппаратные комплексы) и МБД (машины баз данных)
Tantor Polar поставляется с машиной баз данных Tantor XData Gen3 (третье поколение). МБД TantorXData, на которой работали нагрузочные тесты, была представлена на конференции PG BootCamp:
На конференции PgConf 2026 PostgresPro Machine не было, а стенд находился в самом дальнем углу:
Год назад, на PgConf 2025 Postgres Professional анонсировал начало разработки своего ПАК и стенд PostgresPro Machine располагался в центре зала. На стенде была стойка с машиной. Машина год назад не выпускалась и говорили, что рабочий вариант будет в конце августа. Я спросил — почему не привезли машину в этот раз, сказали, что, наверное, её было тяжело затаскивать или проблемы с провозом.
Я пошел гулять по выставке и увидел стенд СКАЛА-Р, на котором была стойка со Скалой. Значит, проблем с затаскиванием и провозом не было.
Вместо системных блоков (блейдов) внутри Скалы стоял ноутбук, на котором крутились презентации, выводимые на переднюю панель Скалы. На закрытии конференции, Иван Панченко (генеральный директор Постгрес Профессиональный), сказал: «Есть кто-нибудь из Скалы? Поднимитесь! Лучший из существующих ПАКов на По́стгресе — Скала«.
Заключение
Доклад Алексея можно посмотреть в записи.
10 апреля у Максима Горшенина вышло интервью «Вся правда о Tantor XData Gen3«, где рассказано про историю выбора PolarDB и создания Tantor Polar (ссылка на ютюб).
ссылка на оригинал статьи https://habr.com/ru/articles/1023046/