Я создаю службу, для которой я буду использовать MongoDB в качестве хранилища. Служба создаст хэш ввода пользователя, а затем увидит, существует ли тот же хэш (+ вход) в нашем наборе данных.
Хэш будет уникальным, но случайным (= неинкрементным/последовательным), поэтому мой вопрос:
$object_id = new MongoId(HEX-OF-96BIT-HASH);
Или MongoDB обрабатывает ObjectID иначе, чем другие серверные, поскольку "реальный" ObjectID также содержит отметки времени, machine_id и т.д.
Каковы плюсы и минусы использования "случайного" значения? Я думаю, было бы статистически медленнее, если бы движок обновил индекс на вставках, когда новый _id никоим образом не является инкрементным - верю ли я на это?
Да, отлично использовать случайное значение для идентификатора объекта, если какое-то значение присутствует в поле _id хранящегося документа, оно рассматривается как objectId.
Так как поле _id всегда индексируется и первичный ключ, вам нужно убедиться, что для каждого объекта создается другой объект.
Существуют некоторые рекомендации по оптимизации идентификаторов объектов, определенных пользователем:
Хотя любые значения, включая хеши, могут использоваться для поля _id, я бы рекомендовал не использовать случайные значения по двум причинам:
Возможно, вам понадобится разработать стратегию управления конфликтами в случае, если вы производите одинаковые случайные значения для двух разных объектов. В этом вопросе вы подразумеваете, что вы будете генерировать идентификаторы, используя некоторый тип хэш-алгоритма. Я бы не считал эти значения "случайными", поскольку они основаны на содержании, которое вы перевариваете хешем. Тогда вероятность столкновения является функцией разнообразия контента и алгоритма хеширования. Если вы используете что-то вроде MD5 или SHA-1, я бы не стал беспокоиться об алгоритме, просто о том, что вы хешируете. Если вам нужно разработать стратегию управления конфликтами, то вам определенно не следует использовать случайные или хэш-идентификаторы, поскольку управление столкновением в кластерной среде сложнее и требует дополнительных запросов.
Случайные значения, а также хэш-значения целенаправленно предназначены для разгона на числовой строке. Для того, чтобы (a) требовалось больше хранить индекс B-дерева в памяти в любое время, и (b) может вызвать переменную производительность вставки из-за перебалансировки B-дерева. MongoDB оптимизирован для обработки ObjectID, которые поступают в порядке возрастания (с однократной детализацией). Скорее всего, вам лучше будет придерживаться их.
Хорошо ли это или плохо, зависит от его уникальности. Конечно, ObjectId, предоставленный MongoDB, совершенно уникален, так что это хорошо. Пока вы можете воспроизвести эту уникальность, тогда вы должны быть в порядке.
Не существует собственных рисков/производительности при использовании собственного идентификатора. Я предполагаю, что использование его в строковой форме может использовать больше возможностей индекса/хранения/запросов, но там вы используете его в форме MongoID (ObjectId), которая должна сохранять сильные стороны не хранить его в простой строке.
Я только что узнал ответ на один из моих вопросов относительно производительности индексирования:
Если _id находятся в несколько четком порядке, то при вставках не нужно загружать все b-дерево для индекса _id. Объект BSON ObjectIds имеет это свойство.
Источник: http://www.mongodb.org/display/DOCS/Optimizing+Object+IDs