Псевдо первичные ключи в MongoDB - плохая идея?

Question

http://code.flickr.com/blog/page/4/

Это сообщение в блоге от разработчиков Flickr, в котором описывается их упрощенный подход к созданию идентификаторов GUID для фотографий в защищенной базе данных с использованием mysql.

Я работаю над приложением, которое использует MongoDB для хранения данных, которое имеет аналогичные требования для элементов, хранящихся во встроенных документах. По сути, документ в коллекции представляет собой список элементов, а затем отдельные элементы внутри , каждый из которых должен иметь какой-то идентификатор, также для целей поиска. Я бы предпочел не помещать элементы в другую коллекцию, поскольку ключи списка, которые не являются элементами, на самом деле являются просто метаданными и не должны иметь свою собственную коллекцию. В идеале это должен быть один документ.

Я думал, что для решения этой проблемы может быть реализован подход, подробно описанный в сообщении в блоге - одна конечная точка, которая генерирует GUID для этих записей и сохраняет последнее использованное значение. Проблема в том, что я не уверен, если этот подход создает проблемы при шардинге хранилища данных в монго. У меня нет опыта распространения Mongo на несколько машин. Я предполагаю, что прикладной уровень может проверить эту конечную точку при сохранении данных и установить соответствующий ключ _id, но я не знаю, как это повлияет на запросы к набору данных.

Будет ли установка такой системы GUID ошибочной идеей? Я понимаю, что это противоречит некоторым принципам NoSQL в целом, но поскольку документы встроены, какая альтернатива существует?

Answer 1

Я думаю, ObjectID - это путь.Они хранятся гораздо компактнее, чем GUID / UUID, и поддерживают примерно увеличивающийся порядок, что имеет преимущества для индексации.Он также предназначен для генерации на стороне клиента без необходимости использования сервера билетов, как описано в статье.Единственный реальный недостаток по сравнению с их решением состоит в том, что они используют 12 байтов, а int64 использует 8 (GUID / UUID используют 16 в двоичном или 32 в шестнадцатеричном формате плюс несколько байтов служебных данных).Еще один потенциальный недостаток (который в большинстве случаев выгоднее) заключается в том, что поскольку время создания кодируется в ObjectId, если они используются для общедоступных идентификаторов, это может привести к утечке нежелательной информации пользователям, например, когда другой пользователь подписалк вашим услугам.