MongoDB

01Идея: документы вместо строк

Представьте реляционную базу как набор таблиц, которые вы соединяете между собой, а MongoDB — как картотеку, где в каждой папке лежит всё об одной сущности. Документ — это BSON-объект (бинарный JSON с дополнительными типами: даты, десятичные числа, ObjectId). Документы живут в коллекциях, коллекции — в базе данных. У каждого документа есть уникальный _id. Документы одной коллекции не обязаны иметь одинаковые поля, но на практике должны, и это обеспечивается валидатором JSON Schema. Максимальный размер одного документа — 16 MB, и это подсказка: документы предназначены для ограниченных данных, а не для бесконечных списков.

• BSON: бинарный формат, в котором MongoDB хранит данные; поддерживает типы, которых нет в JSON, например Date и Decimal128.
• Коллекция: группа документов, примерно как таблица.
• ObjectId: 12-байтный _id по умолчанию, примерно упорядоченный по времени создания.

02Моделирование: встраивать или ссылаться

Главный вопрос проектирования — класть ли связанные данные внутрь родительского документа (embed) или в отдельную коллекцию с id-ссылкой на них (reference). Встраивайте, когда дочерние данные принадлежат родителю, читаются вместе с ним и имеют ограниченный размер: заказ и его позиции, пользователь и его адреса. Используйте ссылку, когда данные общие, растут без ограничений или обновляются независимо: комментарии к популярному посту, товары, на которые ссылаются многие заказы. Правило из официальных рекомендаций MongoDB: «данные, к которым обращаются вместе, нужно хранить вместе». Проектируйте от запросов: сначала перечислите экраны и API-вызовы, затем сформируйте документы так, чтобы каждый обслуживался одним чтением.

1// One order document: line items embedded, customer referenced
2{
3  _id: ObjectId("665f1c2a9b1e8a0012345678"),
4  customerId: ObjectId("665f1b009b1e8a0011112222"),
5  status: "paid",
6  total: NumberDecimal("59.90"),
7  items: [
8    { sku: "TSHIRT-M", qty: 2, price: NumberDecimal("19.95") },
9    { sku: "CAP-01", qty: 1, price: NumberDecimal("20.00") }
10  ],
11  createdAt: ISODate("2026-11-05T10:00:00Z")
12}

03Запросы, индексы и правило ESR

Запросы пишутся документами-фильтрами ({ status: "paid" }) с операторами вроде $gt, $in и $elemMatch. Без индекса MongoDB сканирует каждый документ (COLLSCAN). Индексы — это B-деревья, как в SQL-базах, а составные индексы следуют правилу ESR: сначала поля, по которым идёт сравнение на равенство (Equality), затем поля сортировки (Sort), затем поля с фильтром по диапазону (Range). Индекс { customerId: 1, createdAt: -1 } идеально обслуживает «последние заказы этого клиента». Всегда проверяйте запрос через explain("executionStats") и сравнивайте totalDocsExamined с nReturned: если первое намного больше, индекс неправильный или отсутствует.

1db.orders.createIndex({ customerId: 1, status: 1, createdAt: -1 })
2 
3db.orders
4  .find({ customerId: id, status: "paid", createdAt: { $gte: since } })
5  .sort({ createdAt: -1 })
6  .limit(20)
7  .explain("executionStats")

04Aggregation pipeline

Агрегация — ответ MongoDB на GROUP BY и отчёты. Pipeline — это массив стадий: каждая преобразует поток документов и передаёт дальше, как на конвейере. $match фильтрует (ставьте его первым, чтобы он мог использовать индекс), $group считает итоги, $sort сортирует, $project меняет форму, $lookup соединяет с другой коллекцией, а $unwind превращает массив в отдельный документ на каждый элемент. Pipeline мощные, но могут быть тяжёлыми: $group по миллионам документов расходует память, а стадии, превышающие 100 MB, сбрасывают данные на диск. Держите $match и $project в начале, чтобы уменьшить объём до дорогих стадий.

1db.orders.aggregate([
2  { $match: { status: "paid", createdAt: { $gte: ISODate("2026-10-01") } } },
3  { $unwind: "$items" },
4  { $group: {
5      _id: "$items.sku",
6      units: { $sum: "$items.qty" },
7      revenue: { $sum: { $multiply: ["$items.qty", "$items.price"] } }
8  } },
9  { $sort: { revenue: -1 } },
10  { $limit: 10 }
11])

05Replica set, write concern и транзакции

Replica set — это группа серверов mongod с одинаковыми данными: один primary принимает записи, secondary копируют его журнал операций (oplog). Если primary падает, оставшиеся участники за секунды выбирают нового. Write concern определяет, сколько участников должны подтвердить запись; начиная с MongoDB 5.0 по умолчанию это «majority», то есть подтверждённая запись переживёт failover. Read concern и read preference управляют тем, что и откуда вы читаете. Многодокументные ACID-транзакции есть (в replica set с 4.0, в шардированных кластерах с 4.2), но они стоят производительности; при хорошей модели документов они нужны редко, потому что запись в один документ и так атомарна.

• В продакшене используйте минимум трёх участников с данными, распределённых по зонам.
• Подключайтесь полной строкой подключения replica set, чтобы драйверы находили нового primary при failover.
• Чтение с secondary может вернуть немного устаревшие данные; используйте его только там, где это допустимо.

06Использование из приложения

Официальные драйверы есть для Node.js, PHP, Python, Go, Java и других языков. В Node.js многие команды добавляют Mongoose для схем и валидации, но нативный драйвер тоже хорош и легче. Создавайте один клиент на процесс и переиспользуйте его: клиент держит пул соединений. Валидируйте входные данные на границе, храните деньги в Decimal128 (никогда не во float) и сохраняйте даты как настоящие значения Date в UTC. Включите валидацию схемы на уровне коллекции, чтобы кривой деплой не смог записать мусор.

1import { MongoClient } from "mongodb";
2 
3const client = new MongoClient(process.env.MONGODB_URI!); // reuse per process
4const orders = client.db("shop").collection("orders");
5 
6export async function latestOrders(customerId: ObjectId) {
7  return orders
8    .find({ customerId }, { projection: { items: 0 } })
9    .sort({ createdAt: -1 })
10    .limit(20)
11    .toArray();
12}

07WiredTiger: как на самом деле устроено хранение

WiredTiger — движок хранения MongoDB. Он использует управление конкурентностью на уровне документа, так что два писателя блокируют друг друга, только если трогают один и тот же документ. Данные и индексы — это B-деревья, сжатые на диске (по умолчанию snappy, опционально zstd). WiredTiger держит кэш в RAM, по умолчанию примерно 50% от (RAM минус 1 GB); производительность зависит от того, помещается ли туда рабочий набор (часто используемые документы плюс индексы). Записи сначала попадают в журнал и периодически сбрасываются в файлы данных через checkpoint, поэтому после сбоя восстановление идёт от последнего checkpoint плюс журнал. Когда рабочий набор не помещается, вы видите давление на вытеснение из кэша, а чтения с диска начинают доминировать в задержке — это момент добавить RAM, урезать индексы или шардировать.

• Следите за db.serverStatus().wiredTiger.cache: dirty и evicted байты.
• Для быстрых запросов индексы должны помещаться в RAM; проверяйте размеры через db.collection.stats().

08Шардирование и выбор shard key

Шардирование делит коллекцию между несколькими replica set. Роутер (mongos) отправляет каждый запрос на те шарды, которые владеют нужными диапазонами shard key. Shard key решает всё: у него должна быть высокая кардинальность, он должен равномерно распределять записи и присутствовать в большинстве запросов. Монотонно растущий ключ вроде timestamp или ObjectId отправляет все вставки на один шард (горячий шард); hashed-шардирование исправляет распределение, но запросы по диапазону разлетаются по всем шардам. Составной ключ вроде { tenantId: 1, createdAt: 1 } часто хорошо работает для multi-tenant приложений. С 5.0 коллекцию можно перешардировать онлайн, а с 6.0 балансировщик ориентируется на объём данных, а не на число чанков, но перешардирование всё равно дорогое, поэтому выбирайте внимательно.

1sh.enableSharding("shop")
2sh.shardCollection("shop.events", { tenantId: 1, createdAt: 1 })
3 
4// Queries that include tenantId are targeted to one shard
5db.events.find({ tenantId: "t_42", createdAt: { $gte: since } })

09Регуляторы согласованности: write concern, read concern, causal sessions

MongoDB позволяет выбирать согласованность для каждой операции. Write concern w: "majority" ждёт, пока запись окажется у большинства участников, поэтому она переживёт failover; w: 1 быстрее, но запись может откатиться, если primary упадёт до репликации. Read concern "majority" возвращает только данные, подтверждённые большинством, "linearizable" даёт самую сильную гарантию для чтения одного документа ценой большей стоимости, а "snapshot" используется внутри транзакций. Causally consistent sessions гарантируют, что клиент читает собственные записи даже при чтении с secondary. Ошибка — смешивать настройки не думая: запись с w: 1 и чтение с secondary могут показать пользователям данные, которые потом исчезнут.

10Change streams, TTL и time series

Change streams позволяют приложению подписаться на вставки, обновления и удаления в коллекции, базе или кластере; они построены на oplog. Их можно возобновить по resume token, что делает их надёжным источником для синхронизации поискового индекса или кэша либо для публикации событий (часто вместе с паттерном outbox). TTL-индексы автоматически удаляют документы через заданное время — удобно для сессий и временных токенов. Коллекции time series эффективно хранят измерения в бакетах с автоматическим сжатием, что подходит для метрик и данных IoT. Atlas также добавляет Atlas Search (полнотекстовый поиск на базе Lucene) и Vector Search, а последние релизы Community и Enterprise начали приносить поиск и векторный поиск в self-managed развёртывания.

1// Expire sessions 24 hours after createdAt
2db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 86400 })
3 
4// React to new paid orders
5const stream = db.orders.watch([{ $match: { "fullDocument.status": "paid" } }],
6  { fullDocument: "updateLookup" })