Collections

Коллекции — это пространства имён для документов с общими ожиданиями по запросам, валидации и жизненному циклу, а не просто «таблицы с другим названием». Делите или объединяйте коллекции по ownership, access pattern, retention и совместимости shard key.

					// Разные коллекции, когда расходятся lifecycle и индексы
db.orders.insertOne({ ... })       // горячие транзакционные данные
db.order_events.insertOne({ ... }) // append-only audit trail
				

| Делить коллекции, когда | Держать вместе, когда | |-------------------------|----------------------| | Разный TTL или архивная политика | Всегда читаются как единое целое | | Разные shard keys или cardinality | Одни индексы обслуживают все запросы | | Независимые write rates | Общая валидация и ownership | | Границы безопасности / tenancy | Рост документа ограничен |

На уровне коллекции важны `validator`, `collation`, capped collections для логов фиксированного размера и time series collections для метрик.

На интервью: обоснуйте границы коллекций query shapes и операционными политиками, а не «красотой папок».

Типовые ошибки: одна огромная коллекция с несвязанными формами документов; разделение, после которого всегда нужны join в приложении; игнорирование shard key при проектировании; смешение PII и публичных данных.

Компромисс — изоляция эксплуатации vs стоимость join: больше коллекций упрощает масштабирование и политики, но переносит связи в приложение или aggregation pipeline.

Чеклист:

• Сопоставьте коллекцию с owner и access pattern.
• Опишите validation, TTL и архивную политику.
• Объясните последствия shard key заранее.
• Назовите, когда допустима цена `$lookup`.