MongoDB интересна не обещанием гибкой схемы само по себе, а тем, как документная модель меняет баланс между скоростью разработки, атомарностью операций и ценой консистентности.
В повседневной работе глава помогает мыслить через форму документа, агрегаты, read concern и write concern, чтобы быстрые продуктовые решения не превращались в хаос на этапе роста и усложнения запросов.
В интервью и design review она особенно полезна, когда нужно показать, почему документная модель действительно ускоряет delivery в этом домене и какие ограничения команда принимает осознанно, а не случайно.
Практическая польза главы
Границы документов
Проектируйте aggregate и document shape так, чтобы частые операции были атомарны без сложных join.
Consistency knobs
Настраивайте read/write concern под конкретные пользовательские сценарии, а не глобально для всех запросов.
Shard key discipline
Выбирайте ключ шардинга через распределение нагрузки, hot partitions и стоимость ребалансировки.
Interview framing
Объясняйте, почему document-модель ускоряет delivery, и какие ограничения вы принимаете осознанно.
Источник
MongoDB
История MongoDB и ключевые особенности, включая транзакции и вопросы консистентности.
MongoDB — документно-ориентированная NoSQL база данных, которая со временем эволюционировала от «быстрого JSON-хранилища» к системе с репликацией, шардированием и multi-document ACID транзакциями. В этой главе разберём историю появления и то, как менялись гарантии консистентности.
История: ключевые вехи
Старт разработки
10gen начинает разработку MongoDB как части платформы PaaS.
Релиз и open source
Компания смещает фокус на open-source модель и коммерческую поддержку.
MongoDB Inc.
10gen переименовывается в MongoDB Inc.
Atlas
Появляется MongoDB Atlas (DBaaS), который становится основным способом потребления продукта.
IPO
MongoDB выходит на биржу (тикер MDB).
4.0: транзакции + snapshot
Появляются multi-document ACID транзакции и snapshot read concern.
5.0: w:majority по умолчанию
По данным Wikipedia, дефолтный write concern повышен до majority.
Документация
Sharded Cluster Components
mongos, config servers и shard replica sets как базовые элементы кластера.
Архитектура MongoDB (современные версии)
В MongoDB выделяют слой клиентов и драйверов, слой маршрутизации и выполнения запросов, а также уровень репликации и шардирования поверх storage engine.
Компоненты sharded cluster
mongos (router)
Маршрутизирует запросы к нужным шардам на основе метаданных.
Config servers
Хранят метаданные кластера и состояние шардинга.
Shards (replica sets)
Каждый шард разворачивается как replica set.
Типовые режимы развертывания
Standalone
Один mongod, без шардирования и репликации.
Replica set
Primary + несколько secondary, синхронизация через oplog.
Sharded cluster
mongos + config servers + несколько shard replica sets.
DDL vs DML: как проходит запрос
DDL меняет структуру коллекций и индексов, DML работает с документами. Ниже - цепочки выполнения для обоих типов запросов.
Как запрос проходит через MongoDB
Сравнение цепочки для DDL (структура) и DML (данные)
Активный шаг
1. Команда клиента
CRUD запрос приходит через драйвер.
Работа с данными
- DML работает с документами и индексами, но не меняет схему.
- Ключевая нагрузка - кеш, индексы и журналирование.
- Read/Write concern задают компромисс между latency и надежностью.
Связанная глава
Jepsen и модели консистентности
Как Jepsen тестирует распределённые системы и что означают модели консистентности.
Консистентность в MongoDB: что можно настраивать
В распределённой базе данных «консистентность» — это не один переключатель, а набор настроек и компромиссов. В Wikipedia подчёркиваются read/write concern и появление транзакций как ключевые механизмы.
Replication и шардирование
MongoDB поддерживает репликацию и шардирование, поэтому чтения/записи — это всегда компромиссы сети и отказов.
Read/Write concern
MongoDB использует уровни read concern и write concern, чтобы управлять свежестью чтений и надежностью подтверждения записей.
ACID транзакции
С версии 4.0 поддерживаются multi-document ACID транзакции, что сближает модель с классическими RDBMS сценариями.
Как менялись модели и гарантии во времени
Более безопасные дефолты
- Wikipedia отмечает, что дефолтный write concern повышен до majority (w:majority), что снижает риск потери подтвержденных записей при сбоях.
- Для строгих сценариев важно осознанно выбирать уровни read/write concern и понимать их влияние на latency и availability.
Что MongoDB гарантирует сегодня (в общих чертах)
- Поддерживает репликацию и шардирование, а также multi-document ACID транзакции (с 4.0).
- Уровни read concern / write concern позволяют выбирать компромисс между скоростью и безопасностью.
- Wikipedia отмечает, что в 5.0 дефолтный write concern был повышен до majority (w:majority).
Практический вывод для системного дизайна: при выборе MongoDB важно заранее договориться, какие гарантии нужны продукту (latency vs safety), и проверить, что конфигурация и драйверы действительно выставляют ожидаемые уровни чтения/записи.
Связанные главы
- Database Selection Framework - Когда выбирать документную модель MongoDB и как оценивать trade-offs по консистентности, сложности запросов и эксплуатации.
- Jepsen и модели консистентности - Как проверять реальные гарантии распределённой БД под отказами и почему декларативных обещаний недостаточно.
- Репликация и шардинг - Практика работы с replica set, failover, shard key и последствиями lag/ребалансировки для MongoDB-кластеров.
- Введение в хранение данных - Базовый контекст по связи storage-решений с API-контрактами и эволюцией архитектуры продукта.
- PostgreSQL: история и архитектура - Сравнение документной и реляционной моделей при выборе transactional core и сценариев со сложной аналитикой.
- Elasticsearch: архитектура и поиск - Разница ролей MongoDB и search-движка в системах, где нужен полнотекстовый поиск и агрегаты по событиям.