Документоориентированные хранилища данных: MongoDB

В реляционных базах данных и строгих колоночных форматах Parquet каждая таблица имеет жесткую предопределенную схему (Schema-on-Write). Все строки обязаны иметь одинаковый набор столбцов, а добавление нового атрибута требует операции ALTER TABLE. Однако в реальных прикладных системах городского хозяйства и интернета вещей данные часто обладают высокой структурной неоднородностью.

Карточка аварийной заявки диспетчерской службы содержит базовые поля (адрес, время, заявитель), но состав специфических атрибутов зависит от характера происшествия: для прорыва трубопровода важны диаметр трубы, глубина залегания и давление, для отказа электроподстанции — фаза, напряжение и схема резервирования, а для заявки по лифтовому оборудованию — этажность, модель лебедки и коды ошибок контроллера. Попытка уложить такие данные в классическую реляционную схему приводит либо к созданию десятков полупустых таблиц, либо к антипаттерну Entity-Attribute-Value (EAV) с катастрофической потерей производительности ¹.

Естественным решением для таких задач стал класс документоориентированных СУБД (Document Stores), ярким представителем которых является MongoDB ².

Модель данных: документы и формат BSON

В MongoDB базовой единицей хранения является документ (Document), а совокупность документов образует коллекцию (Collection), аналогичную таблице реляционной СУБД.

Документы представлены в формате BSON (Binary JSON) — бинарной сериализации объектов JSON. В отличие от стандартного текстового JSON, формат BSON:

1. Поддерживает расширенный набор типов данных: 64-битные целые (int64), даты с миллисекундной точностью (Date), бинарные массивы (binData), регулярные выражения и уникальные 12-байтные идентификаторы ObjectId.
2. Явно сохраняет длину каждого поля и документа, что позволяет СУБД пропускать ненужные поля при парсинге без последовательного посимвольного чтения.
3. Имеет жесткое ограничение на максимальный размер одного документа: 16 МБ (для хранения больших файлов вроде сканов актов и схем применяется протокол GridFS).

Пример документа аварийного инцидента в BSON:

{
  "_id": ObjectId("65e0a1b2c3d4e5f6a7b8c9d0"),
  "incident_number": "INC-2024-8841",
  "created_at": ISODate("2024-03-01T14:22:00Z"),
  "district": "Советский",
  "location": {
    "type": "Point",
    "coordinates": [84.9521, 56.4883]
  },
  "category": "водоснабжение",
  "equipment": {
    "pipe_diameter_mm": 300,
    "material": "чугун",
    "depth_m": 2.4
  },
  "tags": ["срочно", "утечка", "проезжая_часть"],
  "inspections": [
    {
      "inspector": "Иванов А. В.",
      "date": ISODate("2024-03-01T15:10:00Z"),
      "result": "требуется раскопка"
    }
  ],
  "status": "в_работе"
}

Встраивание (Embedding) против ссылок (Referencing)

В реляционных базах связь между сущностями реализуется через внешние ключи и нормализацию. В документоориентированных базах разработчик выбирает между двумя стратегиями:

1. Встраивание документов и массивов (Embedding): Связанные данные хранятся прямо внутри родительского документа (например, массив актов осмотра inspections или координаты location).
   • Плюсы: Чтение всей информации об инциденте выполняется за одно дисковое обращение без соединений (JOIN). Атомарность обновления всего документа гарантируется из коробки.
   • Минусы: Дублирование данных при связях многие-ко-многим; риск превышения лимита 16 МБ при неконтролируемом росте массивов.
2. Ссылки по идентификатору (Referencing): Хранение _id связанного документа из другой коллекции (например, ссылка на карточку обслуживающей организации). Используется при редких обращениях или очень больших объемах связанных данных.

Индексирование в MongoDB

Хранение документов на диске в движке WiredTiger организовано на основе B-деревьев. Для ускорения поиска MongoDB поддерживает богатый набор индексов:

• Одиночные и составные индексы (Single / Compound Indexes): Позволяют быстро находить документы по значениям одного или нескольких полей:

  db.incidents.createIndex({ district: 1, created_at: -1 });
  

• Многоключевые индексы (Multikey Indexes): Если индекс строится по полю, содержащему массив (например, tags: ["срочно", "утечка"]), MongoDB автоматически индексирует каждый элемент массива. Запрос db.incidents.find({ tags: "срочно" }) использует индекс по B-дереву.
• Геопространственные индексы (2dsphere): Специализированные индексы для работы с координатами стандарта GeoJSON на сферической поверхности Земли. Поддерживают поиск ближайших объектов ($nearSphere) и проверку попадания в полигон ($geoWithin):

  db.incidents.createIndex({ location: "2dsphere" });
  

• Текстовые индексы (Text Indexes): Обеспечивают полнотекстовый поиск по ключевым словам с учетом стемминга и стоп-слов.

Конвейер агрегации (Aggregation Pipeline)

В отличие от простых операций поиска find(), для сложного аналитического анализа в MongoDB используется конвейер агрегации (Aggregation Pipeline) ³. Документы последовательно проходят через цепочку стадий преобразования, аналогично конвейеру UNIX:

  Коллекция --> [$match] --> [$unwind] --> [$group] --> [$sort] --> Результат

Основные стадии конвейера

1. $match: Фильтрация документов по предикату (аналог WHERE в SQL). Если $match стоит первым этапом, он эффективно использует B-дерево индексы.
2. $project: Выборка, переименование полей или вычисление новых выражений (аналог SELECT).
3. $group: Группировка документов по ключу _id с вычислением агрегатных функций: $sum, $avg, $min, $max, $push (аналог GROUP BY).
4. $unwind: Разворачивание массива в поток отдельных документов. Если документ содержал массив из 3 элементов, стадия $unwind порождает 3 копии документа, каждая с одним элементом массива.
5. $lookup: Левое внешнее соединение (Left Outer Join) с документами из другой коллекции.
6. $facet: Выполнение нескольких независимых агрегационных конвейеров над одним набором данных в рамках одного запроса (удобно для фасетного поиска).

Пример агрегационного конвейера для расчета распределения типов аварий по районам:

db.incidents.aggregate([
  { $match: { status: "завершено", created_at: { $gte: ISODate("2024-01-01") } } },
  { $group: {
      _id: { district: "$district", category: "$category" },
      incident_count: { $sum: 1 },
      avg_repair_hours: {
        $avg: {
          $divide: [{ $subtract: ["$closed_at", "$created_at"] }, 3600000]
        }
      }
  }},
  { $sort: { incident_count: -1 } }
]);

Транзакции и архитектура высокой доступности

Исторически документные базы критиковали за отсутствие гарантий ACID для нескольких документов. Однако начиная с версии 4.0 MongoDB поддерживает многодокументные распределенные транзакции (Multi-Document ACID Transactions) с изоляцией Snapshot Isolation на базе движка WiredTiger ⁴.

Для обеспечения отказоустойчивости применяется механизм наборов реплик (Replica Sets):

• Один первичный узел (Primary), принимающий все операции записи.
• Несколько вторичных узлов (Secondary), асинхронно или синхронно реплицирующих журнал операций (oplog).
• При отказе Primary вторичные узлы автоматически проводят голосование по алгоритму Raft и выбирают нового лидера менее чем за 3 секунды.

Для горизонтального масштабирования объемов хранения применяется шардирование (Sharding) на основе ключа шардирования (Shard Key) и маршрутизаторов mongos.

Итоги темы

MongoDB и документоориентированная модель представляют собой мощный инструмент для систем с динамической и слабоструктурированной природой данных. Формат BSON объединяет выразительность JSON с эффективностью бинарного представления, богатая система индексов (включая геопространственные 2dsphere) обеспечивает высокую скорость точечных запросов, а конвейер агрегации Aggregation Pipeline позволяет решать сложные аналитические задачи прямо внутри распределенной СУБД.

Литература

1. Fowler M., Sadalage P. J. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. — Addison-Wesley Professional, 2012. — Chapter 3: Document Databases ¹.
2. Chodorow K. MongoDB: The Definitive Guide: Powerful and Scalable Data Storage. — 3rd ed. — O'Reilly Media, 2020 ².
3. MongoDB Documentation. The Aggregation Pipeline Architecture. — MongoDB Inc., 2024. https://www.mongodb.com/docs/manual/core/aggregation-pipeline/ ³.
4. MongoDB Documentation. WiredTiger Storage Engine and Concurrency Control. — MongoDB Inc., 2024. https://www.mongodb.com/docs/manual/core/wiredtiger/ ⁴.

Дополнительные материалы

Вопросы для самопроверки

1. Чем документоориентированная модель отличается от реляционной модели данных и в каких прикладных сценариях она предпочтительнее?
2. В чём заключаются отличия формата BSON от стандартного текстового JSON? Какие дополнительные типы данных он поддерживает?
3. Каковы преимущества и недостатки встраивания документов (Embedding) по сравнению с нормализованным хранением ссылок (Referencing)?
4. Как устроен многоключевой индекс (Multikey Index) в MongoDB при индексировании полей массивов?
5. Как работает геопространственный индекс 2dsphere и какие координаты ожидает стандарт GeoJSON (широта/долгота или долгота/широта)?
6. Опишите принцип работы конвейера агрегации (Aggregation Pipeline). Почему стадию $match рекомендуется ставить в самое начало конвейера?
7. Что делает стадия $unwind и как она влияет на количество документов в конвейере?
8. Каким образом стадия $lookup выполняет операцию соединения и почему злоупотребление ею превращает MongoDB в неэффективную реляционную СУБД?
9. Как в MongoDB обеспечивается отказоустойчивость в наборе реплик (Replica Set)? Какова роль журнала операций oplog?
10. Какие ограничения накладывает лимит размера документа BSON в 16 МБ и как организуется хранение файлов большего объёма?

Глоссарий темы

Шпаргалка по командам MongoDB

// Поиск инцидентов с фильтрацией по массиву и вложенному полю:
db.incidents.find({
  "equipment.material": "чугун",
  "tags": "срочно"
}).sort({ created_at: -1 }).limit(10);

// Создание составного и геопространственного индексов:
db.incidents.createIndex({ district: 1, created_at: -1 });
db.incidents.createIndex({ location: "2dsphere" });

// Поиск объектов в радиусе 1000 метров от заданной точки (долгота, широта):
db.incidents.find({
  location: {
    $nearSphere: {
      $geometry: { type: "Point", coordinates: [84.9521, 56.4883] },
      $maxDistance: 1000
    }
  }
});

// Конвейер агрегации: развернуть теги и подсчитать популярность:
db.incidents.aggregate([
  { $unwind: "$tags" },
  { $group: { _id: "$tags", count: { $sum: 1 } } },
  { $sort: { count: -1 } }
]);

Типичные ошибки и подводные камни

1. Неограниченный рост массивов (Unbounded Arrays): Добавление каждого показания датчика или лога в массив одного документа ($push) со временем приводит к превышению лимита 16 МБ и постоянному перемещению документа на диске движком WiredTiger.
2. Перепутанный порядок координат в GeoJSON: Стандарт GeoJSON требует строгого порядка: [долгота (longitude), широта (latitude)]. Передача координат в привычном порядке [широта, долгота] приводит к тому, что объекты на карте окажутся в Антарктиде или в океане.
3. Отсутствие $match перед $unwind и $group: Вызов $unwind для всей коллекции перед фильтрацией приводит к генерации миллионов временных документов в оперативной памяти сервера, вызывая деградацию всей системы.

Литература

1. Chodorow K. MongoDB: The Definitive Guide. — O'Reilly Media, 2020 ¹.
2. Fowler M., Sadalage P. J. NoSQL Distilled. — Addison-Wesley, 2012 ².
3. MongoDB Official Manual. Aggregation Pipeline and Indexing. — 2024 ³.

Лабораторная работа 5. Документоориентированное хранилище MongoDB: геопространственный поиск и конвейеры агрегации

• Раздел курса: тема 5 «Документоориентированные хранилища данных: MongoDB»

Введение

В диспетчерских службах ЖКХ и городского хозяйства информация об инцидентах поступает в виде разнородных актов, включающих текстовые описания, списки задействованных бригад, геокоординаты мест аварий и произвольные наборы технических параметров поврежденного оборудования. Документоориентированная модель MongoDB идеально подходит для хранения подобных слабоструктурированных карточек.

В этой лабораторной работе вы развернете коллекцию карточек аварийных заявок в MongoDB, построите геопространственные и многоключевые индексы, выполните пространственный поиск инцидентов в окрестности заданного адреса и разработаете многостадийный агрегационный конвейер для расчета ключевых показателей надежности городских инженерных сетей.

Цель работы

Освоить приемы проектирования документоориентированных схем данных в MongoDB, построение индексов по массивам и координатам GeoJSON, выполнение геопространственных запросов и конструирование аналитических конвейеров агрегации (Aggregation Pipeline).

После выполнения работы вы сможете:

• проектировать схемы документов с вложенными структурами и массивами в формате BSON;
• создавать и использовать геопространственные индексы 2dsphere для поиска в радиусе и полигоне;
• строить многостадийные конвейеры агрегации с операторами $match, $unwind, $group и $project;
• анализировать планы выполнения запросов в MongoDB через метод .explain("executionStats").

Оборудование и учебная среда

Для выполнения работы потребуются:

• сервер MongoDB (версии 6.0 или новее) и клиентская оболочка mongosh (либо модуль pymongo в Python);
• файл первичных данных инцидентов incidents_seed.json.

Порядок выполнения работы

Часть 1. Загрузка данных и исследование документов BSON

1. Импортируйте исходный массив документов инцидентов в коллекцию city_incidents:

   mongoimport --db smart_city --collection incidents --file incidents_seed.json --jsonArray
   

2. Подключитесь к базе через оболочку mongosh smart_city.
3. Найдите документ с максимальным числом тегов и вложенным актом осмотра:

   db.incidents.findOne({ "tags.1": { $exists: true } });
   

4. Обратите внимание на структуру поля location: координаты сохранены в формате стандарта GeoJSON (Point, [долгота, широта]).

Часть 2. Геопространственный поиск инцидентов

1. Создайте геопространственный индекс по полю местоположения:

   db.incidents.createIndex({ location: "2dsphere" });
   

2. Найдите все инциденты, произошедшие в радиусе 1500 метров от центральной диспетчерской (координаты: [84.9500, 56.4800]):

   db.incidents.find({
     location: {
       $nearSphere: {
         $geometry: { type: "Point", coordinates: [84.9500, 56.4800] },
         $maxDistance: 1500
       }
     }
   }, { incident_number: 1, category: 1, created_at: 1, _id: 0 });
   

3. Проверьте план выполнения запроса с помощью explain("executionStats"). Убедитесь, что поиск использует индекс GEO_NEAR_2DSPHERE без полного сканирования коллекции.

Часть 3. Многоключевые индексы по массивам тегов

1. Создайте индекс по массиву тегов:

   db.incidents.createIndex({ tags: 1 });
   

2. Выполните поиск инцидентов, одновременно содержащих теги «срочно» и «раскопка»:

   db.incidents.find({ tags: { $all: ["срочно", "раскопка"] } });
   

3. Оцените число просмотренных индексных ключей (totalKeysExamined) и возвращенных документов (nReturned).

Часть 4. Построение конвейера агрегации (Aggregation Pipeline)

Сконструируйте конвейер агрегации для вычисления среднего времени ликвидации аварий в разрезе районов и материалов трубопроводов:

db.incidents.aggregate([
  // Стадия 1: отбираем только закрытые заявки с указанным материалом
  { $match: {
      status: "завершено",
      "equipment.material": { $exists: true },
      closed_at: { $exists: true }
  }},

  // Стадия 2: вычисляем длительность работ в часах
  { $project: {
      district: 1,
      material: "$equipment.material",
      duration_hours: {
        $divide: [{ $subtract: ["$closed_at", "$created_at"] }, 3600000]
      }
  }},

  // Стадия 3: группируем по району и материалу
  { $group: {
      _id: { district: "$district", material: "$material" },
      total_incidents: { $sum: 1 },
      avg_duration: { $avg: "$duration_hours" },
      max_duration: { $max: "$duration_hours" }
  }},

  // Стадия 4: сортируем по числу инцидентов
  { $sort: { total_incidents: -1 } }
]);

Журнал работы

Подготовьте отчет о выполнении лабораторной работы, содержащий:

1. Текстовое представление репрезентативного документа BSON из учебной коллекции.
2. Текст запроса и результат геопространственной выборки инцидентов в окрестности диспетчерской с подтверждением использования индекса 2dsphere.
3. Результаты агрегационного конвейера: сводную таблицу времени ликвидации аварий по типам труб и районам города.
4. Выводы о границах применимости документоориентированной СУБД для задач оперативного учета инцидентов.