Основная философия
Проектирование схемы в MongoDB определяется паттернами запросов приложения, а не правилами нормализации, как в реляционных БД. Основная цель — структурировать данные вокруг того, как они будут читаться и записываться, а не того, как они организованы логически.
Встраивание vs. Ссылки
Выбор между этими двумя подходами — самое критичное решение:
- Встраивание хранит связанные данные внутри одного документа — идеально для данных, которые всегда читаются вместе и имеют отношение один-ко-многим (один-ко-нескольким)
- Ссылки хранят связанные данные в отдельных коллекциях, связанных по ID — лучше для больших, часто обновляемых или независимо читаемых данных
- Допускай контролируемое дублирование данных, когда оно улучшает производительность чтения
Проектирование индексов
- Создавай индексы, которые прямо поддерживают твои самые частые запросы
- Избегай избыточного индексирования, так как каждый индекс добавляет накладные расходы при записи
- Используй составные индексы, когда запросы фильтруют или сортируют по нескольким полям
Структура документа
Согласуй форму документа с поведением приложения:
- Группируй поля, которые читаются вместе, в один документ
- Избегай глубоко вложенных структур, которые усложняют запросы
- Держи документы в пределах лимита BSON в 16MB, используя ссылки для больших или неограниченных наборов данных (например, массивов, которые растут бесконечно)
Планирование масштабируемости
- Проектируй с учётом шардирования с самого начала, если предусмотрено горизонтальное масштабирование
- Выбирай ключ шардирования, который равномерно распределяет данные и согласуется с частыми паттернами запросов
Главный вывод
В отличие от реляционных БД, в MongoDB нет единственно правильной схемы. Лучший дизайн — это тот, который делает твои самые критичные запросы приложения быстрыми, простыми и эффективными — даже если это означает некоторое дублирование в хранимых данных.