Documents

Документ MongoDB — это BSON-запись, обычно один JSON-образный aggregate, который приложение читает или обновляет целиком. Хороший дизайн начинается с access patterns: какие поля читаются вместе, как растут вложенные массивы и насколько велик один write.

					// Агрегат заказа: один read отдаёт checkout summary
{
  _id: ObjectId("..."),
  customerId: "c_12",
  status: "paid",
  items: [{ sku: "A1", qty: 2, price: 19.99 }],
  totals: { subtotal: 39.98, tax: 3.2 },
  createdAt: ISODate("2026-06-15T10:00:00Z")
}
				

| Задача | Рычаг в документе | |--------|-------------------| | Локальность чтения | Встраивать данные, читаемые вместе | | Конкуренция записи | Выносить горячие поля в отдельные docs | | Рост | Ограничивать массивы; архивировать историю | | Дрейф схемы | Валидация в приложении + опционально JSON Schema |

`_id` неизменяем; natural keys — только если стабильны. Имена полей и типы должны быть предсказуемы для индексов и aggregation.

На интервью: объясните, почему сформировали один документ, а не много строк, и назовите компромисс read/update.

Типовые ошибки: неограниченные массивы внутри документа; смешивание несвязанных сущностей «потому что Mongo schemaless»; документы близко к лимиту 16 MB; перезапись всего документа ради мелкого поля, когда помогло бы разделение.

Компромисс — между локальностью чтения и усилением записи: глубокий embedding ускоряет reads, но усложняет конкурентные updates и рост документа.

Чеклист:

• Назовите доминирующие read и write paths.
• Покажите пример aggregate-shaped документа.
• Объясните nesting vs split по contention и росту.
• Упомяните лимиты BSON и владение валидацией.