В документной базе нет дешёвых JOIN, поэтому схему денормализуют под основные запросы: так, чтобы запрос обслуживался одним документом.
А ещё Тот же принцип в Cassandra и DynamoDB
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
В реляционной модели нормализация убирает дублирование, а join-ы дёшевы. В документной БД join-ов между коллекциями либо нет, либо они дороги ($lookup), поэтому оптимизируют под чтение: связанные данные дублируют/вкладывают так, чтобы основной запрос обслуживался одним документом. Плата — контролируемая денормализация: при изменении продублированных данных их надо обновлять в нескольких местах (или мириться с устареванием). Поэтому сначала определяют ключевые запросы, потом схему — это обратный порядок относительно реляционного дизайна.
Один верный вариант. Подумайте, потом откройте ответ.
Модель документа, embedding против referencing, индексы, aggregation pipeline, атомарность документа и шардирование.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto