HTAP - одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика - в другой, а между ними ‑ разного рода ETL, CDC и прочие parquet‑файлы. В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.
История корпоративных СУБД последние пару десятков лет вращается вокруг одной и той же проблемы: OLTP и аналитика требуют разной архитектуры выполнения запросов, разной модели хранения данных и разного подхода к масштабированию. Транзакционная система обслуживает тысячи коротких операций, а аналитический движок стремится как можно быстрее читать огромные объемы, строить агрегацию и выполнять сложные JOIN'ы. Из‑за этого, кстати говоря, первые OLAP‑системы вообще не были реляционными.
Ранний OLAP строился вокруг отдельного аналитического контура: данные выгружались из операционной базы, загружались в многомерные кубы, рассчитывались агрегаты, и аналитики работали с уже подготовленным представлением данных. Тогда это выглядело абсолютно естественно: реляционные СУБД плохо справлялись с многомерной аналитикой, а сами аналитики думали не в терминах таблиц и индексов, а в терминах измерений, срезов, временных рядов и гиперкубов. Потом появился ROLAP, аналитика начала смещаться к реляционным данным. Oracle встроил OLAP Option прямо внутрь СУБД, появились материализованные представления, аналитические функции SQL, схемы «звезда» и «снежинка», но сама идея отдельного аналитического представления данных никуда не исчезла, она просто сменила форму.
OLAP и Postgres
Известная аналитическая записка специалистов Oracle в 2016 году справедливо указывала на то, что PostgreSQL не дотягивает до enterprise‑уровня ввиду отсутствия таких технологий как RAC, GRID, параллельная обработка запросов, Oracle Exadata Smart Scan и других. Базовый Postgres отлично решал транзакционные задачи, вокруг него росла экосистема, появлялись движки для аналитики, колоночные расширения, CDC‑конвейеры, и вот так вместе с ClickHouse, Greenplum, DuckDB, Kafka и другими постепенно сформировался целый класс систем, выстроенных вокруг идеи "PostgreSQL плюс аналитический движок" . Для рынка модель оказалась удобной. Вот это исследование HTAP‑систем 2024 года относит ее к классу архитектуры с двумя и больше независимыми хранилищами, причём это зрелый и полноценный класс систем. Транзакции живут внутри PostgreSQL, аналитика — внутри отдельного движка со своими форматом хранения, планировщиком запросов и логикой чтения. Даже если синхронизация идёт почти в реальном времени, между OLTP и аналитикой всё равно появляется прослойка из репликации, снапшотов или CDC‑механизмов. И чем выше нагрузка и объем данных, тем сильнее система начинает тратить ресурсы не на выполнение запросов, а на поддержание согласованности между двумя контурами обработки данных.
Довольно долго это не воспринималось как серьезное ограничение. Пока нагрузка укладывается в привычный сценарий "транзакции отдельно, аналитика отдельно", архитектура работает хорошо. Но крупные enterprise‑системы почти никогда не живут в такой чистой модели, и там появляются длинные снапшоты, большие объемы репликационного трафика, конкуренция за пропускную способность WAL и многие другие нюансы.
Другое важное свойство "комбо‑подходов" становится очевидным, когда речь заходит о такой прозаической, но важной вещи, как совместимость. Прикручиваемый OLAP‑движок — это все‑таки другая СУБД (да‑да, pg_duckdb — это тоже другая СУБД внутри PostgreSQL с другим SQL). Их создатели честно признают, что SQL‑диалект следует стандартам PostgreSQL, но из‑за различий в реализации некоторые конструкции обязательно будут работать иначе. Приходится отдельно описывать, как нужно корректировать запросы для аналитики (то есть для этой самой другой СУБД). Для пользователя, привыкшего к PostgreSQL, это означает дополнительный когнитивный барьер и риск получить ошибку на проде из‑за незаметного отличия в синтаксисе.
Вот лишь несколько примеров...
…из документации DuckDB:
enum‑типы PostgreSQL не поддерживаются вообще;numericPostgreSQL при высокой точности может автоматически преобразовываться вdouble precision, потому что DuckDB не поддерживает такой диапазон precision. Это уже риск потери точности финансовых и расчётных данных;jsonbв DuckDB превращается в обычныйjson, поскольку собственногоjsonbу DuckDB нет. Часть PostgreSQL‑операторов и функций для jsonb при этом просто отсутствует;timestamp_nsтеряет точность при преобразовании в PostgreSQL timestamp — наносекунды обрезаются до микросекунд;Многие сложные типы PostgreSQL работают с ограничениями. Например, multidimensional arrays требуют отдельной обработки, а nested‑типы вроде
STRUCT,MAPиUNIONимеют ограничения совместимости;Можно потерять гарантии ACID, если писать в обычную heap таблицу и таблицу duckdb в одной транзакции.
Итак, большая часть современного HTAP вокруг PostgreSQL развивается ровно по этой линии: рядом появляется отдельный аналитический контур - Greenplum, ClickHouse, DuckDB и другие. Извне все выглядит аккуратно: PostgreSQL продолжает выполнять транзакции, OLAP‑движок отвечает за тяжелые аналитические запросы, SQL остаётся знакомым. Возникает вопрос - а откуда аналитический движок берёт данные? В какой‑то момент выясняется, что почти вся архитектура таких систем вращается вокруг перегрузки данных из Postgres в отдельное аналитическое представление, будь то parquet, колоночное хранилище или материализованные представления. Сами данные при этом продолжают жить в обычных таблицах.
А могут ли данные не перегружаться?
Быть может, компаниям стоить копить данные не в реляционной СУБД, а сразу в паркетных файлах? Делать так, вообще говоря, можно, но это будут "мусорные", а не бизнес‑данные. Такого рода данные льются в ClickHouse и другие нереляционные базы в больших объемах, например, данные о посещении страниц пользователями. Клиентам облачных провайдеров интересно, как пользователи посещали страницы их небольших веб‑магазинов. Подобная аналитика продается на Западе, где развиты облачные сервисы, но найдется ли такое разнообразие малого бизнеса в России, который готов платить за аналитику?
Parquet‑файлы не появляются сами по себе: данные нужно выгружать, преобразовывать, синхронизировать, поддерживать консистентность. И вот тут «комбо‑HTAP» неожиданно начинает напоминать старые OLAP‑системы двадцатилетней давности, только вместо MOLAP‑кубов теперь parquet и векторная обработка. С инженерной точки зрения это совершенно нормальная архитектура, но есть тонкость, которая особенно заметна в enterprise‑системах.
OLAP "на корпоративном"
Корпоративная аналитика не всегда означает анализ петабайт логов или поведения пользователей крупного интернет‑магазина. В enterprise‑системах бизнес‑данные обычно живут в реляционных СУБД. ERP, банковские системы, биллинг, финансовый контур, транзакционные системы — все это обычные таблицы Oracle, MS SQL или PostgreSQL. Аналитика там нужна поверх оперативных данных — не выгруженных ночью через ETL, не подготовленных заранее в parquet, а таких, которые прямо сейчас находятся внутри транзакционной системы.
Именно поэтому Oracle много лет строил Exadata, RAC и OLAP Option вокруг идеи общего транзакционного хранилища. Ценность была не только в скорости аналитических запросов. Oracle строил архитектуру вокруг shared storage, общей видимости транзакций, возможности независимо масштабировать вычисления и хранилище, а также выполнять аналитику максимально близко к источнику данных. PostgreSQL долго двигался в другую сторону, оставаясь интегрированной Compute‑Storage системой со своей копией данных у каждой реплики. Фиксация транзакций проходит через единый WAL‑поток, MVCC‑снапшоты зависят от ProcArray. Масштабирование означает либо шардинг, либо появление отдельного аналитического контура.
Оффтоп: OLAP и шардинг
Логика шардинга проста: если одна PostgreSQL‑система перестаёт справляться одновременно с OLTP и аналитикой, значит данные нужно разнести по множеству узлов и распределить нагрузку. Поначалу все выглядит красиво: нагрузка масштабируется горизонтально, система выдерживает больший объем операций, потом возникают трудные вопросы с распределенными JOIN'ами, ребалансировкой и локализацией данных, накладные расходы на выполнение аналитических запросов поверх распределенной топологии. Для OLTP это еще терпимо, хотя совместимость c PostgreSQL начинает страдать уже здесь. Аналитике становится тяжело: чем сильнее данные физически распределены между шардами, тем дороже становится согласованное выполнение запросов поверх всей системы. Архитекторы вынуждены бороться за то, чтобы аналитические запросы случайно не превратились в сетевой шторм между shard‑нодами. Ну а если данные нужно реплицировать, то копия должна быть на каждом шарде. Нужно тратить время на репликацию, соответственно, когда нагрузка возрастает, быстро запустить еще одну машину не получится. Если же заниматься партиционированием и на каждом шарде держать свою партицию, то отказ одного шарда может повалить всю систему. Получается, реплики нужны еще и для партиций. Поэтому в машинах баз данных вместо тупикового шардинга довольно давно ушли в сторону shared storage и архитектурного разделения Compute и Storage.
Что в черном ящике, если «снаружи» — Postgres?
Интересен подход, который развивается в мире в cloud‑native базах данных (мы об этом писали в статье «Postgres по‑русски: где наши Aurora, AlloyDB и Neon?»). Упомянутое исследование HTAP‑систем отдельно выделяет архитектуры с разделением Compute и Storage и shared storage в отдельный класс Сloud‑native HTAP architecture. Среди примеров там упоминаются AlloyDB, SingleStore, Snowflake Unistore и PolarDB. У таких систем меняется сама точка разделения OLTP и аналитики, вместо отдельного аналитического хранилища появляется единый физический слой данных, вместо независимых копий — shared storage с общей видимостью транзакций. В такой схеме хранилище можно масштабировать независимо (то есть реплицировать его), поэтому система отказоустойчива. Новые узлы вычислений (читай: реплики) можно запускать быстро, поскольку для них нет никакой необходимости полностью реплицировать БД.
И вот это уже именно то направление, куда идет «Тантор Лабс» с проделанной работой над PolarDB и представленной в марте‑апреле 2026 г. МБД Tantor XData Gen3. Alibaba попыталась перестроить саму архитектуру PostgreSQL вокруг идеи общего хранилища данных. В Tantor Polar compute‑ноды не содержат собственной постоянной копии БД, все экземпляры работают поверх единого слоя хранения, и с точки зрения HTAP это уже иная модель. В Tantor Polar и Tantor Postgres 18 есть CSN (Commit Sequence Number) — развитие MVCC‑механики для единого порядка видимости транзакций между compute‑узлами. Каждый раз, когда транзакции требуется снимок, больше не нужно получать ProcArrayLock и проходиться по всем активным бэкендам, чтобы собрать их идентификаторы транзакций, соответственно, при тысячах соединений не происходит ограничения пропускной способности.
МБД Tantor XData Gen3 реализует совершенно иную идеологию. Благодаря shared storage и CSN система обеспечивает единый порядок видимости транзакций и предоставляет бизнесу консистентный срез данных на чистом PostgreSQL. Если системе нужна дополнительная вычислительная мощность под аналитику, можно добавить Compute‑ноды, и данные при этом не будут размножаться между серверами, потому что Compute‑слой отделен от хранения. И, главное, аналитические запросы не требуют иного синтаксиса, а значит, ни в 1С, ни в других бизнес‑приложениях ничего не потребуется переписывать.
Но как добиться масштабирования аналитических запросов, если мы сохраняем поведение обычного PostgreSQL? Здесь, как ни странно, на помощь приходит старый добрый GreenplumDB с его оптимизатором ORCA, но немного в другом виде. В основе HTAP в Tantor Polar лежит распределенный механизм выполнения MPP, реализованный на GPORCA и называемый PX/ePQ (Elastic Parallel Query). Почему «Elastic»? В традиционных MPP‑движках данные распределяются по разным узлам, и на разных узлах могут иметь разные атрибуты распределения, такие как хеш‑распределение, или случайное распределение, или же быть полностью реплицированными. Это зачастую вызывает перекосы в распределении данных и эффект «слабого звена» во время чтения, когда время выполнения ограничивается самой медленной подзадачей. В Tantor Polar нет шардинга и используется архитектура общего хранилища, позволяющая всем вычислительным узлам получать доступ ко всем данным. В распределенном MPP‑движке Tantor Polar мы позаимствовали идеи из модели Volcano для параллельной обработки всех операторов сканирования, и ввели оператор PxScan. Благодаря координации между рабочими процессами целевая таблица делится на несколько блоков данных виртуальных разделов. Каждый рабочий процесс сканирует свой собственный блок данных виртуального раздела, обеспечивая таким образом распределенное параллельное сканирование между машинами.
Данные, отсканированные оператором PxScan, перераспределяются с помощью оператора Shuffle. Затем перераспределенные данные обрабатываются на каждом рабочем узле так, как если бы это была единая машина, в соответствии с моделью Volcano.
Эластичное масштабирование в Tantor Polar дает ряд значимых преимуществ:
Любой узел может стать узлом‑координатором, что решает проблему единой точки отказа, присущую узлам‑координаторам в традиционных базах данных MPP.
Tantor Polar (МБД Tantor XData Gen3) может масштабироваться горизонтально (по количеству вычислительных узлов) и вертикально (параллелизм одного узла), при этом эластичное масштабирование вступает в силу немедленно, без необходимости перераспределения данных. Это позволяет использовать более гибкие стратегии планирования, обеспечивая работу различных бизнес‑доменов на разных наборах узлов.
Устранение типовых проблем асимметрии распределения данных, которые являются неотъемлемой частью традиционного MPP. Их основные причины кроются в асимметрии распределения данных и асимметрии их вычислений.
Все эти возможности доступны с использованием обычного heap. Для некоторых задач метод хранения heap является неоптимальным, например, если у нас широкая таблица, по которой необходимо прочитать только несколько колонок и выполнить агрегатные функции. Поэтому мы доработали ePQ/PX, чтобы он мог выполнять запросы по колоночным данных с нашим расширением pg_columnar. Это дало значительную экономию ресурсов и векторное выполнение для некоторых запросов.
Вы спросите, не проще ли было внедрить pg_duckdb? Не проще. Дело в том, что pg_duckdb работает в рамках одной ноды, и в open source для него нет распределенного движка. А это самая сложная часть для реализации. Использование проверенной (но не всегда идеальной) ORCA выглядит более оправданным: все ее плюсы и минусы известны, а сообщество большое — различные форки GreenplumDB и Cloudberry тому подтверждение.
Заключение
HTAP — это практический запрос бизнеса: аналитика нужна поверх оперативных данных без постоянной перегрузки в отдельные витрины, parquet‑файлы и внешние аналитические контуры. Проблема в том, что реализовать настоящий HTAP внутри PostgreSQL — сложная и нетривиальная задача. Нужны общая видимость транзакций, общее хранилище данных, масштабирование вычислений отдельно от хранения и глубокая перестройка самой архитектуры PostgreSQL. Пусть простой путь с интеграцией нескольких систем стал заметно удобнее и современнее, архитектурно каждая система все равно сохраняет свои особенности, синтаксис и жизненный цикл данных. В сумме это никак не дает HTAP‑машину в духе Oracle Exadata или SAP HANA.
В «Тантор Лабс» мы движемся в другую сторону. СУБД Tantor Polar и машина баз данных Tantor XData Gen3 развиваются вокруг идеи настоящего HTAP внутри PostgreSQL. Наша МБД уже умеет выполнять распределенные запросы на shared storage, а оптимизатор ORCA научился работать с columnar на основе Table Access Methods (пусть и ограниченно, тут впереди еще большая работа). PostgreSQL давно поддерживает подключаемые движки хранения, но большая часть механики выполнения запросов, MVCC и планировщика по‑прежнему глубоко завязана на классическую строчную модель хранения данных, поэтому полноценная колоночная обработка внутри PostgreSQL требует гораздо более глубокой переработки ядра, чем может показаться со стороны.
Ну и да — Tantor Polar точно так же можно дополнить ClickHouse или pg_duckdb. Но ведь тогда это выйдет совсем другая история:)
Читайте другие наши статьи о разработках в контексте HTAP СУБД: