Зачем менять архитектуру PostgreSQL для масштабируемых HTAP-систем вместо тюнинга?

Архитектура PostgreSQL для масштабируемых HTAP-систем — почему тюнинг не решит проблему

Команды пытаются получить HTAP на PostgreSQL через тюнинг и более мощные серверы. Это упирается в предел одного узла. Причина — ограничения самой СУБД и сети. Без разделения вычислений и хранения и без низких задержек в сети масштаб не растёт.

Выход — смена архитектуры. Tantor XData Gen3 предлагает именно её. Система сохраняет совместимость с PostgreSQL и 1С, поддерживает HTAP и заявляет кластерную отказоустойчивость. Тесты стартовали 7 апреля в Москве, промышленной эксплуатации пока нет. Дальше — что именно тормозит классический PostgreSQL и как это снимают.

Команды рассчитывают получить HTAP на PostgreSQL за счёт ресурсов и тюнинга. Добавляют CPU, память, реплики, иногда шарды. Ожидание простое: больше железа — больше пропускная способность.

Но классический PostgreSQL привязан к одному узлу. Его модель плохо масштабирует параллельную аналитику. Реплики помогают читать, но запись и координация остаются узким местом.

Без разделения ролей — вычислений, хранения и сети — система упирается в предел. Именно это меняет новая архитектура, а не очередной набор настроек.

Следствие прямое: растут затраты, падает стабильность. Вопрос упирается не в оптимизацию, а в устройство системы.

Featured image: htap postgres architecture

Как это работает

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

Почему возникает предел

Архитектура ориентирована на один пишущий узел. WAL и блокировки локальны. Реплики снимают нагрузку чтения, но не запись. Шардирование переносит сложность в приложение.

В Tantor XData Gen3 роли разделены. Есть слой вычислений и отдельное хранилище. Узлы связаны сетью RDMA с низкой задержкой. Добавлены параллельная обработка и конвейерная запись WAL. В ядро PostgreSQL внесено около 1,5 млн строк кода. Используются процессоры AMD EPYC.

К чему это приводит

Разделение убирает главный узкий участок. CPU и хранилище масштабируются независимо. Задержки при доступе к данным ниже, пропускная способность выше. Нагрузка распределяется между узлами.

При этом сохраняется совместимость с PostgreSQL и приложениями. Это снижает риск миграции. Но требуется новая сеть и кластерная инфраструктура.

Вывод

Масштабируемый HTAP на PostgreSQL требует смены архитектуры. Тюнинг не меняет базовые ограничения.

Подход	Вычисления vs хранилище	Сеть	Модель масштабирования	Совместимость	Модель отказоустойчивости	Ключевые технологии и ограничения
Классический PostgreSQL	Вычисления и хранение на одном узле; запись привязана к первичному серверу	Обычные сетевые стеки (TCP/IP); удалённый доступ с заметной задержкой	Вертикальное масштабирование; реплики для чтения — ограниченная горизонталь	Полная совместимость с PostgreSQL-приложениями	Primary–Replica; единый пишущий узел	Локальные WAL и блокировки; ограничена параллельная аналитика
Шардирование / тюнинг (наращивание ресурсов)	По сути тот же принцип — ресурсы на узле/шарде, но распределены логикой приложения	TCP/IP между шардами; межшардовые задержки	Горизонталь через шарды, но с повышенной сложностью операций	Совместимость сохраняется, но требуется логика в приложении	Множественные примарные узлы по шардам; сложное резервирование	Перенос сложности в приложение; межшардовые транзакции и консистентность — операционная нагрузка
Tantor XData Gen3	Разделение: независимые слои Compute и Storage; независимое масштабирование	RDMA низкой задержки для связи между узлами	Независимое масштабирование вычислений и хранилища; параллельная обработка	Сохранена совместимость с PostgreSQL и приложениями (например, 1С)	Tantor RAC: один пишущий, несколько читающих узлов; кластерная HA	Параллельная обработка, конвейерная запись WAL, CSN, балансировка нагрузки; ~1.5M строк кода в ядро PostgreSQL; AMD EPYC

Когда аналитика тормозит транзакции

Отчёт по большим таблицам замедляет операции. Аналитика забирает CPU и диск у того же сервера.

Добавление ресурсов помогает ненадолго. Очереди на запись и блокировки снова растут. Увеличивается задержка, падает стабильность SLA.

Это не про индекс. Это про устройство системы.

Когда масштабирование дорожает

Сервер меняют на более мощный — и получают временный эффект. Через время ограничения возвращаются, а бюджет растёт.

Связка вычислений и хранения увеличивает цену ошибки и сложность резервирования. Растёт стоимость владения.

Это сигнал к смене модели, а не к очередному апгрейду.

Когда шардирование усложняет жизнь

Базу делят на шарды, чтобы распараллелить нагрузку. Появляются межшардовые запросы и сбои.

Команды тратят время на согласование данных. Падает пропускная способность на сложных запросах.

Шардирование переносит проблему в приложение, но не убирает узкое место координации.

Практический эффект

Стабильнее выполняются SLA при росте аналитики. Нагрузка распределяется, а не давит на один сервер.

Затраты становятся предсказуемыми. Масштабируют нужный слой, а не весь узел целиком.

Снижается операционная нагрузка. Меньше межшардовых сценариев и ручной координации.

Параллельная обработка и балансировка повышают пропускную способность. Узкие места управляются на уровне кластера.

Цена — новая сеть и пересборка инфраструктуры. Но это контролируемые изменения, в отличие от бесконечных апгрейдов.

Проблема: HTAP пытаются вытянуть тюнингом и апгрейдом. Это лишь откладывает отказ одного узла.

Решение: архитектура PostgreSQL для масштабируемых HTAP-систем требует разделения вычислений и хранения и кластерной модели с низкими задержками. Такой подход демонстрирует Tantor XData Gen3. Тесты идут, промышленной эксплуатации пока нет.

Когда пора менять архитектуру:

аналитика влияет на транзакции и SLA
рост CPU и памяти не снижает задержки
шардирование усложняет операции и увеличивает ошибки
стоимость масштабирования растёт быстрее нагрузки

Вывод: если видите эти признаки, тюнинг не поможет. Нужна модель, где Compute, Storage и сеть проектируются вместе.

Вопросы и ответы

Можно ли получить масштабируемый HTAP на PostgreSQL только тюнингом?

Нет. Тюнинг и апгрейды сдвигают предел, но не убирают зависимость от одного пишущего узла. Нужны раздельные слои и низкие задержки сети.

Когда думать о смене архитектуры?

Когда аналитика мешает транзакциям и рост ресурсов не снижает задержки. Это признак системного ограничения.

Чем Tantor XData Gen3 отличается от шардинга?

Он разделяет вычисления и хранение и использует RDMA. Координация не уходит в приложение, поэтому исчезает часть узких мест.

Сохранится ли совместимость с приложениями, например 1С?

Да. Заявлена совместимость с PostgreSQL и приложениями, что снижает риски миграции.

Готово ли решение к промышленной эксплуатации?

Пока нет. Идут тесты на реальных системах. Перед внедрением разумно проводить пилоты.