Шардирование
PostgreSQL:
когда и как
Инженерная точность в мире данных. Разбираем архитектуру горизонтального масштабирования и подводные камни распределенных транзакций.
Вертикаль против Горизонтали
Главный вопрос любой CTO: купить сервер в 2 раза мощнее или добавить еще один в кластер?
Вертикальное масштабирование (Scale Up) — это путь наименьшего сопротивления. Вы просто обновляете железо: больше RAM, быстрее NVMe. Для PostgreSQL это эффективно до определенного предела (обычно до 1-2 ТБ данных и 100k RPS). Однако, вы упираетесь в физические лимиты одного процессора и стоимость серверов уровня Enterprise.
Шардирование (Scale Out) меняет правила игры. Данные распределяются по множеству серверов, позволяя обрабатывать запросы параллельно. Но цена за бесконечную масштабируемость — архитектурная сложность. Вы теряете ACID-гарантии на уровне всей системы и получаете головную боль с перемещением данных (rebalancing).
Решения ПингКит
Аудит стратегии
Анализируем паттерны доступа к данным. Подскажем, хватит ли вам партиционирования (Partitioning) или нужен полноценный Citus.
Миграция без простоя
Внедряем репликацию и двойную запись, чтобы перенести данные в распределенную архитектуру без остановки сервиса.
Оптимизация запросов
Переписываем сложные JOINы и агрегации для распределенной среды. Настраиваем колокацию данных на нодах.
Подводные камни распределенных транзакций
Когда ваша таблица разбита на 10 шардов, простая транзакция `UPDATE accounts SET balance = balance - 100 WHERE id = 5` превращается в распределенную операцию. Если данные лежат на одном шарде — всё быстро. Если транзакция затрагивает 5 разных шардов — начинается ад.
Самая частая ошибка — использование 2PC (Two-Phase Commit) повсеместно. Это блокирует ресурсы на всех нодах и килит производительность в пиковые часы. В ПингКит мы обучаем команды паттерну Eventual Consistency. Вместо жесткой синхронизации мы используем очереди (Kafka/RabbitMQ) для асинхронного согласования состояний. Да, данные могут расходиться на 200мс, но система не падает под нагрузкой.
Наш подход: Consistent Hashing
Обычное хеширование (`ID % N`) требует полной пересортировки данных при добавлении нового сервера. Это "переезд" на ходу, который вызывает простои.
Мы используем алгоритм Consistent Hashing. Представьте хеш-кольцо: сервера и данные размещаются на нем по хешу. При добавлении новой ноды она забирает данные только с соседней ноды, не затрагивая остальные 99% системы.
// Virtual Nodes обеспечивают равномерность
// Rebalancing занимает минуты, а не часы
Сравнение производительности
| Метрика | Monolith (8 Core) | Sharded Cluster (3 Nodes) | Прирост |
|---|---|---|---|
| SELECT (Indexed) | 2ms | 2.5ms | -25% |
| INSERT (Batch) | 5000 ops/s | 15200 ops/s | +204% |
| UPDATE (Hot Rows) | 1200 ops/s | 3800 ops/s | +216% |
| Сложность DevOps | Низкая | Высокая | — |
Сложно масштабировать в одиночку?
Мы поможем спроектировать архитектуру, которая выдержит рост в 10 раз.