Источник
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), и проверить, что конфигурация и драйверы действительно выставляют ожидаемые уровни чтения/записи.