Хороший выбор СУБД почти никогда не выглядит как любовь с первого взгляда к одной технологии. Он больше похож на последовательное отсечение неподходящих вариантов по требованиям системы.
Для реальных проектных решений глава полезна тем, что помогает сравнивать кандидатов по профилю чтения и записи, SLA, характеру запросов, модели консистентности и операционной цене, а не по громкости бренда.
Для интервью и инженерных разборов она дает особенно сильную позицию: важно не просто назвать победителя, а показать, почему другие варианты были отклонены и что может заставить пересмотреть решение позже.
Практическая польза главы
Shortlist по критериям
Формируйте 2-3 кандидата СУБД на основе read/write профиля, SLA и характера запросов вместо выбора по популярности.
Оценочная матрица
Сравнивайте варианты по консистентности, latency p95/p99, операционной сложности и полной стоимости владения.
Реестр рисков
Фиксируйте ограничения заранее: vendor lock-in, multi-region задержки, миграционные окна и кадровую экспертизу команды.
Interview defense
Показывайте, почему отклонили альтернативы и какие сигналы заставят пересмотреть выбранную технологию.
Фундамент
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 теоретическими и не фиксировать явные консистентностные допущения.
References
Связанные главы
- Зачем разбираться в системах хранения - Общая карта подходов к данным и место фреймворка выбора СУБД в общей системе решений.
- Введение в хранение данных - Базовые trade-offs по консистентности, интеграции и API-контрактам до выбора конкретного движка.
- Путеводитель по базам данных (short summary) - Практическое дополнение к фреймворку: как применять критерии выбора к реальным кейсам.
- PostgreSQL: история и архитектура - OLTP baseline с сильной транзакционной моделью и развитой экосистемой.
- MySQL: история, движки и масштабирование - Альтернативный OLTP-путь с широким production-опытом и различными operational trade-offs.
- MongoDB: история и консистентность - Документная модель и схема эволюции для гибких продуктовых сценариев.
- Cassandra: архитектура и компромиссы - Распределённая write-heavy модель и компромиссы по консистентности на больших масштабах.
- ClickHouse: аналитическая СУБД - OLAP-направление для высокопроизводительной аналитики и сканов по большим объемам данных.
- Репликация и шардирование - Операционная детализация replication/sharding решений после выбора базовой категории СУБД.
- CAP теорема - Фундамент для обсуждения консистентности и доступности при сетевых разделениях.
- PACELC теорема - Расширяет CAP с учетом latency/consistency компромиссов даже без partition.
- Data Pipeline / ETL / ELT Architecture - Связка OLTP и OLAP контуров через pipeline и разделение operational/analytical нагрузок.
- Designing Data-Intensive Applications (short summary) - Теоретическая база по моделям данных, репликации и partitioning для архитектурных решений.