Хороший выбор СУБД почти никогда не выглядит как любовь с первого взгляда к одной технологии. Он больше похож на последовательное отсечение неподходящих вариантов по требованиям системы.
Для реальных проектных решений глава полезна тем, что помогает сравнивать кандидатов по профилю чтения и записи, требованиям к сервисному уровню, характеру запросов, модели консистентности и операционной цене, а не по громкости бренда.
Для интервью и инженерных разборов она дает особенно сильную позицию: важно не просто назвать победителя, а показать, почему другие варианты были отклонены и что может заставить пересмотреть решение позже.
Практическая польза главы
Отбор по критериям
Формируйте 2-3 кандидата СУБД на основе профиля чтения и записи, требований к сервисному уровню и характера запросов вместо выбора по популярности.
Оценочная матрица
Сравнивайте варианты по консистентности, задержке p95/p99, операционной сложности и полной стоимости владения.
Реестр рисков
Фиксируйте ограничения заранее: зависимость от вендора, межрегиональные задержки, миграционные окна и кадровую экспертизу команды.
Защита решения
Показывайте, почему отклонили альтернативы и какие сигналы заставят пересмотреть выбранную технологию.
Фундамент
Database Internals
Внутренние механизмы СУБД помогают понимать, почему один движок лучше держит транзакции, а другой - сканы и агрегации.
В этой главе выбор начинается не с любимой технологии, а с , и . Сначала мы разводим и , затем фиксируем , , , , и .
Фреймворк выбора СУБД помогает выбрать хранилище под конкретный продукт и его ограничения, а не под вкус команды. Цель главы - пройти решение по шагам: определить профиль чтения и записи, выбрать между транзакционным и аналитическим контуром, а затем принять решения по репликации и шардированию с учётом операционной сложности.
OLTP и OLAP: с чего начать выбор
OLTP
Много коротких транзакций, высокая конкуренция за записи, строгие требования к задержке и корректности изменений.
- p95/p99 задержки критичны для пользовательских операций.
- Нужны гарантии ACID и предсказуемая семантика транзакций.
- Частые точечные чтения и записи по ключу.
PostgreSQL / MySQL / распределённый SQL в зависимости от масштаба и требований к консистентности.
OLAP
Тяжёлые аналитические запросы, агрегации по большим диапазонам, колоночное чтение и оптимизация стоимости анализа.
- Основная нагрузка - аналитика и отчёты с преобладанием чтения.
- Нужны материализованные витрины и массовый приём данных из пакетных и потоковых контуров.
- Допускается более дорогой путь записи ради быстрого анализа.
ClickHouse / DWH / lakehouse-хранилище с колоночным движком.
Пять осей выбора СУБД
1. Профиль чтения и записи
Оцените соотношение чтения и записи, размер операций, всплески нагрузки и требования к задержке.
- Сколько операций записи и чтения в секунду ожидается на старте и через год?
- Каков горячий набор данных и по каким ключам к нему обращаются?
- Есть ли всплески трафика и как часто нужны исторические пересчёты или массовые загрузки?
2. Консистентность и транзакции
Решите, где нужна строгая консистентность, а где достаточно согласования со временем.
- Допустимо ли читать устаревшие данные и в каких пользовательских сценариях это безопасно?
- Требуются ли транзакции по нескольким строкам или сущностям?
- Какие гарантии чтения и записи бизнес считает обязательными?
3. Репликация
Определите цель репликации: высокая доступность, геораспределение, масштабирование чтения или аварийное восстановление.
- Нужна ли синхронная репликация для критичных данных?
- Какие RPO/RTO целевые метрики для аварийного восстановления?
- Какое отставание репликации приемлемо для продукта?
4. Шардирование
Проверяйте необходимость стратегии шардирования только после того, как вертикальное масштабирование и индексы перестают помогать.
- Какой ключ шардирования минимизирует горячие точки нагрузки и межшардовые запросы?
- Насколько болезненны повторное шардирование и миграции ключей?
- Какие операции станут распределенными транзакциями?
5. Операционная сложность
Сравните не только техническую пригодность, но и полную стоимость владения: экспертизу команды, инструменты, операционные инструкции.
- Есть ли экспертиза в команде по выбранной СУБД?
- Как устроены резервное копирование, восстановление, наблюдаемость и дежурства?
- Сколько стоит кластер при целевом объёме и требуемом уровне сервиса?
Быстрая матрица выбора
Транзакционный бэкенд: заказы, платежи, аккаунты
Сначала OLTP
Строгая консистентность, транзакции и низкая задержка чтения и записи.
Продуктовая аналитика, BI и разовые исследовательские запросы
Сначала OLAP
Большие сканы и агрегации эффективнее выполнять в колоночных хранилищах.
Смешанная нагрузка: операции и аналитика
Несколько типов хранилищ
Разведите путь записи OLTP и аналитический контур через CDC/ETL/ELT-конвейер.
Глобальный масштаб с региональными требованиями SLA
Репликация и выборочное шардирование
Комбинация локальности чтения, высокой доступности и контролируемой стоимости операций.
Практика
Репликация и шардирование
Практические модели и визуализации: ведущий узел с репликами, несколько ведущих узлов, ключ шардирования и перебалансировка.
Репликация и шардирование: минимальные правила
Репликация
- Выберите синхронную или асинхронную стратегию по критичности данных.
- Измеряйте отставание репликации и влияние на консистентность чтения.
- Проверяйте переключение на резерв регулярными тренировками, а не только на бумаге.
Шардирование
- Выбирайте ключ шардирования под реальные шаблоны запросов, а не под абстракцию.
- Оценивайте межшардовые соединения и цену распределённых транзакций.
- Закладывайте миграционный путь для повторного шардирования заранее.
Частые ошибки выбора СУБД
Выбирать базу только по хайпу, без профиля нагрузки и требований к уровню сервиса.
Шардировать слишком рано, до исчерпания вертикального масштабирования и индексов.
Игнорировать стоимость эксплуатации: резервное копирование, миграции, дежурства и наблюдаемость.
Смешивать OLTP и тяжёлую аналитику в одном кластере без изоляции ресурсов.
Считать CAP/PACELC теоретическими и не фиксировать явные консистентностные допущения.
Источники
Связанные главы
- Зачем разбираться в системах хранения - Общая карта подходов к данным и место фреймворка выбора СУБД в общей системе решений.
- Введение в хранение данных - Базовые компромиссы консистентности, интеграции и API-контрактов до выбора конкретного движка.
- Путеводитель по базам данных (short summary) - Практическое дополнение к фреймворку: как применять критерии выбора к реальным кейсам.
- PostgreSQL: история и архитектура - Ориентир для OLTP-сценариев с сильной транзакционной моделью и развитой экосистемой.
- MySQL: история, движки хранения и масштабирование - Альтернативный OLTP-путь с широким опытом эксплуатации и другими операционными компромиссами.
- MongoDB: документная модель, репликация и консистентность - Документная модель и схема эволюции для гибких продуктовых сценариев.
- Cassandra: архитектура и компромиссы - Распределённая модель с преобладанием записи и компромиссы по консистентности на больших масштабах.
- ClickHouse: аналитическая СУБД - OLAP-направление для высокопроизводительной аналитики и сканов по большим объёмам данных.
- Репликация и шардирование - Операционная детализация репликации и шардирования после выбора базовой категории СУБД.
- CAP теорема - Фундамент для обсуждения консистентности и доступности при сетевых разделениях.
- PACELC теорема - Расширяет CAP с учётом компромисса между задержкой и консистентностью даже без сетевого разделения.
- Архитектура конвейеров данных: ETL и ELT - Связка OLTP- и OLAP-контуров через конвейер данных и разделение операционной и аналитической нагрузки.
- Designing Data-Intensive Applications, 2nd Edition (short summary) - Теоретическая база по моделям данных, репликации и партиционированию для архитектурных решений.