Вы — DBA или архитектор в компании, где PostgreSQL — это сердце продукта. Вы отвечаете за то, чтобы база работала, и прекрасно знаете: одна кривая сессия в пятницу вечером может испортить выходные всей команде. Например, финансовому отделу срочно нужен тяжелый аналитический отчет за последние пять лет. Аналитик пишет развесистый SELECT с десятком JOIN, запускает его на проде... и база ложится. Транзакции висят, пользователи видят 504 ошибку, а вы в панике убиваете сессию аналитика, чтобы спасти систему.
Классическое решение этой проблемы известно всем: нужно строить DWH (хранилище данных). Вы покупаете отдельные серверы, разворачиваете ClickHouse или Greenplum, нанимаете дата-инженеров и начинаете писать ETL-пайплайны.
А дальше начинается суровая реальность. ETL-скрипты падают по ночам из-за изменившейся схемы данных. Данные в хранилище всегда немного отстают от прода. Аналитикам приходится учить новый диалект SQL. А бизнес с ужасом смотрит на счета за двойную инфраструктуру и расширенную команду для ее сопровождения.
Мы в Postgres Professional давно смотрели на эту боль и думали: а что, если перестать гонять данные туда-сюда? Что, если научить PostgreSQL одинаково хорошо справляться и с быстрыми транзакциями (OLTP), и с тяжелой аналитикой (OLAP)? Так появился Postgres Pro AXE.
Что такое AXE и почему «акселератор»
AXE — это аналитическое решение на ядре PostgreSQL. Оно может работать как самостоятельная СУБД для тяжёлых OLAP-нагрузок, так и расширять возможности уже существующей PostgreSQL-инфраструктуры — добавляя полноценную аналитику без замены того, что уже работает. Неофициально в команде её называют «аналитический акселератор»: вы остаётесь в привычной Postgres-среде, но аналитические запросы начинают работать совсем иначе.
Под капотом AXE — СУБД Postgres Pro и два расширения. Первое расширение, pgpro_axe, это векторный аналитический движок. Второе, pgpro_metastore, — это каталог метаданных аналитических таблиц: оно преобразует Parquet-файлы в полноценные аналитические таблицы, управляет правами доступа к ним и обеспечивает ACID-гарантии при работе с OLAP-данными, включая согласованность метаданных при многопользовательском доступе. Все операции с аналитическими данными — выгрузка, регистрация, обновление, управление доступом — выполняются через единый интерфейс хранимых процедур pgpro_metastore. Вместе эти компоненты дают то, чего нет ни в обычном PostgreSQL, ни в большинстве специализированных СУБД: возможность работать с транзакционной и аналитической нагрузкой на одной инфраструктуре — без отдельного аналитического сервера и без замены существующей системы.
Ключевое понятие, которое стоит усвоить, — аналитическая таблица. Это логическая сущность (набор строк и столбцов), структура которой зарегистрирована в каталоге метаданных pgpro_metastore. Физически данные аналитической таблицы хранятся во внешнем или локальном хранилище в столбцовом формате, а векторный движок pgpro_axe считывает их напрямую при выполнении аналитических запросов.
О формате хранения. AXE использует Parquet — открытый столбцовый формат, где данные одного столбца лежат рядом на диске. Это позволяет при запросе читать только нужные столбцы, а не строки целиком, эффективно сжимать данные и оставаться совместимым со всеми современными BI-инструментами: Superset, Metabase, Tableau и другими.
В тестах TPC-H/TPC-DS и ClickBench результаты выглядят так:
до 30 раз быстрее PostgreSQL на аналитических запросах при одинаковом «железе»;
до 20 раз быстрее Greenplum на сложных запросах;
до 10 раз меньше потребление RAM и CPU по сравнению с Greenplum для достижения той же производительности.
Почему аналитика убивает ваш прод
Проблема, с которой мы начали, имеет системное объяснение. PostgreSQL — строчная база данных (row-oriented). Когда вы делаете SELECT SUM(revenue) FROM orders WHERE date > '2026-01-01', PostgreSQL читает каждую строку целиком, хотя вам нужен только один столбец. При миллионах строк это катастрофически неэффективно — аналитический запрос загружает CPU и I/O, создавая конкуренцию за ресурсы с транзакционными сессиями. Пользователи видят задержки, а DBA — красный мониторинг.
AXE использует столбцовое хранение (column-oriented): данные одного столбца лежат рядом на диске, читаются вместе, обрабатываются векторными инструкциями процессора. Физически это тот самый формат Parquet, о котором мы говорили выше, — данные сжимаются в несколько раз, а при запросах считываются только нужные столбцы, что экономит I/O.
Жизненный сценарий: аналитика продаж без боли и ETL
Отойдём от синтетических тестов и посмотрим на реальную задачу.
Представьте крупный e-commerce. В основной базе Postgres крутятся горячие данные: текущие заказы, корзины пользователей, остатки на складах — классический OLTP. Но маркетологам нужно внедрить динамическое ценообразование (Smart Pricing) и сегментировать клиентов на основе покупок за последние три года.
Хранить три года истории в обычных Heap-таблицах Postgres — дорого и неэффективно. Такие запросы будут сканировать терабайты данных, загружая CPU и I/O — именно те ресурсы, которые нужны транзакционным сессиям прямо сейчас. Классическое решение — ETL в отдельное хранилище — это отдельный сервер, дублирование данных, задержки синхронизации и ещё один продукт в стеке, который нужно поддерживать.
С AXE задача решается иначе. Вместо копирования данных в стороннюю СУБД мы переводим их в формат Parquet — открытый бинарный формат с поколоночным сжатием. Он идеально подходит для аналитики: данные сжимаются в несколько раз, а при запросах считываются только нужные столбцы, что экономит I/O.
Разовое чтение через read_parquet() удобно для быстрых тестов, но если к историческим данным будут регулярно обращаться десятки аналитиков и BI-систем, их правильнее зарегистрировать как аналитическую таблицу.
Настройка выполняется один раз. Сначала мы объявляем и инициализируем сам каталог метаданных, а затем регистрируем в нем хранилище и таблицу:
-- Указываем параметры подключения к каталогу метаданных SELECT metastore.define_catalog_connection( 'localhost', -- адрес сервера метаданных '5433', -- порт 'postgres', -- имя базы данных 'metastore_admin',-- имя администратора AXE 'password' -- пароль ); -- Инициализируем структуру каталога метаданных SELECT metastore.init(); -- Создаём описание хранилища, куда AXE будет складывать Parquet-файлы SELECT metastore.add_storage( 'orders_storage', -- имя хранилища для дальнейших ссылок 's3://analytics/orders', -- целевой путь для хранения данных 's3://analytics/orders/tmp' -- временный каталог для промежуточных операций ); -- Регистрируем аналитическую таблицу в каталоге SELECT metastore.add_table( 'orders_archive', -- имя аналитической таблицы 'orders_storage', -- используемое хранилище 'public.orders' -- наследуем структуру существующей таблицы Postgres ); -- Переносим данные из транзакционной таблицы в аналитическую (конвертируем в Parquet) SELECT metastore.copy_table( 'orders_archive', 'SELECT * FROM public.orders' ); -- Создаём стандартное представление Postgres Pro для прозрачного доступа SELECT metastore.create_view('orders_archive');
После этого orders_archive выглядит для любого пользователя как обычная таблица Postgres: к ней применяются привычные права доступа через GRANT, она видна в стандартных инструментах. Аналитик просто пишет SELECT * FROM orders_archive — и не думает о том, что данные физически лежат в S3. Никаких ETL-серверов. Никаких промежуточных слоёв между источником и аналитикой. Минимальная рассинхронизация.
А как же нагрузка на прод?
Справедливый вопрос от любого DBA: «Вы предлагаете запустить аналитику на сервере, где у меня крутится процессинг платежей? Вы в своём уме?»
Именно так мы и не предлагаем. Продуктивный сервер с транзакционной нагрузкой — это не место для тяжёлой аналитики: аналитические запросы будут конкурировать за CPU и I/O с транзакционными сессиями именно тогда, когда это наименее уместно. Расширения AXE устанавливаются на мастер и автоматически распространяются на реплики вместе с данными. Для аналитической нагрузки вы просто направляете BI-системы (Superset, Metabase, Tableau) и аналитиков на реплику — она утилизирует простаивающие мощности, не создавая конкуренции с транзакционным мастером.
Основной мастер продолжает спокойно обрабатывать транзакции, а реплика утилизирует свои простаивающие мощности для переваривания тяжёлых отчётов. Экономия на оборудовании с первого дня.
Интерфейс metastore: как это работает на практике
Все сценарии работы с аналитическими данными в AXE реализуются через единый интерфейс хранимых процедур pgpro_metastore. Независимо от задачи — архивация логов, финансовая отчётность или динамическое ценообразование — последовательность одна: создать хранилище, зарегистрировать аналитическую таблицу, наполнить её данными, создать представление.
Исторические данные без архивирования. Классическая ситуация: данные за прошлые годы переносят в архивную систему или просто удаляют, потому что они замедляют запросы. С AXE исторические данные лежат в Parquet-файлах, мгновенно доступны через SQL и не мешают работе приложения.
Разберём на примере таблицы пользовательских событий user_events, которая постоянно пополняется. Вот полный рецепт из четырёх шагов:
1. Создаём хранилище — указываем AXE, куда класть Parquet-файлы:
SELECT metastore.add_storage( 'events_storage', -- имя хранилища 'file:///data/events', -- путь к Parquet-файлам 'file:///data/events_tmp' -- путь для временных файлов );
2. Создаём аналитическую таблицу — регистрируем в metastore «обёртку» над будущими Parquet-файлами, наследуя структуру столбцов от существующей таблицы Postgres:
SELECT metastore.add_table( 'user_events_archive', -- имя новой аналитической таблицы 'events_storage', -- хранилище из шага 1 'public.user_events', -- берём структуру столбцов отсюда 'имя_столбца1,имя_столбца2' -- столбцы для секционирования(необязательный параметр) );
3. Наполняем аналитическую таблицу данными — copy_table() выполняет SQL-запрос над таблицами Postgres, конвертирует результат в Parquet-файл и связывает его с аналитической таблицей из шага 2. Этот вызов можно запускать по расписанию, добавляя каждый месяц данные за предыдущий период:
SELECT metastore.copy_table( 'user_events_archive', -- аналитическая таблица из шага 2 $$ SELECT * FROM public.user_events WHERE created_at BETWEEN date_trunc('month', now()) - interval '1 month' AND date_trunc('month', now()) $$ -- запрос к Postgres, результат уйдёт в Parquet );
4. Создаём представление — чтобы обращаться к аналитической таблице как к обычной, без специального синтаксиса:
SELECT metastore.create_view('user_events_archive');
После этого аналитик просто пишет SELECT * FROM user_events_archive — и не думает о том, что данные физически лежат в Parquet-файлах. Прод не затронут, данные за годы доступны мгновенно.
Финансовая отчётность без отдельного DWH. Финансовая аналитика — это классический OLAP: агрегации по периодам, сравнение план/факт, группировки по подразделениям. Раньше для этого строили отдельное хранилище с ETL-конвейером. С AXE достаточно создать аналитическую таблицу поверх существующих данных:
SELECT metastore.add_storage( 'finance_storage', 's3://analytics/finance', -- сюда AXE будет складывать Parquet-файлы 's3://analytics/finance/tmp' -- временная папка для промежуточных операций ); SELECT metastore.add_table( 'sales_archive', -- имя новой аналитической таблицы 'finance_storage', -- хранилище из шага выше 'marketing.sales' -- наследуем структуру столбцов отсюда ); -- Наполняем аналитическую таблицу данными из Postgres SELECT metastore.copy_table( 'sales_archive', 'SELECT * FROM marketing.sales' ); -- Создаём представление marketing.sales_archive. -- После этого клиент работает с ним теми же SQL-запросами, -- что и с обычной таблицей Postgres — переписывать ничего не нужно. -- Разница только в скорости: данные читаются не из строчных таблиц, -- а из Parquet-файлов в S3 через векторный движок AXE. SELECT metastore.create_view('sales_archive', 'marketing');
После этого запросы к marketing.sales_archive летят через векторный движок AXE, а не через строчное хранилище PostgreSQL.
Разграничение прав: аналитики и продажники в одной системе
Разграничение прав в AXE реализуется через специальные хранимые процедуры pgpro_metastore — они управляют доступом к аналитическим таблицам, не затрагивая внутренние структуры хранилища. Подробные примеры с конкретными командами — в документации Postgres Pro AXE.
Практический вопрос: сколько ресурсов нужно
Объём необходимых ресурсов зависит от нагрузки, объёма обрабатываемых данных и требований к скорости отклика.
Ориентир для планирования: на каждый активный конкурирующий аналитический запрос - не менее 4 физических ядер, 6 ГБ ОЗУ на каждое ядро
При смешанной OLTP+OLAP нагрузке OLTP-ресурсы планируются сверху. Именно поэтому мы рекомендуем использовать AXE на реплике, а не на мастере: реплика утилизирует простаивающие мощности, не создавая конкуренции с транзакционной нагрузкой.
Итого: кому и зачем нужен AXE?
Мы создавали Postgres Pro AXE для тех, кто устал от сложности и хочет быстро собрать рабочее аналитическое решение под задачу. Для команд, которые хотят просто писать SQL-запросы и получать результат мгновенно, не задумываясь о том, где лежат данные — в оперативной памяти, на NVMe-диске или в холодном S3-хранилище.
AXE решает три главные задачи:
Быстрые ответы из больших данных: до 30 раз быстрее обычного Postgres на аналитических запросах — и так вплоть до терабайтов и петабайт данных.
Экономия на инфраструктуре: меньше затрат на отдельные серверы под DWH и поддержку ETL-инструментов. Поддерживать AXE могут те же специалисты, которые уже работают с Postgres Pro.
Спокойствие команды: привычный диалект PostgreSQL, знакомые принципы администрирования и безопасности — как в привычном Postgres Pro Enterprise. Переучиваться не нужно.
Если вы хотите проверить, как AXE справится с вашими историческими данными или тяжелыми отчетами, его можно протестировать бесплатно. Оставьте заявку на нашем сайте, и мы поможем развернуть пилот на вашей инфраструктуре.
А пока — делитесь в комментариях: сколько костылей в ваших ETL-пайплайнах прямо сейчас?
