Каждый раз, когда в компании возникают проблемы с производительностью PostgreSQL, обсуждение обычно идет по одному и тому же сценарию.
Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.
Недавно мы в Tarantool столкнулись именно с такой ситуацией у одного из клиентов. В этой статье расскажем подробно об этой ситуации, поделимся, как мы ее решили и почему такой подход в целом стоит использовать практически всем, кто имеет дело с PostgreSQL.
Описание проблемы
У клиента была хорошо знакомая многим архитектура. PostgreSQL выступал мастер-системой и источником истины для бизнеса. Внутри базы хранились данные, необходимые для расчетов. Отдельные сервисы периодически забирали эти данные, выполняли вычисления и записывали результаты обратно. После этого десятки других сервисов использовали уже рассчитанные данные для своей работы.
Схема выглядела примерно так:
На первый взгляд все выглядело правильно, но:
количество данных росло;
количество сервисов росло;
количество пользователей росло.
А вместе с ними росли и счета за инфраструктуру.
Самое опасное решение — заменить PostgreSQL
В такие моменты часто появляются радикальные идеи: перейти на другую БД, переписать все на новый стек, перенести данные в распределенную систему. На практике подобные проекты редко бывают дешевыми и быстрыми.
Важно помнить, что PostgreSQL является одной из самых надежных и зрелых СУБД на рынке. Во многих компаниях вокруг нее построены десятки сервисов, процессов и интеграций. Поэтому мысль просто взять и заменить PostgreSQL обычно вызывает примерно такую же реакцию, как предложение заменить фундамент у уже построенного дома.
Технически возможно, но на практике — крайне болезненно. Поэтому мы начали искать другой путь.
А точно ли проблема в PostgreSQL
Когда мы начали разбирать нагрузку, оказалось, что большая часть ресурсов PostgreSQL тратится вовсе не на транзакции и даже не на запись данных. Основная нагрузка приходилась на чтение, причем зачастую сервисам были нужны не исходные данные, а уже готовый результат расчетов.
Приведем упрощенный пример. В PostgreSQL хранятся:
clients
contracts
accounts
limits
transactions
products
risk_profilesСервису нужен ответ вида:
{
"client_id": 123,
"active_limit": 100000,
"contracts": 5,
"risk_level": "LOW"
}Чтобы получить его, база данных каждый раз выполняет:
несколько JOIN;
агрегации;
сортировки;
вычисления.
Когда запрос один — это не проблема. Когда их сто тысяч в секунду — это совсем другая история. Но зачем заставлять PostgreSQL каждый раз собирать один и тот же ответ?
Не база данных, а пути данных
Вместо очередной реплики PostgreSQL мы решили посмотреть на систему целиком. Если сервисам нужен готовый результат расчетов, возможно стоит хранить этот результат отдельно от исходных данных. Так появилась идея операционной витрины данных.
В этой системе PostgreSQL остается источником истины и все транзакции продолжают выполняться именно в нем. Расчетные сервисы тоже продолжают работать как раньше. Но результат расчетов начинает поставляться в отдельное высокопроизводительное хранилище, оптимизированное под чтение.
Архитектура начинает выглядеть так:
В роли витрины данных может выступать не только Tarantool. Подойдет любая технология, которая соответствует требованиям вашей компании по производительности, надежности, стоимости владения и эксплуатационным процессам.
Почему это дешевле
На первый взгляд кажется, что раз мы добавляем еще одну систему, то расходы должны только вырасти. Но на практике экономика часто работает наоборот.
Представьте компанию, которая ежегодно увеличивает нагрузку на 30–50%. Каждый новый этап роста приводит к покупке:
новых серверов PostgreSQL;
дополнительной памяти;
новых реплик;
дополнительных мощностей для резервного копирования;
А еще к увеличению затрат на сопровождение.
Через несколько лет стоимость владения начинает расти быстрее самой нагрузки. В такой ситуации инвестиции в специализированный слой данных могут оказаться дешевле постоянного горизонтального масштабирования основной базы данных. Фактически компания покупает не еще одну базу данных, а возможность наконец перестать бесконечно наращивать инфраструктуру PostgreSQL.
Что получает бизнес
Если посмотреть на ситуацию глазами CTO или руководителя платформенной команды, преимущества выглядят не как «база стала быстрее». Гораздо важнее другое. Компания получает возможность:
отложить масштабирование PostgreSQL;
уменьшить количество реплик;
снизить требования к вычислительным ресурсам;
сократить расходы на инфраструктуру;
ускорить работу клиентских сервисов;
сделать время ответа более предсказуемым.
Особенно хорошо подобный подход работает в системах, где доля операций чтения превышает 80–90%.
Когда такой подход не нужен
Любая архитектурная оптимизация имеет свою цену. Если PostgreSQL загружен на 20–30%, а бизнес не испытывает проблем с производительностью, строить отдельную витрину данных, скорее всего, не имеет смысла. Но если каждое новое бизнес-требование заканчивается покупкой дополнительных серверов, возможно стоит задать себе вопрос: мы действительно масштабируем данные или на самом деле масштабируем архитектурную ошибку?
Что делать на практике
Если вы решили отделить контур хранения данных от контура доставки данных, то на чем строить такую витрину? Вариантов достаточно много: это и Elasticsearch, и Redis, и специализированные кэши.
В нашем случае нужно было:
быстро доставлять данные сервисам;
поддерживать постоянную синхронизацию с PostgreSQL;
работать с готовыми объектами данных;
не заставлять команды переписывать существующие приложения;
не превращать решение в еще один инфраструктурный проект на год.
Поэтому в качестве витрины данных мы предложили клиенту использовать Tarantool Database.
Как мы реализовали витрину данных
PostgreSQL продолжил выполнять роль мастер-системы и источника истины. Все бизнес-транзакции, расчеты и процессы записи остались на своих местах. Мы не меняли существующие процессы и не заставляли команду переписывать приложения — изменился только путь доставки данных до сервисов.
Изменения из PostgreSQL начали передаваться через CDC в Tarantool, где формировались уже готовые представления данных для клиентских сервисов. В результате сервисы перестали обращаться напрямую к PostgreSQL за каждым запросом. Для них появилась специализированная витрина данных, содержащая уже подготовленные объекты.
Как данные попадали в витрину
Здесь может возникнуть опасение: получается, что данные придется записывать сразу в две системы? На практике это не так.
PostgreSQL продолжает оставаться единственной системой записи. После изменения данных информация автоматически передается через TCDC (Tarantool Change Data Capture) в Tarantool DataBase.
То есть приложения продолжают работать с PostgreSQL как и раньше, а витрина данных получает изменения автоматически и поддерживает актуальное состояние данных. С точки зрения разработчиков ничего принципиально не меняется, но чтение и запись начинают жить в разных контурах.
Как выглядит объект витрины
Представьте, что информация о клиенте хранится в нескольких таблицах:
clients
accounts
contracts
limits
transactions
risk_profilesДля большинства сервисов вся эта структура избыточна, ведь им нужен уже готовый результат. Поэтому в витрине данных формируется объект наподобие такого:
{
"client_id": 12345,
"client_name": "ООО Ромашка",
"contracts_count": 5,
"active_limit": 1000000,
"risk_level": "LOW",
"last_transaction_date": "2026-08-15"
}Для клиентского сервиса это уже полноценный объект ClientProfile: без JOIN, агрегаций и дополнительных вычислений. То есть сервис получает ровно те данные, которые необходимы ему для работы.
Что изменилось для бизнеса
На этапе обсуждения проекта клиент не спрашивал про производительность, RPS или миллисекунды. Его интересовало, как долго существующая архитектура сможет выдерживать рост нагрузки без очередной закупки оборудования.
А возник именно такой вопрос вот почему. В компании запускался новый цифровой продукт, и, по прогнозам команды, количество запросов к данным должно было вырасти почти вдвое в течение ближайшего года.
Первый вариант решения выглядел привычно: увеличить ресурсы PostgreSQL и подготовить дополнительные read-replica. Но при оценке стоимости стало понятно, что инфраструктурные расходы будут расти практически теми же темпами, что и бизнес-нагрузка. По предварительной оценке, в течение ближайшего года потребовалось бы развернуть как минимум две новые read-replica PostgreSQL для обслуживания растущего числа сервисов и пользователей.
Именно тогда команда начала искать способ масштабировать потребление данных без бесконечного масштабирования основной базы данных.
После появления операционной витрины данных большая часть запросов на чтение ушла из PostgreSQL. Это позволило отказаться от планов по развертыванию дополнительных реплик на ближайшем этапе развития платформы и использовать существующие мощности значительно дольше.
То есть задача проекта заключалась не в том, чтобы ускорить PostgreSQL. Задача заключалась в том, чтобы рост бизнеса перестал автоматически приводить к росту инфраструктурных расходов. Именно этот эффект оказался наиболее ценным для заказчика.
Какие метрики действительно улучшились
Предсказуемость затрат. Команда получила более понятный горизонт планирования инфраструктуры. Вместо регулярных обсуждений очередного масштабирования PostgreSQL появилась возможность использовать существующие мощности значительно дольше.
Скорость запуска новых сервисов. Раньше появление нового сервиса автоматически означало увеличение нагрузки на мастер-систему. Каждая новая команда становилась еще одним потребителем PostgreSQL. После появления витрины данных новые сервисы могли использовать уже подготовленные данные без дополнительной нагрузки на основную систему.
Снижение стоимости роста. Рост количества пользователей перестал автоматически означать рост количества серверов. Это не означает, что инфраструктура перестала расти совсем. Но стоимость обслуживания каждого нового клиента стала заметно ниже.
Устойчивость платформы. Одним из побочных эффектов стало снижение зависимости клиентских сервисов от текущего состояния PostgreSQL. Даже во время пиковых нагрузок на мастер-систему пользовательские сервисы продолжали получать данные из специализированной витрины.
Для бизнеса это означает более стабильный пользовательский опыт — а стабильность пользовательского опыта обычно конвертируется в конкретные показатели:
меньше обращений в поддержку;
меньше инцидентов;
меньше потерянных операций;
выше удовлетворенность пользователей.
Что оказалось самым ценным в этом проекте
Если попросить меня выделить главный результат такого подхода, я бы назвал не производительность или экономию. Самым ценным оказалось разделение ответственности между системами.
PostgreSQL продолжил заниматься тем, что умеет лучше всего: надежно хранить данные и обеспечивать консистентность. А витрина данных взяла на себя задачу быстрой доставки информации до клиентских сервисов.
На практике именно такое разделение позволило компании перестать рассматривать масштабирование инфраструктуры как единственный способ решения проблемы роста нагрузки.
Именно поэтому подобная архитектура может быть полезна не только крупным компаниям. Любая система, в которой количество операций чтения значительно превышает количество операций записи, рано или поздно сталкивается с похожими вопросами.
Заключение
За годы работы с высоконагруженными системами я заметил одну закономерность: когда система начинает упираться в ограничения, мы почти всегда сначала покупаем новое железо. Намного реже мы задаем вопрос, правильно ли вообще движутся данные внутри системы.
В случае нашего клиента PostgreSQL продолжил отлично выполнять свою работу. Мы не меняли фундамент — мы просто перестали использовать его в качестве несущей стены для всего здания. И именно это позволило масштабировать бизнес быстрее, чем инфраструктурные расходы.