Базы, коллекции и документы

Вопрос «mongo коллекции go-код как достаёт» решается двумя вызовами. client.Database("shop") возвращает mongo.Database — дескриптор базы, db.Collection("orders") возвращает mongo.Collection — дескриптор коллекции. Важнейший факт про оба типа: это лёгкие дескрипторы, а не сетевые объекты. Ни Database, ни Collection ничего не отправляют на сервер в момент создания — они просто запоминают имя; создать их можно сколько угодно, даже в цикле, без единого пакета по сети. Вся сетевая жизнь начинается на операциях: InsertOne, FindOne, CountDocuments — вот где ходят пакеты. Оба типа потокобезопасны: один дескриптор коллекции можно смело разделять между горутинами, мьютексы в вашем коде для этого не нужны. Дешевизна дескрипторов даёт рабочий стиль: дескрипторы коллекций создаются в одном месте — в конструкторе хранилища или пакете моделей — и живут столько же, сколько приложение; никаких Collection-на-запрос. Два вызова Database с одним именем вернут два независимых дескриптора — они равнозначны, и с какими работать — вопрос стиля: половина кодовых баз берёт дескриптор базы один раз в конструкторе, а коллекции от него при инициализации хранилища.

Документы mongodb — единица хранения и обмена: именно они летят по сети в BSON, именно их видит mongosh. Документ — упорядоченный набор полей: в BSON порядок значим, и драйвер это уважает, когда пишет структуры и bson.D. Типы полей богаче JSON: int32 и int64 различаются, дата — time.Time с миллисекундной точностью, деньги — Decimal128, идентификатор — ObjectID, значения могут быть массивами и вложенными документами без ограничения глубины, кроме лимита размера. Есть и привычные по JSON штуки: null, бинарные данные, логические значения. У каждого документа есть _id — первичный ключ коллекции: он существует всегда, уникален и неизменяем. Если вы его не задали, драйвер сгенерирует ObjectID на стороне клиента при вставке — об этом подробнее в уроке про ObjectID. По умолчанию в коллекции нет требования совпадения форм: соседние документы могут отличаться полями, и это осознанная свобода — схема переезжает в ваши Go-структуры с bson-тегами, а база остаётся исполнителем. Поле _id после вставки неизменяемо — обновить его не даст ни драйвер, ни сервер, поэтому продумайте ключ заранее: миграция идентификаторов на живой коллекции делается перезаписью всех документов.

В MongoDB нет CREATE TABLE: база и коллекция возникают в момент первой записи. Вставили документ в shop.orders — появились и база shop, и коллекция orders, с дефолтными настройками. До первой вставки пустые коллекции не существуют — show collections в mongosh их не покажет. Ленивость удобна для прототипов и раздражает в проде, и вот почему: коллекция создаётся по имени, а имя берётся из кода, где живут опечатки. Плюс драйвера в том, что дескриптор с несуществующим именем ошибки не даст — минус в том, что ошибки и не даст: вставка молча создаст коллекцию с кривым именем, и половина данных окажется в order вместо orders. Для настроек — capped-коллекции фиксированного размера для кольцевых логов, валидация схемы, индексы — существуют явные команды создания, их разберём во второй половине курса — в уроках про индексы и валидацию схемы, а типовая вставка обходит их стороной.

Единственный распространённый сценарий, где коллекцию создают явно и заранее, — capped: фиксированный кольцевой буфер. db.CreateCollection(ctx, "events", options.CreateCollection().SetCapped(true).SetSizeInBytes(10_000_000)) создаёт коллекцию, в которой новые записи вытесняют старые, когда место кончилось: последние десять мегабайт событий всегда на месте, чистить ничего не нужно. Лимит по числу документов задаётся SetMaxDocuments. Типовые обитатели таких коллекций — аудиторские события, поток логов, очередь сообщений для чтения tailable-курсором — курсором, который не закрывается на конце, а ждёт новых записей, как tail -f. Альтернатива capped для чистки — TTL-индекс, который удаляет документы по возрасту: он требует отдельного индекса и разбирается в соответствующем уроке. Те же опции CreateCollection умеют навешивать валидатор схемы — до него дойдём отдельным уроком; для обычных коллекций дефолтного ленивого создания достаточно. Проверить настройки можно в mongosh через db.events.isCapped() — маленькая команда, которая иногда отвечает на большой вопрос «почему мои старые данные исчезли».

Сколько нужно клиентов — вопрос с почти всегда одним ответом: один. mongo.Client потокобезопасен и ведёт внутренний пул соединений: горутины берут сокеты по мере надобности и возвращают их обратно, а вам не нужно ничего синхронизировать. Дескрипторы Database и Collection создаются от клиента в один момент — обычно в конструкторе приложения — и передаются зависимостям дальше: репозиториям, хендлерам, воркерам. Второй клиент оправдан в двух случаях: тесты с отдельным окружением и редкие операции, которым нужна изоляция настроек, вроде отдельного read preference для аналитики; оба сценария мы тронем позже — в уроках про тесты и производительность. Клиент на каждый HTTP-запрос — антипаттерн из первого дня: каждый несёт собственный пул, сервер копит лишние сокеты, а latency растёт на установке соединения. Если мигрируете с ORM-мира, ориентир тот же, что и у sql.DB или GORM: долгоживущий хендл, короткоживущие операции. Отдельный плюс одного клиента — единая точка настройки: параметры пула, read preference по умолчанию и мониторинг настраиваются на клиенте один раз, а не в каждой коллекции.

Мультитенантность — сценарий, где вопрос «одна база или несколько» возникает всерьёз. Три рабочих раскладки. Первая: общая база, поле tenant_id в каждом документе и индекс, начинающийся с него; проще всего в эксплуатации, требует дисциплины в фильтрах. Вторая: общая база, коллекция на клиента (orders_acme, orders_globex); изоляция данных нагляднее, но количество коллекций растёт линейно с клиентами, а кросс-тенантные отчёты превращаются в обход. Третья: база на клиента; максимальная изоляция — бэкапы и экспорт клиента делаются командой, но лимиты на количество коллекций и администрирование наступают быстрее, чем кажется. Я вижу первую раскладку по умолчанию и откат к третьей, когда у клиента есть требование физической изоляции. Выбирайте до того, как появятся данные: переезд между раскладками — это ручная миграция каждой коллекции. И не переусложняйте раньше времени: если клиентов меньше пяти, первая раскладка выигрывает почти всегда, а изоляция добирается дисциплиной фильтров и индексом с префиксом tenant_id.