Раздел про базы данных полезен не каталогом технологий, а тем, что возвращает разговор к самой трудной части: какие свойства данных и запросов вообще заставляют нас выбирать конкретный класс хранилища.
В повседневной инженерной работе эта глава помогает разложить систему на разные контуры хранения: транзакционное ядро, аналитические витрины, поисковый слой, кэш и событийные логи, чтобы не пытаться решить все одной СУБД.
На интервью и в архитектурных обсуждениях она задает правильную рамку: сначала профиль нагрузки, консистентность, задержки и стоимость эксплуатации, и только потом названия конкретных движков.
Практическая польза главы
Карта нагрузок
Разложите продукт по профилям OLTP/OLAP/streaming и заранее зафиксируйте, где нужна жесткая консистентность, а где допустима задержка.
Границы хранилищ
Определяйте ownership данных по доменам, чтобы отделять source of truth от индексов, кэшей и аналитических витрин.
План эволюции
Стройте roadmap миграции: от одного storage к polyglot-модели без остановки сервиса и с контролем риска.
Interview-аргументация
Показывайте решение через trade-offs CAP/PACELC, latency budget и стоимость эксплуатации, а не через список технологий.
Контекст
Designing Data-Intensive Applications
Ключевой источник по data models, consistency, replication и инженерным компромиссам хранилищ.
Раздел «Системы хранения» нужен, чтобы проектировать данные как архитектурный фундамент продукта, а не как вспомогательную деталь после выбора API. На практике storage-решения определяют reliability, latency, стоимость и пределы масштабирования всей системы.
Эта глава связывает System Design с реальными решениями по БД: какую модель данных выбрать, где нужны строгие гарантии консистентности и как управлять эволюцией хранилища в production.
Почему эта часть важна
Хранилище определяет границы системы
Выбор модели данных и СУБД влияет на API, консистентность, latency, стратегию масштабирования и операционные процессы.
Storage trade-offs критичны для архитектуры
SQL, document, key-value, wide-column и графовые БД решают разные классы задач и дают разные гарантии.
Надежность данных - это инженерная дисциплина
Репликация, транзакции, восстановление и backup-стратегии требуют системного проектирования, а не точечных фиксов.
Ошибки выбора СУБД дорого исправлять
Поздняя миграция модели данных и схемы хранения обычно стоит дороже, чем ранняя валидация ограничений домена.
Storage-компетенция обязательна в System Design
На интервью и в production ожидают, что инженер умеет обосновывать выбор БД через нагрузку, консистентность и стоимость владения.
Как проходить раздел по системам хранения
Шаг 1
Зафиксировать профиль нагрузки и критичные пути
Определите read/write ratio, размер данных, требования к latency и RTO/RPO для ключевых пользовательских сценариев.
Шаг 2
Выбрать модель данных под домен
Сопоставьте доменные сущности и тип запросов с подходящей моделью: relational, document, key-value, columnar или graph.
Шаг 3
Задать консистентность и транзакционные границы
Решите, где нужна строгая ACID-семантика, а где допустимы eventual consistency и компенсационные механики.
Шаг 4
Спроектировать масштабирование и доступность
Определите схему репликации, партиционирования, failover и кэширования до запуска production-нагрузки.
Шаг 5
Планировать эволюцию хранилища как roadmap
Добавьте lifecycle-правила для миграций схемы, архивирования, cost control и наблюдаемости данных.
Ключевые storage trade-offs
Строгая консистентность vs latency и доступность
Чем выше требования к согласованности, тем дороже обходятся распределенные записи и тем сложнее держать низкую задержку.
Нормализация vs скорость чтения
Нормализованные схемы упрощают целостность, но денормализация часто нужна для высоконагруженных read-heavy сценариев.
Универсальная БД vs специализированный стек
Одна БД снижает операционную сложность, но polyglot persistence дает лучшую эффективность под разные типы данных.
Managed DB vs инфраструктурный контроль
Managed-сервисы ускоряют delivery, но могут ограничивать тонкую настройку, переносимость и контроль стоимости на масштабе.
Что входит в раздел
Storage foundations
Модели данных, принципы выбора БД и системные основы проектирования data-intensive сервисов.
Database engines in practice
Практический обзор OLTP/OLAP и NoSQL движков с их архитектурными ограничениями и эксплуатационными компромиссами.
Как применять это на практике
Частые ошибки
Рекомендации
Материалы раздела
- Введение в хранение данных
- Database Selection Framework
- Путеводитель по базам данных (short summary)
- Designing Data-Intensive Applications (short summary)
- Database Internals (short summary)
- PostgreSQL изнутри (short summary)
- PostgreSQL: архитектура и практики
- MySQL: архитектура и практики
- MongoDB: архитектура и практики
- Cassandra: архитектура и практики
- ClickHouse: аналитическая СУБД
- Redis: архитектура in-memory хранилища
- YDB: distributed SQL архитектура
- CockroachDB: distributed SQL архитектура
- DuckDB: embedded OLAP
- Time Series Databases (TSDB): типы и trade-offs
Куда двигаться дальше
Соберите storage-базу
Начните с Data Storage Intro, Database Selection Framework и DDIA, чтобы сформировать системный язык выбора хранилищ.
Углубите движки и эксплуатацию
Далее переходите к обзорам PostgreSQL/MySQL/MongoDB/Cassandra/ClickHouse и внутренностям БД, чтобы уверенно принимать production-решения по данным.
Связанные главы
- Database Selection Framework - дает прикладной алгоритм выбора СУБД под конкретный профиль нагрузки и архитектурные ограничения.
- Designing Data-Intensive Applications (short summary) - формирует фундамент по моделям данных, репликации и транзакциям для принятия storage-решений в distributed системах.
- PostgreSQL: архитектура и практики - помогает разобрать OLTP-контур и практические компромиссы реляционной модели в production.
- Cassandra: архитектура и практики - расширяет тему масштабирования и консистентности для write-heavy распределенных сценариев.
- ClickHouse: аналитическая СУБД и архитектура - добавляет аналитический OLAP-угол: колоночное хранение, партиционирование и high-throughput чтения.