Хороший выбор СУБД почти никогда не выглядит как любовь с первого взгляда к одной технологии. Он больше похож на последовательное отсечение неподходящих вариантов по требованиям системы.
Для реальных проектных решений глава полезна тем, что помогает сравнивать кандидатов по профилю чтения и записи, требованиям к сервисному уровню, характеру запросов, модели консистентности и операционной цене, а не по громкости бренда.
Для интервью и инженерных разборов она дает особенно сильную позицию: важно не просто назвать победителя, а показать, почему другие варианты были отклонены и что может заставить пересмотреть решение позже.
Практическая польза главы
Отбор по критериям
Формируйте 2-3 кандидата СУБД на основе профиля чтения и записи, требований к сервисному уровню и характера запросов вместо выбора по популярности.
Оценочная матрица
Сравнивайте варианты по консистентности, задержке 95-го и 99-го перцентилей, операционной сложности и полной стоимости владения.
Реестр рисков
Фиксируйте ограничения заранее: зависимость от вендора, межрегиональные задержки, миграционные окна и кадровую экспертизу команды.
Защита решения
Показывайте, почему отклонили альтернативы и какие сигналы заставят пересмотреть выбранную технологию.
Рамка выбора и редакторский фокус
Фокус главы
методике выбора СУБД по профилю нагрузки и ограничениям системы
Профиль нагрузки
Начинайте с профиля данных: что является источником истины, где нужна транзакционная обработка OLTP, где аналитика, поиск, кэш или поток событий.
Когда выбирать
Глава нужна как входная рамка: она помогает выбрать порядок изучения и не прыгать сразу к любимой СУБД.
Граница и риск
Главный риск — смешать классификацию, выбор технологии и эксплуатационные гарантии в одну неявную рекомендацию.
Связать дальше
Связывайте выводы с фреймворком выбора СУБД, DDIA и практическими обзорами конкретных движков.
Фундамент
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-контрактов до выбора конкретного движка.
- Путеводитель по базам данных (краткое содержание) - Практическое дополнение к фреймворку: как применять критерии выбора к реальным кейсам.
- PostgreSQL: история и архитектура - Ориентир для сценариев транзакционной обработки OLTP с сильной транзакционной моделью и развитой экосистемой.
- MySQL: история, движки хранения и масштабирование - Альтернативный путь транзакционной обработки OLTP с широким опытом эксплуатации и другими операционными компромиссами.
- MongoDB: документная модель, репликация и консистентность - Документная модель и схема эволюции для гибких продуктовых сценариев.
- Cassandra: архитектура и компромиссы - Распределённая модель с преобладанием записи и компромиссы по консистентности на больших масштабах.
- ClickHouse: аналитическая СУБД - Направление аналитической обработки OLAP для высокопроизводительной аналитики и сканов по большим объёмам данных.
- Репликация и шардирование - Операционная детализация репликации и шардирования после выбора базовой категории СУБД.
- CAP теорема - Откуда берётся выбор между консистентностью и доступностью, когда сеть распадается на части, — основа для решений из оси 2.
- PACELC теорема - Расширяет теорему CAP с учётом компромисса между задержкой и консистентностью даже без сетевого разделения.
- Архитектура конвейеров данных: извлечение, преобразование и загрузка (ETL) и ELT - Связка контуров транзакционной (OLTP) и аналитической (OLAP) обработки через конвейер данных и разделение операционной и аналитической нагрузки.
- Designing Data-Intensive Applications, 2nd Edition (short summary) - Теоретическая база по моделям данных, репликации и партиционированию для архитектурных решений.