Разгрузка PostgreSQL: построение операционных витрин данных на базе Tarantool

Разгрузка PostgreSQL: построение операционных витрин данных на базе Tarantool

При росте нагрузок производительность СУБД снижается. Стандартный путь масштабирования PostgreSQL (оптимизация запросов, индексы, вертикальный Scale-Up и read-реплики) в долгосрочной перспективе ведет к тупику. Стоимость инфраструктуры растет быстрее нагрузки, а транзакционная база становится единым бутылочным горлышком системы.

В этом материале мы разберем альтернативный архитектурный паттерн — разделение контуров чтения и записи (Read/Write Split) с использованием In-Memory СУБД Tarantool в качестве операционной витрины данных. PostgreSQL при этом остается мастер-системой и надежно фиксирует транзакции, а Tarantool берет на себя нагрузку по чтению денормализованных объектов, обеспечивая субмиллисекундный отклик при пиковых запросах.

Архитектурный тупик: почему реплики не спасают

Рассмотрим типичный сценарий: по мере роста бизнеса увеличивается число микросервисов, которым нужен доступ к данным клиентов, транзакциям, договорам и лимитам. Первоначально все запросы направляются напрямую в PostgreSQL. Вскоре СУБД начинает перегружаться, а оптимизация запросов, индексы и увеличение мощности серверов дают лишь временную передышку при росте инфраструктурных расходов.

Когда предел масштабирования исчерпан, архитекторы прибегают к репликации: создаются read-реплики для SELECT-запросов. Но этот подход решает проблему лишь временно, поскольку репликация масштабирует копии PostgreSQL, но не меняет сам характер запросов. Репликам все так же приходится выполнять ресурсоемкие JOIN-операции соединения таблиц, вычислять агрегации в реальном времени, производить сортировку и сложные вычисления при каждом обращении клиента.

С ростом объема данных каждый SELECT требует сканирования все большего количества страниц памяти. Если сервису нужен профиль клиента, включающий информацию из таблиц clients, contracts, accounts, limits и risk_profiles, PostgreSQL на каждый запрос собирает эти данные заново. В условиях высокой нагрузки (highload) выполнение JOIN-операций превращается в колоссальную нагрузку. Замена PostgreSQL на распределенную SQL-базу — процесс крайне рискованный и долгий, так как вокруг зрелой СУБД завязаны десятки внутренних процессов, интеграций и легаси-кода.

Разделение контуров и концепция операционной витрины

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

Поскольку в большинстве бизнес-приложений доля операций чтения превышает 80–90% от общего объема трафика, разгрузка именно этого направления дает максимальный эффект. Вместо того чтобы заставлять реляционную СУБД собирать профили на лету, мы храним уже собранные, готовые к отдаче денормализованные объекты в отдельном быстродействующем слое — операционной витрине данных (Data Mart).

Схема работы контура:

1. Контур записи (Write Path): Все транзакционные операции, создание новых записей и расчетные процессы осуществляются в PostgreSQL. Эта база остается единственным источником истины и гарантом консистентности (ACID).
2. Контур доставки данных (Data Delivery Path): Любые изменения в таблицах PostgreSQL автоматически перехватываются СУБД и мгновенно доставляются в витрину без участия бизнес-логики приложений.
3. Контур чтения (Read Path): Клиентские микросервисы больше не обращаются к PostgreSQL для отображения данных пользователям. Все SELECT-запросы направляются в операционную витрину данных, которая мгновенно отдает денормализованные плоские объекты по первичному ключу.

В качестве витрины отлично подходит Tarantool. Благодаря In-Memory архитектуре (хранению данных в оперативной памяти), встроенному компилятору Lua и поддержке сложных структур данных, Tarantool обеспечивает субмиллисекундный отклик при выполнении миллионов запросов в секунду (RPS) на обычном оборудовании.

Схема доставки данных через Tarantool CDC (TCDC)

Ключевым условием успешной работы такой архитектуры является автоматическая доставка изменений из PostgreSQL в Tarantool. Двойная запись на уровне прикладного кода (когда приложение пишет одновременно в обе базы) недопустима, так как ведет к рассинхронизации при сетевых сбоях.

Для безопасной доставки изменений используется технология Change Data Capture (CDC) и готовый продукт Tarantool CDC (TCDC). Он подключается к PostgreSQL в качестве клиента репликации и читает WAL-логи.

Синхронизация витрины состоит из двух этапов:

1. Холодный импорт (Cold Import): При первоначальном запуске TCDC осуществляет первичное наполнение витрины — вычитывает текущее состояние таблиц PostgreSQL и переносит его в пространства Tarantool.
2. Подписка на изменения (Subscription to Changes): После завершения импорта TCDC переходит в режим реального времени. Как только в PostgreSQL происходит фиксация транзакции, изменяющей строку в отслеживаемых таблицах, TCDC перехватывает это событие и отправляет его в Tarantool.

Преимущество TCDC заключается в том, что он работает асинхронно и не создает дополнительной транзакционной нагрузки на PostgreSQL. Процесс репликации WAL-логов отделен от выполнения основных бизнес-транзакций, благодаря чему время отклика на операциях записи в мастер-системе не увеличивается.

Как устроен денормализованный объект витрины

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

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

В Tarantool денормализованный профиль клиента (ClientProfile) может быть представлен в виде плоского JSON-документа:

{
  "client_id": 12345,
  "client_name": "ООО Ромашка",
  "contracts_count": 5,
  "active_limit": 1000000,
  "risk_level": "LOW",
  "last_transaction_date": "2026-08-15"
}

Когда внешнему микросервису требуется отобразить личный кабинет клиента, он делает один простой запрос в Tarantool по ключу client_id. Tarantool мгновенно извлекает этот JSON-документ. Нет необходимости выполнять JOIN-ы, агрегировать количество договоров или искать дату последней транзакции. Все расчеты производятся один раз в момент изменения данных в PostgreSQL и записываются в Tarantool в уже готовом виде.

Бизнес-эффект и экономика решения

Перенос нагрузки на чтение в операционную витрину на базе Tarantool дает ощутимый экономический и технический эффект:

• Снижение темпов роста инфраструктурных затрат: Вместо закупки read-реплик PostgreSQL с большими дисковыми массивами компания разворачивает компактный кластер Tarantool. Требования к дисковой системе при этом резко снижаются.
• Отказ от расширения PostgreSQL на ближайших этапах: Извлечение 90% трафика на чтение из основной БД позволяет зафиксировать конфигурацию серверов PostgreSQL, продлевая жизненный цикл существующего оборудования.
• Стабильный пользовательский опыт (Predictable Latency): Время отклика при чтении из Tarantool измеряется единицами миллисекунд и практически не зависит от общего объема данных в системе.
• Изоляция и автономность сервисов: Сбои или замедление работы аналитических систем в PostgreSQL больше не блокируют работу клиентских сервисов.

Риски, компромиссы и когда витрина не нужна

Несмотря на преимущества, внедрение операционной витрины данных сопряжено с определенными компромиссами:

• Усложнение инфраструктурного ландшафта: В системе появляется новый критически важный компонент, который требует администрирования, настройки бэкапов, развертывания отказоустойчивых конфигураций и мониторинга.
• Согласованность данных в конечном счете (Eventual Consistency): Поскольку доставка изменений через CDC происходит асинхронно, присутствует небольшая задержка обновления данных. Если бизнес-процесс требует мгновенного отображения изменений, чтение должно производиться из PostgreSQL.
• Необходимость контроля CDC-лага: Требуется настроить мониторинг пропускной способности канала доставки изменений. Если TCDC начнет отставать от WAL-логов, пользователи увидят устаревшие данные.
• Когда внедрение избыточно: Если загрузка PostgreSQL не превышает 20–30%, а задержки выполнения запросов устраивают бизнес, внедрение витрины принесет лишь лишние накладные расходы. Также паттерн не подходит для OLAP-систем со сложными ad-hoc запросами.

В сухом остатке, операционная витрина данных на базе Tarantool — это мощный инструмент масштабирования, позволяющий разгрузить PostgreSQL и остановить рост инфраструктурных расходов. Оставляя транзакционную СУБД делать то, в чем она сильна — надежно фиксировать изменения, мы переносим ресурсоемкую логику сборки и отдачи готовых объектов туда, где она выполняется с максимальной эффективностью.