Распределенная СУБД Shardman: горизонтальное масштабирование для enterprise-задач на базе Postgres Pro
Для бизнеса, который стремится к технологической независимости и работает с постоянно растущим объемом данных, крайне важно уметь масштабировать используемые базы данных. Это ключевая часть стратегии. Распределенная СУБД Shardman, созданная в результате проведенных Postgres Professional исследований 2017 года, позволяет горизонтально распределять данные без потерь в согласованности и управляемости, предоставляя при этом единый массив данных, как будто ваше приложение пользуется одной БД. В обзоре мы подробно рассмотрим, когда внедрять шардирование, как Shardman справляется с ограничениями традиционных подходов и почему он стал выбором для миграций с Oracle на объемах свыше 60 ТБ.
Содержание |
Что такое шардирование
Шардирование (от англ. shard — осколок, фрагмент) — это способ горизонтального масштабирования, при котором данные в одной логической таблице физически хранятся на разных узлах. Каждый узел обслуживает только свою часть данных, что снижает нагрузку на систему в целом. Полноценная распределенная СУБД с поддержкой шардинга — это отдельный класс решений.
Postgres Pro Shardman — распределенная СУБД, разработанная для сценариев, в которых традиционные подходы к масштабированию и отказоустойчивости уже не обеспечивают стабильную работу.
Когда пора задуматься о шардировании?
1. Исчерпаны ресурсы вертикального масштабирования
Рост числа ядер не дает линейного прироста, а стоимость серверов с большим количеством ядер становится непропорционально высокой.
2. База перестает влезать в рамки
В условиях постоянных модификаций и фоновых операций (vacuum, analyze, репликация) даже хорошо оптимизированная система начинает терять производительность.
3. Количество соединений становится критичным
Модель «один процесс на соединение» дает сбои при 10 000+ активных сессиях. Это критично для архитектур с долгоживущими соединениями и высокой частотой транзакций. В случае с Shardman используется специальное техническое решение для этой проблемы.
4. Все классические методы уже не помогают
Секционирование, пулы соединений, архивация, архитектурная модификация и связанные с ней компромиссы — все это уже использовано, но рост продолжается.
Архитектура и ключевые возможности Shardman
В архитектуре Shardman используются секционирование, внешние таблицы (FDW) и встроенная поддержка транзакций, что позволяет сохранить совместимость с SQL и привычной моделью работы с данными. Система ориентирована на устойчивую работу под OLTP-нагрузками, где требуется одновременно высокая производительность и строгая согласованность данных. Решение протестировано на объемах до 2 ПБ.
Горизонтальное масштабирование без простоя
Shardman обеспечивает автоматическое распределение строк таблиц по узлам с учетом объема и текущей нагрузки. Добавление новых серверов не требует остановки системы или миграции данных: масштабирование и ребалансировка выполняется на лету. Поддерживается работа с различными типами таблиц — глобальными, соразмещенными и локальными, что позволяет гибко адаптировать архитектуру под специфику конкретного проекта.
Распределенные транзакции и целостность данных
Система сохраняет свойства ACID даже в распределенной среде. Это достигается за счет собственного механизма согласования транзакций и контроля консистентности между узлами. Пользователи получают привычную транзакционную модель — без необходимости менять логику работы приложений.
Высокая доступность без единой точки отказа
Shardman не содержит централизованных компонентов, что исключает наличие единой точки отказа (SPOF). Любой узел может быть использован как точка входа в систему. При сбоях трафик автоматически перераспределяется на резервные узлы, обеспечивая непрерывную работу сервисов.
Параллельная обработка запросов
Архитектура Shardman позволяет выполнять запросы параллельно на нескольких узлах кластера. Встроенная маршрутизация направляет запросы туда, где находятся нужные данные, что позволяет минимизировать накладные расходы и повысить общую производительность. При этом используется эффективный механизм ребалансировки — при изменении нагрузки данные перераспределяются между узлами автоматически.
Реальный кейс: как перенесли 180 ТБ с Oracle на Postgres Pro
В 2023 году появилась задача полной миграции одной из крупных государственных информационных систем на новое решение. В системе сотни терабайт активных данных, постоянные изменения. При этом простой был невозможен даже на несколько часов, а потеря данных негативно сказалась бы на функционировании государственного аппарата.
К моменту начала работ объем базы составлял около 180 ТБ. Стало ясно: миграция потребует не только поэтапного переноса, но и надежного механизма синхронизации изменений между этапами. Именно здесь критически важными стали возможности распределенной СУБД — без нее проект либо затянулся бы на месяцы, либо сопровождался бы массовыми потерями данных и отказами.
На первом этапе данных были скопированы в Postgres Pro Shardman, на втором — выстроена параллельная работа российской и зарубежной СУБД, на третьем этапе — полный переход на отечественное решение. Скорость копирования данных составляла 10 ТБ/сутки, за счет многократного запаса производительности Shardman удалось достигнуть копирования в 600–800 параллельных потоков, а оптимизация базы обеспечила уменьшение ее размера на 50 ТБ.
В основе решения лежал Postgres Pro Shardman. Он позволил:
• перенести данные по частям, не останавливая сервис;
• обрабатывать изменения, поступающие во время миграции, в фоновом режиме;
• масштабировать обработку параллельно по нескольким потокам;
• создавать реплики и бэкапы без дополнительной нагрузки на основной сервис;
• сохранить привычную логику приложения и согласованность данных.
Миграция прошла без потерь данных. После выхода в промышленную эксплуатацию производительность выросла, время отклика снизилось, а система стала масштабироваться по мере роста нагрузки.
Таким образом, Shardman является не просто технологией, а комплексным решением для бизнеса, который столкнулся с экспоненциальным ростом данных и нагрузки. Он позволяет масштабировать Postgres Pro далеко за пределы одного сервера, сохраняя при этом управляемость, отказоустойчивость и целостность данных.
Решение подходит для государственных информационных систем, финтех-проектов, e-commerce платформ и других высоконагруженных OLTP-приложений.
