PostgreSQL без компромиссов: как получить горизонтальное масштабирование, более 5000 соединений и полноценный HTAP
Рост нагрузки в бизнес-приложениях рано или поздно упирается в возможности СУБД. Классический PostgreSQL, как и его коммерческие модификации (форки), рано или поздно перестают справляться: запросы выполняются дольше, большое количество одновременных подключений замедляет систему, а попытки запустить сложную аналитику сталкиваются с ограничениями масштабирования и параллелизма. Разработчики «Тантор Лабс» предложили ответ на эти вызовы — программно-аппаратный комплекс Tantor XData Gen3. CNews разбирается, как устроена новинка и какие инфраструктурные барьеры она снимает.
Архитектурный потолок классического PostgreSQL
Проблема одномашинной инсталляции открытой СУБД не нова, но ее острота в эпоху требований к отказоустойчивости и скорости реакций возрастает. Процессорные ядра и память не масштабируются бесконечно. Каждое новое подключение в стандартном PostgreSQL — это отдельный процесс операционной системы. При 5000+ одновременных сессий операционная система тратит больше времени на переключение контекста между процессами, чем на выполнение самих запросов. Еще до этого рубежа наступает момент, когда вертикальное масштабирование (замена сервера на более мощный) становится экономически неоправданным.
На рынке представлено множество коммерческих модификаций (форков) и разнообразных надстроек, идея которых — в той или иной степени «додавить» архитектуру. Многие российские компании становятся перед выбором: мириться с деградацией производительности или строить сложные и дорогие инфраструктуры из нескольких разнородных систем.
При попытке масштабировать «ванильный» PostgreSQL до корпоративного уровня компании сталкиваются с несколькими ключевыми ограничениями.
Во-первых, наиболее быстро сказываются пределы одного сервера: дальнейшее наращивание производительности требует дорогого «железа» и дает все меньший эффект. Вертикальное масштабирование становится экономически невыгодным: проблема в том, что стоимость растёт нелинейно: сервер с 512 ГБ оперативной памяти обходится не в два, а в 3–4 раза дороже сервера с 256 ГБ. Для enterprise-конфигурации (16–32 ядра, 256–512 ГБ RAM, NVMe-накопители) только один сервер обойдётся в 1,5–5 млн рублей, а с резервированием (основной + реплика) — в 3–10 млн.
Во-вторых, шардинг (разделение данных на большие фрагменты на разных узлах) помогает справиться с ростом объёмов, но переносит часть задач СУБД на само бизнес-приложение. Например, если данные клиентов, заказов и остатков распределены по регионам, приложение должно понимать, на каком шарде находится нужная информация, правильно направлять запросы и учитывать распределение данных при выполнении JOIN и других операций. При изменении нагрузки или структуры данных эта логика тоже должна меняться. В результате бизнес-приложение начинает фактически участвовать в управлении физическим размещением данных, хотя в классической архитектуре это задача СУБД. Работа сложных запросов значительно ухудшается, разработка и поддержка усложняются, возрастают риски ошибок. В итоге шардинг PostgreSQL становится самой дорогой «оптимизацией», потому что ее основная стоимость — не инфраструктура, а человеко-часы. Опросы показывают, что на управление данными в enterprise-сегменте уходит около 10% всего ИТ-бюджета, причём 75% этих расходов — оплата труда, а не софт или инфраструктура. Только на зарплату команды поддержки шардированной PostgreSQL может уходить 6–14 млн рублей в год — и это без учёта стоимости разработки, которая замедляется из-за архитектурной сложности.
В‑третьих, для аналитики часто разворачивают отдельную (аналитическую) СУБД, из‑за чего возникает постоянная проблема синхронизации данных: между транзакционной системой и аналитикой неизбежно появляются задержки. В итоге компания получает рост сложности архитектуры и эксплуатационных затрат, в том числе на сопровождение разных СУБД — а это уже прямые издержки и риски для бизнеса. Вынос аналитики в отдельную СУБД по существу означает, что компания платит за две инфраструктуры вместо одной. Но главная стоимость — не «железо», а ETL-конвейеры синхронизации: по отраслевым данным, организация сбора и перекладывания данных может потреблять до 80% трудозатрат проекта.
Их три: упор в предел возможностей одного сервера, необходимость вынесения части логики СУБД в бизнес-приложения при использовании компромиссных технологий наподобие шардинга и проблемы синхронизации данных между транзакционным и аналитическим контурами. На практике все эти ограничения приводят как к усложнению архитектуры, так и к неявным финансовым потерям, которые при принятии решений часто недооценивают. Вообще, негативные стороны выбранной архитектуры проявляются не сразу. ИТ-подразделения, не являясь экономистами, обычно оценивают компромиссные решения прежде всего с точки зрения технической реализуемости и среднесрочной эксплуатации, и не подсвечивают бизнесу потенциальный ущерб. А бизнесу как раз важно учитывать и стоимость дополнительных человеко-часов, и замедление разработки, и рост инфраструктурных расходов.
Совокупно попытка «в лоб» масштабировать один сервер PostgreSQL до enterprise-уровня может доходить до десятков млн рублей в год, и для финансовых директоров это вопрос, который стоит поднимать до принятия архитектурных решений, а не после. И все это — без учёта упущенной выгоды от замедления разработки и невозможности быстро внедрять новые функции для бизнеса из-за архитектурной сложности.
Когда технологий слишком много
Отдельный аспект — это выстраивание возможности одновременно работать с транзакциями и аналитикой. В отличие от enterprise-систем, изначально спроектированных для одновременной работы со смешанными нагрузками, в PostgreSQL-системах применяются своего рода «комбо-конфигурации», связки из нескольких систем. Транзакционная нагрузка (Online Transaction Processing, OLTP) остается на PostgreSQL, а для аналитики (Online Analytical Processing, OLAP) внедряется отдельный движок, такой как Greenplum, DuckDB или ClickHouse. Снаружи это выглядит как современное решение, но внутри это возврат к архитектурам двадцатилетней давности, маскирующий старые проблемы под новыми названиями.
Данные начинают жить двойной жизнью. Между базами выстраиваются конвейеры извлечения, преобразования и загрузки (Extract, Transform, Load, ETL) и механизмы захвата изменений данных (Change Data Capture, CDC), которые перегружают данные, преобразуют их, синхронизируют и поддерживают консистентность. Это порождает задержки: данные для аналитики всегда оказываются «вчерашними». К тому же, система тратит драгоценные ресурсы не на выполнение запросов, а на поддержание согласованности между двумя контурами обработки. Помимо роста инфраструктурных затрат, появляется и когнитивный барьер для команд разработки: один SQL-диалект — в PostgreSQL, другой — в аналитическом движке со своими форматами хранения и логикой выполнения.
Подводных камней несколько. Во-первых, это постоянные расходы на синхронизацию данных между системами. Поддержка ETL может составлять до 80% трудозатрат, что эквивалентно 3–8 млн рублей в год. Во-вторых, возникает задержка в данных. Решения на основе устаревших данных могут приводить к прямым финансовым потерям, особенно в сферах, где важна оперативность — антифрод, динамическое ценообразование. Эти задержки могут стоить бизнесу упущенной выгоды и дополнительных рисков.
Также задваиваются затраты на разработку и поддержку. Команде приходится управлять двумя разными моделями данных и инструментами, что замедляет вывод новых функций и увеличивает риск ошибок. В итоге бизнес несёт существенные потери в десятки млн рублей в год на поддержание раздельной архитектуры, не считая рисков простоев и упущенной выгоды из-за задержек в данных.
Tantor XData Gen3: настоящий HTAP
Термин «гибридная транзакционно-аналитическая обработка» (Hybrid Transactional/Analytical Processing, HTAP) перестал быть просто модным словом. Китайские вендоры, такие как Alibaba с платформой PolarDB, уже активно внедряют подобные архитектуры у себя. Но в России до недавнего времени не было продукта, который предлагал бы целостное решение.
«Тантор Лабс» представила машину баз данных (МБД) третьего поколения — Tantor XData Gen3, которая переосмысляет саму архитектуру PostgreSQL, а не просто создает очередную надстройку. В основе – 100% совместимая с PostgreSQL распределенная СУБД Tantor Polar с разделением вычислительных мощностей (Compute) и хранилища (Shared Storage).
Узлы кластера в Gen3 не хранят собственную копию данных, а работают с единым физическим слоем хранения. Это решает главную проблему масштабирования: добавление нового вычислительного узла для выполнения аналитического запроса не требует дорогостоящей репликации всей базы данных. Система использует распределенный движок на базе оптимизатора GPORCA (Greenplum ORCA — оптимизатор параллельных запросов) для параллельной обработки запросов. Для колоночных данных, когда запросу нужны только несколько полей из широкой таблицы, задействуется расширение с векторным выполнением, дающее экономию ресурсов.
Масштабирование и надежность на новом уровне
Одной из заявленных целей при создании Gen3 было преодоление барьера подключений. Встроенный на уровне ядра диспетчер подключений мультиплексирует тысячи клиентских сессий в пул процессов PostgreSQL. Внутренние тесты продукта демонстрируют уверенную работу при 5000 одновременных сессиях с сохранением времени отклика в десятках миллисекунд. Для сравнения: в стандартных конфигурациях при 5000 подключений ресурсы сервера истощаются еще до выполнения первого запроса.
Надежность всей конструкции обеспечивается посегментной репликацией. При отказе координатора или рабочего узла система автоматически переключается на реплику без потери целостности данных. Администратор получает единую консоль мониторинга для наблюдения за состоянием всех компонентов, а процесс добавления нового узла не требует остановки кластера.
При шардинге данные физически режутся на части и раскладываются по разным серверам. Например, отчёт по продажам за год в разрезе регионов приходится собирать из кусков, разбросанных по нескольким узлам. Это добавляет сетевые задержки, усложняет выполнение и делает время ответа непредсказуемым: один и тот же запрос может отработать за секунды, а может — за минуты, в зависимости от того, как легли данные. Отдельный отчет, пожалуй, можно и подождать, но там, где скорость получения данных напрямую влияет на выручку, это неприемлемо. То же касается и работы ИИ-агентов, их эффективность при работе на устаревших данных существенно снижается.
В архитектуре Tantor XData Gen3 данные остаются едиными, аналитика всегда работает с актуальной информацией, а время выполнения запросов всегда предсказуемо. Если говорить о деньгах, то, во-первых, исчезает необходимость держать команду для поддержки шардированного кластера — экономия ФОТ может достигать десятков млн рублей в год. Во-вторых, не нужен отдельный ETL-конвейер для аналитики, потому что аналитические запросы выполняются прямо на актуальных данных — еще миллионы рублей экономии ежегодно. В-третьих, предсказуемая производительность снижает риск просадок в пиковые моменты, когда стоимость простоя измеряется сотнями тысяч, а иногда и миллионами рублей в час. Совокупно переход на архитектуру с разделением Compute и Storage может сэкономить компании как деньги, так и время экспертов, которое можно потратить на более интеллектуальные задачи для помощи бизнесу, и при этом дать аналитику, которая работает не на неактуальной копии, а на текущих данных в реальном времени.
Практический итог: PostgreSQL корпоративного уровня (Enterprise) без переписывания приложений
Для бизнеса ключевой риск любых новых платформ данных — это миграция приложений. В большинстве случаев она означает переработку SQL, логики работы с данными, интеграций и тестирования всей системы.
В Tantor XData Gen3 этот риск снимается за счет полной совместимости с PostgreSQL. Извне, со стороны SQL, приложений и расширений, система выглядит как обычный PostgreSQL. Архитектурные изменения находятся не на уровне приложений, а ниже, внутри системы — в слое хранения, распределения вычислений и выполнения запросов. Платформа берет на себя масштабирование и управление нагрузкой, не требуя изменений в существующем коде. Бизнес получает возможность нарастить производительность и масштаб системы без проекта переписывания приложений и без остановки развития текущих систем.
Практический итог внедрения Tantor XData Gen3 — снижение совокупной стоимости владения (TCO). По данным производителя, миграция на Gen3 позволяет сократить парк серверов на 30–40% за счет более эффективной утилизации ресурсов. Бизнес получает возможность для роста без радикальной перестройки ИТ-ландшафта, начиная с малого и постепенно наращивая мощности, сохраняя при этом единый, привычный стек разработки на PostgreSQL.
Развитие идёт по четырём направлениям, и каждое из них имеет прямой бизнес-смысл.
Первое — аналитический контур: колоночное хранение и развитые механизмы параллельного выполнения запросов. Итог – секунды на получение данных вместо минут и, как следствие, максимальная скорость и точность принятия решений, что особенно важно там, где ценность данных падает с каждой минутой: динамическое ценообразование, маркетинговые кампании, антифрод и т.д. Отчет, на который смотрит человек, — в 2026 году это уже неактуально: на данные смотрит ИИ-агент и мгновенно дает рекомендации для человека.
Второе — транзакционный контур: новые механизмы распределения нагрузки и мультиплексирования. Цель — в том, чтобы система держала пиковые нагрузки без деградации. Чёрная пятница, конец отчётного периода, запуск массовой рассылки — в эти моменты обычный PostgreSQL начинает «задыхаться», и бизнес либо мирится с замедлением, либо держит запасные ресурсы, которые 90% времени простаивают. В нашем случае система будет справляться и с пиками, и с обычной нагрузкой — это прямой вклад в снижение TCO.
Третье — ИИ-сценарии. Сегодня большинство компаний строят ML-модели и ИИ-агентов на данных, выгруженных через ETL, то есть на вчерашнем снимке. Мы делаем базу данных источником актуальных данных для моделей в реальном времени. Антифрод-модель реагирует на транзакцию за миллисекунды, а не после того, как данные дошли через конвейер. Рекомендательная система учитывает последнюю покупку, а не состояние на начало дня. В деньгах это разница между «предотвратили мошенничество на 100 тысяч» и «обнаружили его на следующий день, когда деньги уже ушли».
Четвёртое — собственный механизм обработки данных XDP: работа с памятью, кэшем, сетевым взаимодействием через RDMA, оптимизация трафика WAL и блокировок. Звучит технически, но бизнес-эффект конкретный: меньше задержек, выше утилизация серверов, ниже нагрузка на сеть. На практике это означает, что на одних и тех же серверах система может обрабатывать больше запросов.
Совокупно план развития Tantor XData Gen3 на ближайшие год-два сводится к тому, чтобы дать бизнесу не суррогаты, а лучшие технологии: аналитику в реальном времени, устойчивость к пикам и готовность к ИИ без роста инфраструктурных затрат.»
Рекламодатель: ООО «ТАНТОР ЛАБС»
ИНН/ОГРН: 9701183207/1217700399949
Сайт: https://tantorlabs.ru/