Фундамент
Database Internals
Разбор внутренних механизмов СУБД помогает принимать осмысленные архитектурные решения.
Database Selection Framework - это практический способ выбрать СУБД под конкретный продукт и его ограничения, а не по вкусу команды. Цель главы: структурно пройти выбор между OLTP и OLAP, зафиксировать read/write профиль, требования к консистентности, а затем принять решения по репликации и шардированию с учетом операционной сложности.
OLTP vs OLAP
OLTP
Много коротких транзакций, high concurrency, строгие требования к latency и корректности записи.
- p95/p99 latency критичны для пользовательских операций.
- Нужны ACID-гарантии и предсказуемая transactional semantics.
- Частые point reads/writes, работа по ключу.
PostgreSQL / MySQL / распределенный SQL в зависимости от масштаба и требований к консистентности.
OLAP
Тяжелые аналитические запросы, агрегации по большим диапазонам, columnar scan и экономия на чтении.
- Основная нагрузка - read-heavy аналитика и отчеты.
- Нужны материализованные витрины и массовые batch/stream ingest.
- Компромисс на write path ради быстрого анализа.
ClickHouse / DWH/Lakehouse-подход с columnar engine.
Decision Framework (5 осей)
1. Read/Write профиль
Оцените R/W ratio, размер операций, burst pattern, требуемые SLA по latency.
- Сколько writes/sec и reads/sec ожидается на старте и через год?
- Какой объем данных в hot-set и каков характер ключей доступа?
- Есть ли всплески трафика и как часто нужны backfill/массовые загрузки?
2. Консистентность и транзакции
Решите, где нужен strict consistency, а где достаточно eventual consistency.
- Допустимы ли stale reads и в каких user-flow это безопасно?
- Требуются ли multi-row/multi-entity транзакции?
- Какой уровень read/write concern требуется бизнесу?
3. Репликация
Определите цель репликации: HA, геораспределение, read scaling, disaster recovery.
- Нужен ли sync replication для критичных данных?
- Какие RPO/RTO целевые метрики для аварийного восстановления?
- Какой lag на async-репликах приемлем для продукта?
4. Шардирование
Проверяйте необходимость shard strategy только когда vertical scaling уже не решает задачу.
- Какой shard key минимизирует hotspot и cross-shard queries?
- Насколько болезненны re-sharding и миграции ключей?
- Какие операции станут распределенными транзакциями?
5. Операционная сложность
Сравните не только техническую пригодность, но и стоимость владения: команды, tooling, runbooks.
- Есть ли экспертиза в команде по выбранной СУБД?
- Как устроены backup/restore, observability, on-call практики?
- Сколько стоит кластер при целевом объеме и SLA?
Быстрая матрица выбора
Транзакционный backend (заказы, платежи, аккаунты)
OLTP-first
Строгая консистентность, транзакции и low-latency writes/reads.
Продуктовая аналитика, BI и ad-hoc запросы
OLAP-first
Большие сканы и агрегации эффективнее в columnar хранилищах.
Mixed workload (операции + аналитика)
Polyglot persistence
Отделите OLTP write-path от OLAP serving через CDC/ETL/ELT pipeline.
Глобальный масштаб с региональными SLA
Replication + selective sharding
Комбинация read locality, HA и контролируемой стоимости операций.
Практика
Репликация и шардинг
Практические модели и визуализации: primary-replica, multi-leader, shard key и rebalance.
Репликация и шардирование: минимальные правила
Replication
- Определите sync/async стратегию по критичности данных.
- Измеряйте replication lag и влияние на read consistency.
- Проверяйте failover не на бумаге, а регулярными game day.
Sharding
- Выбирайте shard key под реальные query patterns, а не под абстракцию.
- Оценивайте cross-shard joins и distributed transaction cost.
- Закладывайте миграционный путь для re-sharding заранее.
Частые ошибки выбора СУБД
Выбирать базу только по хайпу, без workload-профиля и SLA.
Преждевременное шардирование до исчерпания vertical scaling и индексов.
Игнорировать стоимость эксплуатации: backup, migrations, on-call, observability.
Смешивать OLTP и тяжелую аналитику в одном кластере без изоляции ресурсов.
Считать CAP/PACELC теоретическими и не фиксировать явные консистентностные допущения.