Použití UUID místo ObjectID v MongoDB

Použití UUID v Mongo je jistě možné a přiměřeně dobře podporované. Dokumenty Mongo například uvádějí UUID jako jednu z běžných možností pro _id pole.

Úvahy

• Výkon – Jak se uvádí v jiných odpovědích, benchmarky ukazují, že UUID způsobují pokles výkonu pro inserty. V nejhorším měřeném případě (z 10 na 20 milionů dokumentů v kolekci) jsou asi ~2-3x pomalejší – rozdíl mezi vkládáním 2 000 (UUID) a 7 500 (ObjectID) dokumentů za sekundu. To je velký rozdíl, ale jeho význam zcela závisí na vašem případu použití. Budete dávkově vkládat miliony dokumentů najednou? U většiny aplikací, které jsem vytvořil, je běžným případem vkládání jednotlivých dokumentů. Stejné srovnávací hodnoty ukazují, že u tohoto vzoru použití je rozdíl velký menší (6 250 -vs- 7 500; ~20 %). Ne bezvýznamné.. ale ani země tříštící.
• Přenositelnost – Mnoho dalších platforem DB má dobrou podporu UUID, takže by se zlepšila přenositelnost. Alternativně, protože UUID jsou větší (více bitů), je možné přebalit ObjectID do „tvaru“ UUID. Tento přístup není tak příjemný jako přímá přenositelnost, ale poskytuje vám způsob, jak „mapovat“ mezi existujícími ObjectID a UUID.
• Decentralizace – Jednou z hlavních předností UUID je to, že jsou univerzálně jedinečné. Díky tomu je praktické je generovat kdekoli, decentralizovaným způsobem (na rozdíl například od automatického zvyšování hodnoty, které vyžaduje centralizovaný zdroj pravdy k určení „další“ hodnoty). Mongo Object ID samozřejmě vyznávají tuto výhodu také. Rozdíl je v tom, že UUID jsou založeny na 15+ let starém standardu a jsou podporovány na (téměř?) všech platformách, jazycích atd. Díky tomu jsou velmi užitečné, pokud někdy potřebujete vytvořit entity (nebo konkrétně sady souvisejících entity) v nesouvislých systémech, bez interakce s databází. Můžete vytvořit datovou sadu s ID a cizími klíči na svém místě a poté zapsat celý graf do databáze někdy v budoucnu bez konfliktu. Ačkoli je to také možné s Mongo ObjectID, najít kód pro jejich generování / práci s formátem bude často těžší.

Opravy

Na rozdíl od některých dalších odpovědí:

• UUID mají nativní podporu Mongo – Můžete použít UUID() fungovat v Mongo Shell přesně stejným způsobem, jakým byste použili ObjectID(); převést řetězec UUID na ekvivalentní objekt BSON.
• UUID nejsou nijak zvlášť velké – Při kódování pomocí binárního podtypu 0x04 jsou 128 bitů ve srovnání s 96 bity pro ObjectID. (Pokud jsou zakódovány jako řetězce, budou být docela plýtvání, zabere asi 288 bitů.)
• UUID mohou obsahovat časové razítko – Konkrétně UUIDv1 kóduje časové razítko s přesností 60 bitů ve srovnání s 32 bity v ObjectID. To je o více než 6 řádů větší přesnost, takže nanosekundy místo sekund. Ve skutečnosti to může být slušný způsob ukládání časových razítek vytvoření s větší přesností než podpora objektů Mongo/JS Date, nicméně...
  • Sestavení v UUID() funkce generuje pouze v4 (náhodné) UUID, takže abyste toho mohli využít, měli byste se při vytváření ID opřít o svou aplikaci nebo ovladač Mongo.
  • Na rozdíl od ObjectID vám časové razítko nedává přirozené pořadí kvůli způsobu, jakým jsou UUID rozdělena. To může být dobré nebo špatné v závislosti na vašem případu použití. (Nové standardy to mohou změnit; viz aktualizace z roku 2021 níže.)
  • Zahrnout do ID časová razítka je někdy špatný nápad. Skončíte s únikem vytvořeného času dokumentů, kdekoli je ID vystaveno. (Objektová ID samozřejmě také kódují časové razítko, takže to částečně platí i pro ně.)
  • Pokud to uděláte s (splňujícími specifikace) v1 UUID, zakódujete také část adresy MAC serverů, což může potenciálně použít k identifikaci stroje. Pravděpodobně to není problém pro většinu systémů, ale také to není ideální. (Nové standardy to mohou změnit; viz aktualizace z roku 2021 níže.)

Závěr

Pokud uvažujete o své Mongo DB izolovaně, ObjectID jsou jasnou volbou. Fungují dobře hned po vybalení a jsou dokonale schopným výchozím nastavením. Použití UUID místo toho dělá přidat určité tření, jak při práci s hodnotami (potřeba převodu na binární typy atd.), tak z hlediska výkonu. Zda se tato drobná nepříjemnost vyplatí mít standardizovaný formát ID skutečně závisí na důležitosti, kterou přikládáte přenositelnosti, a na vašich architektonických volbách.

Budete synchronizovat data mezi různými databázovými platformami? Budete v budoucnu migrovat svá data na jinou platformu? Potřebujete vygenerovat ID venku databázi, v jiných systémech nebo v prohlížeči? Pokud ne nyní, někdy v budoucnu? UUID možná stojí za ty potíže.

Aktualizace ze srpna 2021

IEFT nedávno zveřejnila návrh aktualizace specifikace UUID, která by zavedla některé nové verze formátu.

Konkrétně UUIDv6 a UUIDv7 jsou založeny na UUIDv1, ale převrátí bloky časových značek, takže bity jsou uspořádány od nejvýznamnějšího po nejméně významný. To dává výsledným hodnotám přirozený řád, který (víceméně) odráží pořadí, ve kterém byly vytvořeny. Nové verze také vylučují data odvozená z MAC adresy serverů, čímž řeší dlouhodobou kritiku UUID v1.

Než se tyto změny promítnou do implementací, bude to chvíli trvat, ale (IMHO) výrazně modernizují a vylepšují formát.