Използването на UUID в Mongo със сигурност е възможно и доста добре поддържано. Например, документите на Mongo изброяват UUID като една от често срещаните опции за _id поле.
Съображения
- Ефективност – Както се споменава в други отговори, бенчмарковете показват, че UUID причиняват спад в производителността за вмъквания. В най-лошия измерен случай (преминаване от 10 милиона до 20 милиона документи в колекция) те са около ~2-3 пъти по-бавни – разликата между вмъкването на 2 000 (UUID) и 7 500 (ObjectID) документа в секунда. Това е голяма разлика, но нейното значение зависи изцяло от вашия случай на използване. Ще вмъквате ли групово милиони документи наведнъж? За повечето приложения, които съм изградил, обичайният случай е вмъкването на отделни документи. Същите бенчмаркове показват, че за този модел на използване разликата е много по-малък (6 250 срещу 7 500; ~20%). Не е маловажно.. но не и разтърсващо.
- Преносимост – Много други DB платформи имат добра поддръжка на UUID, така че преносимостта ще бъде подобрена. Като алтернатива, тъй като UUID са по-големи (повече битове), е възможно да се преопакова ObjectID във "формата" на UUID. Този подход не е толкова приятен, колкото директната преносимост, но ви дава начин да „картографирате“ между съществуващите ObjectID и UUID.
- Децентрализация – Една от големите точки за продажба на UUID е, че те са универсално уникални. Това прави практично генерирането им навсякъде, по децентрализиран начин (за разлика например от автоматично нарастваща стойност, която изисква централизиран източник на истина за определяне на "следващата" стойност). Разбира се, идентификаторите на Mongo Object също изповядват това предимство. Разликата е, че UUID са базирани на 15+ годишен стандарт и се поддържат на (почти?) всички платформи, езици и т.н. Това ги прави много полезни, ако някога се наложи да създадете обекти (или по-специално набори от свързани обекти) в разделени системи, без да взаимодействат с базата данни. Можете да създадете набор от данни с идентификатори и външни ключове на място, след което да запишете цялата графика в базата данни в някакъв момент в бъдещето без конфликт. Въпреки че това е възможно и с Mongo ObjectIDs, намирането на код за генерирането им/работата с формата често ще бъде по-трудно.
Корекции
Противно на някои от другите отговори:
- UUID имат собствена поддръжка на Mongo – Можете да използвате
UUID()функционират в Mongo Shell точно по същия начин, по който бихте използвалиObjectID(); за да конвертирате UUID низ в еквивалентен BSON обект. - UUID не са особено големи – Когато се кодира с помощта на двоичен подтип
0x04те са 128 бита, в сравнение с 96 бита за ObjectID. (Ако са кодирани като низове, те ще бъдете доста разточителни, като поемате около 288 бита.) - UUID могат да включват времева марка – По-конкретно, UUIDv1 кодира времеви печат с 60 бита прецизност, в сравнение с 32 бита в ObjectIDs. Това е с над 6 порядъка по-голяма точност, така че нано-секунди вместо секунди. Това всъщност може да бъде приличен начин за съхраняване на създаване на времеви печати с по-голяма точност от поддръжката на Mongo/JS Date обекти, обаче...
- Вградената в
UUID()функцията генерира само v4 (случайни) UUID, така че, за да използвате това, трябва да разчитате на вашето приложение или драйвер Mongo за създаване на идентификационен номер. - За разлика от ObjectIDs, поради начина, по който UUID са разделени на парчета, клеймото за време не ви дава естествен ред. Това може да бъде добро или лошо в зависимост от вашия случай на употреба. (Новите стандарти може да променят това; вижте актуализацията за 2021 г. по-долу.)
- Включването на времеви отпечатъци в личните ви документи понякога е лоша идея. В крайна сметка изтичате създаденото време на документи навсякъде, където е изложен идентификатор. (Разбира се, ObjectID също кодират клеймо за време, така че това отчасти е вярно и за тях.)
- Ако направите това с (съвместими със спецификации) v1 UUID, вие също кодирате част от MAC адреса на сървъра, което може потенциално да се използва за идентифициране на машината. Вероятно не е проблем за повечето системи, но също така не е идеален. (Новите стандарти може да променят това; вижте актуализацията за 2021 г. по-долу.)
- Вградената в
Заключение
Ако мислите за вашата Mongo DB в изолация, ObjectIDs са очевидният избор. Те работят добре от кутията и са напълно способни по подразбиране. Използването на UUID вместо това прави добавете малко триене, както при работа със стойностите (необходимост от преобразуване в двоични типове и т.н.), така и по отношение на производителността. Дали това леко неудобство си струва да имате стандартизиран формат за идентификация наистина зависи от значението, което отдавате на преносимостта и архитектурния си избор.
Ще синхронизирате ли данни между различни платформи за бази данни? Ще мигрирате ли данните си към друга платформа в бъдеще? Трябва ли да генерирате ID външни базата данни, в други системи или в браузъра? Ако не сега, в някакъв момент в бъдещето? UUID-ите може да си струват труда.
Актуализация от август 2021 г.
IEFT наскоро публикува чернова на актуализация на спецификацията на UUID, която ще въведе някои нови версии на формата.
По-конкретно, UUIDv6 и UUIDv7 са базирани на UUIDv1, но обръщат парчетата от времевия печат, така че битовете да са подредени от най-значими към най-малко значими. Това дава на получените стойности естествен ред, който (повече или по-малко) отразява реда, в който са създадени. Новите версии също така изключват данни, извлечени от MAC адреса на сървъра, като адресират дългогодишната критика към v1 UUID.
Ще отнеме време, докато тези промени влязат в реализацията, но (IMHO) те значително модернизират и подобряват формата.
