Что такое документоориентированная БД

Зачем понадобилась ещё одна модель данных и чем документ отличается от строки таблицы.

MongoDB — документоориентированная NoSQL-база данных, которая хранит данные не в таблицах со строками и столбцами, а в гибких документах формата JSON.

Реляционная модель в двух словах

Если вы работали с PostgreSQL или MySQL, картина знакома: данные лежат в таблицах, каждая запись — это строка с фиксированным набором столбцов. Схема задаётся заранее: у таблицы users есть колонки id, name, email, и каждая строка обязана им соответствовать. Связанные данные раскладывают по разным таблицам и собирают обратно через JOIN.

Эта модель отлично подходит, когда структура данных стабильна и важна строгая целостность. Но у неё есть цена: чтобы показать одну сущность (скажем, заказ с товарами и адресом), приходится склеивать несколько таблиц, а изменить схему на живой большой таблице — дорогая операция.

Документная модель: данные как объект

MongoDB предлагает другой взгляд. Вместо того чтобы дробить сущность по таблицам, вы храните её целиком — как вложенный объект, очень похожий на JSON. Вот один пользователь:

{
  "_id": "u1",
  "name": "Анна",
  "email": "[email protected]",
  "address": {
    "city": "Казань",
    "zip": "420000"
  },
  "roles": ["author", "editor"]
}

Заметьте: адрес — это вложенный объект, а роли — массив, и всё это лежит внутри одного документа. В реляционной БД для этого понадобились бы как минимум три таблицы и два JOIN. Здесь — один документ, который читается одним запросом.

NoSQL — не значит «без SQL-возможностей»

Термин NoSQL («Not Only SQL») объединяет базы, которые отказались от строгой табличной модели ради гибкости и горизонтального масштабирования. MongoDB — самый популярный представитель документного семейства. Это не значит, что в ней нет мощных запросов: есть и фильтры, и сортировки, и агрегации, и аналог JOIN. Просто язык запросов другой — это методы над коллекциями, а не SQL.

Когда документная модель выигрывает

• Гибкая или меняющаяся структура. Разные документы в одной коллекции могут иметь разные поля — удобно для каталогов товаров, где у телефона и у книги почти нет общих характеристик.
• Данные читаются целиком. Профиль пользователя, карточка товара, статья с комментариями — всё это естественно ложится в один документ.
• Высокая нагрузка и масштабирование. MongoDB изначально проектировалась под распределение данных по множеству серверов (шардирование).

А вот для данных с множеством сложных связей и строгими транзакциями (банковские проводки, бухгалтерия) реляционная БД нередко уместнее. Выбор модели — это всегда компромисс под конкретную задачу, а не «что новее».

Итог

• MongoDB хранит данные в гибких JSON-подобных документах, а не в таблицах со строгой схемой.
• Связанные данные часто вкладывают внутрь одного документа вместо раскладывания по таблицам.
• NoSQL — это другая модель данных и другой язык запросов, а не отсутствие запросов вообще.
• Документная модель сильна там, где данные читаются целиком и структура может меняться.