Когда в документной БД (MongoDB) выгоднее embedding (вложение), а когда referencing (ссылки)?
- Вкладывать документы или ссылаться на них в MongoDB?
Вложение — для данных, которые читаются вместе и принадлежат одной сущности (заказ с позициями). Ссылки — для многие-ко-многим, неограниченного роста и данных, используемых отдельно.
- Вложение: одно чтение и атомарное обновление (атомарность — на документ)
- Ссылки: нет дублирования, но $lookup или второй запрос
- Лимит документа — 16 МБ; растущие массивы — антипаттерн
А ещё Компромисс — дублировать в документ несколько нужных полей связанной сущности
Подробно
В документной модели нет дешёвых join-ов, поэтому схему проектируют под паттерны доступа. Embedding кладёт связанные данные в один документ: одно чтение, и обновление документа атомарно (атомарность в MongoDB — на уровне одного документа). Это идеально для «читается вместе и принадлежит сущности» (адрес заказа, позиции заказа фиксированной длины). Referencing хранит id и подходит, когда: связь many-to-many, вложенный массив растёт неограниченно (комментарии), либо данные переиспользуются многими и должны быть единым источником правды. Анти-паттерн — безгранично растущие массивы внутри документа (упираются в лимит размера документа и дорого обновляются).
Что хотят услышать
- Критерии вложения и ссылок.
- Атомарность на уровне документа.
- Неограниченный рост как аргумент за ссылки.
Частые ошибки
- Вкладывать безгранично растущие массивы в один документ.
- Ожидать атомарность между несколькими документами без транзакций.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Embedding всегда лучше, ссылок в документных БД не бывает
- ✗Вложение — для связей many-to-many и неограниченно растущих списков; ссылки — для данных, которые читают вместе
- ✓Вложение — для данных одного агрегата, читаемых вместе; ссылки — для many-to-many и неограниченного роста
- ✗Выбор не влияет ни на что, кроме размера на диске
Что спросят дальше
- Каков предел размера документа в MongoDB?
- Что такое атомарность на уровне документа?
Разбор темы
- Документоориентированные БД (MongoDB)
Модель документа, embedding против referencing, индексы, aggregation pipeline, атомарность документа и шардирование.
Связанные вопросы
- Почему в документных БД схему проектируют от запросов, а не нормализуют как в реляционной? Middle
- На каком уровне документная база вроде MongoDB даёт атомарность по умолчанию? Middle
- В документе пользователя хранится массив всех его действий, который постоянно пополняется. Чем плоха такая модель? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.