Документные базы данных

Объект хранится как единый документ

Document Database хранит записи в виде документов — обычно структурированных объектов с полями, вложенными объектами и массивами. Один документ часто соответствует агрегату, который приложение обычно читает и изменяет целиком.

{
  "id": 42,
  "name": "Alex",
  "addresses": [
    { "city": "Denver", "type": "home" }
  ]
}

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

Гибкая структура не означает хаос

Документы одного типа могут иметь различающийся набор полей, что удобно при постепенном развитии модели. Но приложение всё равно должно понимать версии и допустимую структуру данных.

Если новое поле необязательно, старые и новые документы могут некоторое время сосуществовать. При несовместимых изменениях всё равно нужны миграции или логика чтения нескольких версий.

Вложить или сослаться

Если данные маленькие, принадлежат одному агрегату и почти всегда читаются вместе, вложение упрощает чтение. Если объект большой, используется независимо или разделяется между многими сущностями, отдельная запись и ссылка могут быть удобнее.

Слишком большое дублирование усложняет обновления: одно логическое значение приходится синхронно менять во многих документах. Слишком много ссылок, наоборот, возвращает необходимость собирать объект из нескольких запросов.

Запросы зависят от поддерживаемых индексов

Документные базы обычно умеют искать не только по идентификатору, но и по полям документа, если для нужных запросов есть подходящая поддержка и индексы. Это делает модель гибче key-value подхода, но стоимость запросов всё равно нужно учитывать.