Производительность СУБД на высоких нагрузках

Архитектурный контекст

Универсальные СУБД рассчитаны на широкий спектр нагрузок и оптимизированы под средний случай, в котором архитектурный компромисс приемлем. На высокочастотных задачах этот компромисс становится ограничивающим фактором.

PostgreSQL реализует многоверсионный параллелизм (MVCC) с общими структурами в оперативной памяти и периодической сборкой мусора (VACUUM). При одновременной работе десятков клиентских сессий на многоядерных процессорах система упирается в конкуренцию потоков за разделяемые ресурсы: буферные пулы, блокировки, кэши. Увеличение количества процессорных ядер приносит всё меньший прирост производительности.

In-memory СУБД SAP HANA снимает часть этих ограничений за счёт полной резидентности данных в оперативной памяти и колоночного хранения, но сохраняет shared-memory архитектуру и требует вертикального масштабирования на серверах промышленного класса. Стоимость такой инфраструктуры на крупных инсталляциях становится существенным фактором совокупной стоимости владения.

Архитектурное решение: shard-per-core и shared-nothing

Класс архитектурных решений shard-per-core с shared-nothing распределением реализует принципиально другой подход. Каждое процессорное ядро обслуживает собственный независимый шард данных без конкуренции за разделяемые ресурсы. Внутри шарда применяется кооперативная многозадачность без блокировок. Это обеспечивает линейное масштабирование производительности при добавлении ядер и узлов кластера.

Среди публично известных реализаций этого класса — ScyllaDB (Cassandra-совместимая) и Redpanda (Kafka-совместимая). Picodata относится к тому же классу и расширяет его полноценной поддержкой SQL, ACID-транзакций на основе Raft-консенсуса и плагинной моделью для добавления сетевых протоколов (Redis через плагин Radix, Cassandra CQL через плагин Sirin).

Реализация на языках Rust и C исключает паузы от сборки мусора, характерные для систем на Java, и обеспечивает предсказуемое p99-время отклика.

Кейс: высокочастотные очереди сообщений (СМЭВ)

Команда разработки Системы межведомственного электронного взаимодействия (СМЭВ) от РТ Лабс опубликовала открытый технический доклад о миграции с PostgreSQL на платформу, технологически родственную Picodata. Нефункциональные требования СМЭВ включали скорость обмена не менее 200 000 RPS, пропускную способность не менее 500 МБ/с и доступность не ниже 99,99%.

На нагрузке 1 миллион запросов в секунду в очередях сообщений PostgreSQL-решение требовало 4760 процессорных ядер при p99-латентности 320 мс. Миграция на shared-nothing архитектуру сократила потребление процессорных ядер до 770 (в шесть раз меньше серверных мощностей) при одновременном снижении p99-латентности до 130 мс.

Ключевые технические причины разницы: отсутствие периодической сборки мусора, распределённый индекс с константным временем поиска и удаления, а также отсутствие необходимости многоверсионного параллелизма для workload-а очереди сообщений.

Открытый доклад РТ Лабс и Picodata «От PostgreSQL к Tarantool» — полная методология и сырые цифры →

Кейс: параллельный расчёт себестоимости (Picodata Silver)

Плагин Picodata Silver реализует распределённый расчёт себестоимости методом прямого поглощения затрат. Алгоритм работает над графом, в котором вершины представляют центры возникновения затрат (ЦВЗ), а рёбра — коэффициенты распределения между ними. При наличии встречных поставок (циклических зависимостей между ЦВЗ) алгоритм применяет итеративное приближение до сходимости с заданной погрешностью.

До введения санкций на российском рынке золотым стандартом для этой задачи были продукты SAP (FSPER, Controlling, PACM), работающие поверх in-memory СУБД SAP HANA. Отечественные аналоги на основе PostgreSQL — 1С:ERP, Галактика — не рассчитаны на вычисления в реальном времени.

Picodata Silver выполняет полный цикл распределения затрат по десяткам миллионов записей между тысячами центров возникновения затрат за время менее 20 минут с погрешностью не более 100 рублей. На 90% типовых задач распределения кластер из не более чем 32 процессорных ядер обеспечивает целевые показатели производительности.

Техническая реализация: плагин Silver написан на языке Rust поверх фреймворка распределённых графовых вычислений Google Pregel. Шаги графового алгоритма (вычисление на вершинах, обмен сообщениями между вершинами) выполняются параллельно на всех узлах кластера Picodata. Управление плагином осуществляется через SQL-команды (CREATE PLUGIN, ALTER PLUGIN) и консольный инструмент silver-cli.

Техническая документация плагина Picodata Silver →

Сценарии применения

Архитектура shard-per-core и shared-nothing эффективна для следующих классов задач:

• Высокочастотные очереди сообщений (200 000 RPS и выше, с требованием гарантированной доставки и гибкой фильтрации).
• Параллельные вычисления над графами (расчёт себестоимости, сетевой анализ, оптимизация маршрутов).
• Real-time OLTP (онлайн-тарификация, риск-аналитика, персональные предложения в реальном времени).
• Real-time BI (агрегации и аналитика в оперативной памяти на высоких нагрузках чтения).
• Кэш горячих данных с требованиями ACID (замена Redis Cluster при необходимости строгой согласованности).

Архитектура имеет ограничение для задач с высокой кардинальностью распределённых транзакций, затрагивающих большое число шардов одновременно. В текущей версии Picodata ACID-транзакции реализованы в пределах одной партиции; распределённые транзакции между партициями находятся в дорожной карте развития продукта.