ObjectID: анатомия идентификатора

Хранится ObjectID как 12 сырых байт, а 24 hex-символа — это лишь текстовое представление: каждый байт кодируется двумя символами. Внутри — три секции. Первые четыре байта — время в секундах от начала эпохи Unix, записанное big-endian: это и есть время создания, с точностью до секунды. Следующие пять байт — уникальный отпечаток процесса: случайное значение, которое драйвер выбирает один раз при старте процесса и дальше ставит во все идентификаторы этого процесса. Последние три байта — счётчик, который инкрементируется атомарно на каждый новый ObjectID; стартует он тоже со случайного значения, чтобы два процесса не начали с одинаковой точки. Складывая секции, получаем свойства идентификатора: он уникален без единого обращения к серверу, монотонно растёт внутри одного процесса и почти упорядочен по времени между машинами. Именно поэтому mongo objectid стал дефолтным _id в mongo: вставка не требует координации, а база выигрывает плотность записей в индексе — новые документы ложатся в правый край B-дерева, а не раскидываются по всему дереву. Big-endian здесь не украшение: старший байт времени идёт первым, поэтому побайтовое сравнение идентификаторов — это и есть сравнение по времени. Счётчик — три байта, больше шестнадцати миллионов значений: атомарный инкремент на каждый вызов, при переполнении отсчёт начинается заново. У секции времени есть и побочный эффект: hex открывает дату создания любому, кто видит URL, — для номеров заказов это иногда нежелательно, и ниже разберём альтернативы.

В v2 драйвера тип живёт в пакете bson: bson.ObjectID — это массив [12]byte со скромным набором методов, и все они целиком клиентские: ни один не обращается к серверу. NewObjectID() генерирует идентификатор от текущего времени — тот же код, что стоит за автогенерацией _id при вставке. NewObjectIDFromTimestamp(t) собирает ObjectID от произвольной метки — удобно для «синтетических границ» при запросах по диапазону времени, об этом ниже. IsZero() проверяет нулевое значение: пустой ObjectID — это NilObjectID, и отличить «не задан» от «получен из базы» помогает именно он. ObjectIDFromHex и Hex — пара для текстового представления: параметр запроса входит строкой, а уезжает в фильтр уже байтами. Отдельно про сериализацию: ObjectID реализует encoding.TextMarshaler, поэтому в JSON-ответах API автоматически превращается в hex-строку, а не в массив байт — одним пакетом encoding/json решён вопрос «как отдавать _id наружу». Обратное направление продумано так же: UnmarshalText принимает и 24 hex-символа, и 12 сырых байт, а пустую строку декодирует в NilObjectID — необязательный параметр API не ломает разбор. Метка времени в NewObjectIDFromTimestamp задаёт только первые четыре байта: отпечаток процесса и счётчик берутся текущие, поэтому два идентификатора от одной метки различаются. Имена конструкторов переезжать не заставляют: NewObjectID и ObjectIDFromHex называются одинаково в обеих версиях — меняется только пакет. Старый код с primitive.ObjectID переносится заменой импорта: поля, конструкторы и методы совпадают один в один.

Поскольку время стоит в первых байтах, сортировка по _id — это почти сортировка по времени создания: SetSort(bson.D{{Key: "_id", Value: 1}}) выстроит документы от старых к новым без отдельного поля created_at и без индекса поверх него — _id проиндексирован с рождения. На этом держится и пагинация по диапазону: «документы после этого курсора» записывается как {_id: {$gt: последний}}, и следующий лист читается без дорогого skip, о котором подробно поговорим в тринадцатом уроке. Границы диапазона удобно строить из времени: NewObjectIDFromTimestamp(полночь) даёт идентификатор, меньше которого ничего из этого дня нет, — условие {_id: {$gte: утро}, $lt: следующий день} читает документы дня прямо из индекса. Слово «почти» здесь ключевое, и на нём стоит задержаться. Точность времени — секунда: документы одной секунды различаются уже счётчиком, который растёт внутри одного процесса. Значит, для документов одного процесса порядок внутри секунды стабилен, а вот между разными процессами и машинами гарантий нет. Для выдач пользователю, лент и отчетов этого хватает; для строгой хронологии — нет, и следующий коллаут объясняет почему.

Самый частый запрос в любом сервисе — «найди по идентификатору из пути»: /products/68a1f3c4... Параметр приходит строкой, а в фильтр должен уехать bson.ObjectID, поэтому конвертация ставится до запроса: id, err := bson.ObjectIDFromHex(raw). Ошибка конвертации — это 400 от вашего хендлера, а не поход на сервер: строка короче 24 символов, с не-hex символами или пустая отсекается мгновенно. Пропустить проверку и подставить сырую строку в фильтр — значит отправить заведомо пустой запрос: сервер молча вернёт отсутствие совпадений, и вместо честной ошибки «неверный формат» пользователь получит загадочное «не найдено». Дальше всё знакомо: bson.M{"_id": id} — самый дешёвый фильтр в базе, значение лежит в уникальном индексе; FindOne с Decode и ErrNoDocuments работают по правилам шестого урока. Обратный путь — id.Hex() в ответе API или в логе — замыкает круг строка-байты-строка, и никакого второго представления изобретать не нужно. В коллекции при этом лежат именно байты: кодек пишет BSON-тип ObjectID длиной двенадцать, а не строку, — вторая копия hex в документе не заводится, и индекс остаётся компактным. Ошибка ErrNoDocuments здесь — нормальный путь «не найдено»: отдавать её наружу 404-й страницей — решение хендлера, а не драйвера, драйвер честно сообщает о пустоте.

Дефолтный _id хорош всем, кроме особых случаев, и их полезно распознавать заранее. Естественные ключи — артикул, ISBN, slug товара — сами уникальны, и двойной идентификатор только путает: такие коллекции живут с _id-строкой. Распределённым системам, где идентификаторы генерируют десятки сервисов и время машин разъезжается, чаще подходит UUID: 16 байт без намёка на время, зато без утечки «когда создан» наружу — для номеров заказов это иногда требование безопасности. Последовательные номера из бизнес-логики — «номер заказа 1042» — собираются через FindOneAndUpdate с $inc, как в десятом уроке, и живут рядом с ObjectID, а не вместо него. Наконец, URL-дизайн: hex из 24 символов длиннее человеческого slug, поэтому каталоги часто имеют и внутренний _id, и публичный slug с уникальным индексом. Правило простое: ObjectID — разумный дефолт, пока не появился внешний ключ, требование скрыть время или последовательность для людей; тогда выбор осознанный, а не привычный. Для случая UUID готового типа в пакете bson нет — MongoDB хранит UUID бинарным сабтипом, драйвер кодирует []byte, и это ещё один аргумент не заводить UUID без необходимости. С slug-подходом связана и привычная пара индексов: уникальный на slug для публичных страниц и отдельный на created_at для сортировок, которые не хочется привязывать к идентификатору.