Эта глава показывает эволюцию хранения без магии: от файлов и простой OLTP-модели к NoSQL, NewSQL и HTAP команды обычно приходят не из моды, а из накопившихся ограничений.
На практике она помогает честно описать, где в системе живёт состояние, как оно перемещается между очередями, объектным хранилищем и базами данных, и почему из этого появляются требования к идемпотентности, повторам и порядку событий.
На интервью и в архитектурных обсуждениях материал помогает объяснить, почему архитектура данных усложнилась именно в такой последовательности, а не потому что команда сразу выбрала тяжёлый стек.
Практическая польза главы
Модель состояния
Явно описывайте, где живёт состояние: в приложении, очереди, базе данных или объектном хранилище, и какие гарантии нужны на каждом шаге.
API и данные
Проектируйте контракты API с учётом моделей хранения: идемпотентности, повторов, порядка событий и дедупликации.
NewSQL и HTAP
Понимайте, когда NewSQL и HTAP упрощают архитектуру, а когда лучше разнести транзакционный и аналитический контуры.
Структура на интервью
Уверенно объясняйте путь эволюции данных от простого хранения к распределённой архитектуре без лишней сложности.
Источник
Essential Architecture - Data
Расшифровка лекции от 4 октября 2021 года о хранении данных и влиянии выбора хранилища на API.
Эта глава связывает , , , и . Так проще объяснить, почему выбор хранилища меняет задержку, повторы, идемпотентность, дедупликацию и ответственность команд за данные.
Дальше мы идём от файлов и классической к NoSQL, , , , и . Главная мысль остаётся простой: состояние лучше явно вынести за пределы процесса, но после этого нужно честно выбрать, где оно живёт и какие гарантии получает API.
Почему данные определяют API
Связанная тема
The Twelve-Factor App
Подход без сохранения состояния как фундамент масштабирования и устойчивости.
Архитектурные решения по данным превращаются в свойства интерфейсов.
- Задержка ответа и пропускная способность
- Границы строгой и конечной консистентности
- Модель ошибок, повторов и дедупликации
- Ограничения на фильтрацию/поиск/пагинацию
- Идемпотентность для повторяемых операций
- Ответственность команд за данные и контракты
Без состояния как фундамент
Принцип Twelve-Factor: приложения не хранят состояние в процессе. Масштабирование становится проще, но место хранения данных нужно выбрать явно.
Эволюция хранения состояния
Файловые системы
Форматы файлов и правила чтения быстро попадают в бизнес-код.
Реляционные базы данных (OLTP)
SQL и транзакции дают сильные гарантии и выразительный интерфейс.
OLAP и аналитика
Кубы, модели «звезда» и «снежинка» помогают строить BI и агрегаты.
Big Data / Hadoop
MapReduce и экосистема Hadoop закрывают массовую пакетную обработку.
Объектное хранилище
Объекты без жёсткой иерархии и S3 API как де-факто стандарт.
NoSQL
Горизонтальное масштабирование ценой компромиссов.
NewSQL
SQL и ACID-гарантии в распределённой архитектуре для транзакционной нагрузки.
HTAP
Сближение OLTP и OLAP: аналитика почти в реальном времени рядом с операционными данными.
NewSQL и HTAP в архитектурных решениях
Когда нужен NewSQL
Если нужны SQL-модель, строгие транзакции и горизонтальный рост без ручного управления шардами.
Когда нужен HTAP
Когда продукту нужны оперативные транзакции и аналитика почти в реальном времени на тех же данных.
Ключевые риски
Рост операционной сложности, дорогие межрегиональные запросы и ограничения для тяжёлой аналитики.
Как это защищать на интервью
Объясняйте, какую боль решает подход, какие компромиссы принимает команда и какие ограничения снижают риск.
Практический ориентир: NewSQL подходит для ядра с сохранением состояния и высокой транзакционной ценой ошибки, а HTAP — для продуктовых сценариев, где аналитика должна идти почти синхронно с операционным контуром.
Реляционные базы данных: ключевые понятия
Связанная тема
Database Internals
B-Tree, LSM и транзакции внутри СУБД.
Нормализация
Формы данных влияют на схему и поведение запросов.
SQL
Декларативный язык отделяет «что» от «как».
Индексы
Ускоряют чтение, но замедляют запись и обновления.
Транзакции и ACID
Атомарность, изоляция и долговечность формируют контракты.
Репликация
Переключение на резерв и масштабирование чтений с компромиссами по консистентности.
Шардирование
Маршрутизация по ключу шарда и распределение нагрузки.
Интеграция между системами
Связанная тема
Enterprise Integration Patterns
Файлы, RPC и обмен сообщениями как паттерны интеграции.
Обмен файлами
Понятный способ обмена, но со слабой инкапсуляцией.
Общая база данных
Высокая связанность и замедление развития из-за общей схемы.
RPC
Сильные контракты, но требует дисциплины версионирования.
Обмен сообщениями
Асинхронные сценарии и гибкость интеграций.
Общая база данных создаёт сильную связанность и ломает контракты между командами. Современные системы стремятся к разделению ответственности и явным интерфейсам.
Data Lake и Data Mesh
Связанная тема
Big Data
Эволюция аналитики и архитектурные слои.
Data Lake
Централизованный сбор данных из OLTP с ETL-процессами. Масштабирование усложняет связанность и качество данных.
Data Mesh
- Доменно-ориентированная децентрализация
- Данные как продукт
- Платформа самообслуживания
- Федеративное управление через исполняемые политики
DDD и границы доменов
Связанная тема
Learning Domain-Driven Design
Ограниченные контексты и доменные контракты.
Доменные границы и контракты между ограниченными контекстами делают API устойчивыми. Подходы DDD помогают отделить модели данных разных команд.
Как данные превращаются в удобный API
Мостик данные -> API
- Предсказуемые гарантии ACID и BASE
- Ясные источники истины
- Чёткая модель ошибок и повторов
- Границы доменов и контрактов
- Идемпотентность и дедупликация
- Изоляция от общей базы данных
NoSQL через призму CAP/BASE
Понимание CAP и BASE помогает объяснять клиентам консистентность в конечном итоге и строить корректные повторы.
Мини-чек-лист удобного API
- Понятно, какие гарантии консистентности даёт система.
- Клиент понимает, где возможна консистентность в конечном итоге.
- Идемпотентность для операций, которые могут быть повторены.
- Ошибки, ретраи и таймауты описаны детерминированно.
- Нет общей базы данных как скрытого канала интеграции.
- Доменные границы отражены в контракте API.
Практические сценарии выбора хранилища
Журнал проводок и биллинг
Реляционная БД или NewSQL
Сильная консистентность, строгие транзакции, корректная обработка повторов и аудита.
Оперативная отчётность продукта
HTAP или OLTP + потоковая обработка + OLAP
Нужны быстрые дашборды без долгого лага ETL и без потери транзакционной части.
Телеметрия и мониторинг
TSDB + объектное хранилище
Высокая скорость приёма, правила удержания данных и дешёвое долгосрочное хранение исторических метрик.
Контент + поиск + рекомендации
Несколько типов хранилищ
Одна БД редко оптимальна для транзакций, полнотекстового поиска и векторного извлечения контекста одновременно.
Связанные главы
- Путеводитель по БД - Практический ориентир по выбору и эксплуатации баз данных под разные нагрузки.
- Фреймворк выбора СУБД - Помогает выбирать между OLTP, OLAP и NoSQL с учётом нефункциональных требований.
- Designing Data-Intensive Applications, 2nd Edition (short summary) - Фундаментальные концепции о моделях данных, репликации и консистентности для API-контрактов.
- Database Internals (short summary) - Детали движков хранения: B-Tree, LSM, WAL, задержка и пропускная способность.
- Enterprise Integration Patterns (short summary) - Паттерны интеграции между системами: когда выбирать файлы, RPC или обмен сообщениями.
- CAP теорема - Базовые компромиссы консистентности и доступности при сетевых разделениях.
- Data Mesh in Action (Data Mesh в действии) - Эволюция платформы данных от централизованного озера к доменному владению данными.
- The Twelve-Factor App: принципы cloud-native - Принцип приложений без сохранения состояния как отправная точка для выбора внешнего хранилища.