Verwenden von UUIDs anstelle von ObjectIDs in MongoDB

Die Verwendung von UUIDs in Mongo ist sicherlich möglich und wird einigermaßen gut unterstützt. Beispielsweise listen die Mongo-Dokumente UUIDs als eine der gängigen Optionen für _id auf Feld.

Überlegungen

• Leistung – Wie andere Antworten erwähnen, zeigen Benchmarks, dass UUIDs einen Leistungsabfall für Einfügungen verursachen. Im schlechtesten gemessenen Fall (von 10 Mio. auf 20 Mio. Dokumente in einer Sammlung) sind sie etwa 2-3x langsamer – der Unterschied zwischen dem Einfügen von 2.000 (UUID) und 7.500 (ObjectID) Dokumenten pro Sekunde. Dies ist ein großer Unterschied, aber seine Bedeutung hängt ganz von Ihrem Anwendungsfall ab. Werden Sie Millionen von Dokumenten gleichzeitig einfügen? Bei den meisten Apps, die ich erstellt habe, besteht der häufigste Fall darin, einzelne Dokumente einzufügen. Dieselben Benchmarks zeigen, dass der Unterschied für dieses Nutzungsmuster groß ist kleiner (6.250 vs. 7.500; ~20 %). Nicht unbedeutend.. aber auch nicht weltbewegend.
• Portabilität – Viele andere DB-Plattformen haben eine gute UUID-Unterstützung, sodass die Portabilität verbessert würde. Da UUIDs größer sind (mehr Bits), ist es alternativ möglich, eine ObjectID in die "Form" einer UUID umzupacken. Dieser Ansatz ist nicht so schön wie die direkte Portabilität, aber er gibt Ihnen eine Möglichkeit, zwischen bestehenden ObjectIDs und UUIDs "zuzuordnen".
• Dezentralisierung – Eines der großen Verkaufsargumente von UUIDs ist, dass sie universell einzigartig sind. Dies macht es praktisch, sie überall dezentral zu generieren (im Gegensatz zu beispielsweise einem automatisch inkrementierenden Wert, der eine zentrale Quelle der Wahrheit erfordert, um den "nächsten" Wert zu bestimmen). Natürlich bekennen sich auch Mongo Object IDs zu diesem Vorteil. Der Unterschied besteht darin, dass UUIDs auf einem über 15 Jahre alten Standard basieren und auf (fast?) allen Plattformen, Sprachen usw. unterstützt werden. Dies macht sie sehr nützlich, wenn Sie jemals Entitäten (oder insbesondere Sätze von verwandten Entitäten) in unzusammenhängenden Systemen, ohne mit der Datenbank zu interagieren. Sie können einen Datensatz mit IDs und Fremdschlüsseln erstellen und dann das gesamte Diagramm irgendwann in der Zukunft ohne Konflikte in die Datenbank schreiben. Obwohl dies auch mit Mongo ObjectIDs möglich ist, ist es oft schwieriger, Code zu finden, um sie zu generieren/mit dem Format zu arbeiten.

Korrekturen

Im Gegensatz zu einigen anderen Antworten:

• UUIDs haben native Mongo-Unterstützung – Sie können die UUID() verwenden Funktion in der Mongo Shell genau so, wie Sie ObjectID() verwenden würden; um einen UUID-String in ein äquivalentes BSON-Objekt umzuwandeln.
• UUIDs sind nicht besonders groß – Bei Codierung mit dem binären Subtyp 0x04 sie sind 128 Bit, verglichen mit 96 Bit für ObjectIDs. (Wenn sie als Strings kodiert werden, werden sie ziemlich verschwenderisch sein und ungefähr 288 Bit benötigen.)
• UUIDs können einen Zeitstempel enthalten – Insbesondere codiert UUIDv1 einen Zeitstempel mit einer Genauigkeit von 60 Bit im Vergleich zu 32 Bit in ObjectIDs. Das ist über 6 Größenordnungen mehr Präzision, also Nanosekunden statt Sekunden. Es kann tatsächlich eine anständige Möglichkeit sein, Erstellungszeitstempel mit größerer Genauigkeit zu speichern, als Mongo/JS Date-Objekte unterstützen, jedoch ...
  • Die eingebaute UUID() -Funktion generiert nur (zufällige) v4-UUIDs. Um dies zu nutzen, müssen Sie sich bei der ID-Erstellung auf Ihre App oder Ihren Mongo-Treiber stützen.
  • Im Gegensatz zu ObjectIDs gibt Ihnen der Zeitstempel aufgrund der Art und Weise, wie UUIDs aufgeteilt werden, keine natürliche Reihenfolge. Dies kann je nach Anwendungsfall gut oder schlecht sein. (Neue Standards können dies ändern; siehe Update 2021 unten.)
  • Das Einfügen von Zeitstempeln in Ihre IDs ist manchmal eine schlechte Idee. Am Ende verlieren Sie die Erstellungszeit von Dokumenten überall dort, wo eine ID offengelegt wird. (Natürlich kodieren ObjectIDs auch einen Zeitstempel, also gilt das teilweise auch für sie.)
  • Wenn Sie dies mit (spezifikationskonformen) v1-UUIDs tun, codieren Sie auch einen Teil der MAC-Adresse des Servers, was möglicherweise passieren kann verwendet werden, um die Maschine zu identifizieren. Wahrscheinlich kein Problem für die meisten Systeme, aber auch nicht ideal. (Neue Standards können dies ändern; siehe Update 2021 unten.)

Schlussfolgerung

Wenn Sie Ihre Mongo DB isoliert betrachten, sind ObjectIDs die offensichtliche Wahl. Sie funktionieren gut aus der Box und sind ein perfekt fähiger Standard. Die Verwendung von UUIDs statt dessen geht etwas Reibung hinzufügen, sowohl bei der Arbeit mit den Werten (Konvertierung in binäre Typen usw.) als auch in Bezug auf die Leistung. Ob diese kleine Unannehmlichkeit es wert ist, ein standardisiertes ID-Format zu haben, hängt wirklich von der Bedeutung ab, die Sie der Portabilität und Ihren architektonischen Entscheidungen beimessen.

Werden Sie Daten zwischen verschiedenen Datenbankplattformen synchronisieren? Werden Sie Ihre Daten in Zukunft auf eine andere Plattform migrieren? Müssen Sie IDs außerhalb generieren der Datenbank, in anderen Systemen oder im Browser? Wenn nicht jetzt, irgendwann in der Zukunft? UUIDs könnten den Aufwand wert sein.

Update vom August 2021

Die IEFT hat kürzlich einen Aktualisierungsentwurf für die UUID-Spezifikation veröffentlicht, der einige neue Versionen des Formats einführen würde.

Insbesondere basieren UUIDv6 und UUIDv7 auf UUIDv1, drehen jedoch die Zeitstempelblöcke um, sodass die Bits von höchstwertig zu niedrigstwertig angeordnet sind. Dadurch erhalten die resultierenden Werte eine natürliche Reihenfolge, die (mehr oder weniger) die Reihenfolge widerspiegelt, in der sie erstellt wurden. Die neuen Versionen schließen auch Daten aus, die von der MAC-Adresse des Servers abgeleitet werden, und adressieren damit eine langjährige Kritik an v1-UUIDs.

Es wird einige Zeit dauern, bis diese Änderungen in Implementierungen einfließen, aber (IMHO) modernisieren und verbessern sie das Format erheblich.