Het gebruik van UUID's in Mongo is zeker mogelijk en wordt redelijk goed ondersteund. De Mongo-documenten vermelden bijvoorbeeld UUID's als een van de algemene opties voor de _id veld.
Overwegingen
- Prestaties - Zoals andere antwoorden vermelden, laten benchmarks zien dat UUID's een prestatiedaling voor inserts veroorzaken. In het slechtste geval gemeten (van 10 miljoen naar 20 miljoen documenten in een verzameling) zijn ze ongeveer 2-3x langzamer - het verschil tussen het invoegen van 2.000 (UUID) en 7.500 (ObjectID) documenten per seconde. Dit is een groot verschil, maar de betekenis ervan hangt volledig af van uw gebruikssituatie. Gaat u batchgewijs miljoenen documenten tegelijk invoegen? Voor de meeste apps die ik heb gebouwd, is het gebruikelijke geval het invoegen van afzonderlijke documenten. Uit dezelfde benchmarks blijkt dat voor dat gebruikspatroon het verschil veel is kleiner (6.250 -vs- 7.500; ~20%). Niet onbelangrijk.. maar ook niet wereldschokkend.
- Draagbaarheid – Veel andere DB-platforms hebben goede UUID-ondersteuning, zodat de draagbaarheid zou worden verbeterd. Als alternatief, aangezien UUID's groter zijn (meer bits), is het mogelijk om een ObjectID opnieuw in te pakken in de "vorm" van een UUID. Deze aanpak is niet zo mooi als directe overdraagbaarheid, maar het geeft je wel een manier om te "kaarten" tussen bestaande ObjectID's en UUID's.
- Decentralisatie – Een van de grote verkoopargumenten van UUID's is dat ze universeel uniek zijn. Dit maakt het praktisch om ze overal te genereren, op een gedecentraliseerde manier (in tegenstelling tot bijvoorbeeld een automatisch oplopende waarde, die een centrale bron van waarheid vereist om de "volgende" waarde te bepalen). Natuurlijk bieden Mongo Object-ID's dit voordeel ook. Het verschil is dat UUID's zijn gebaseerd op een 15+ jaar oude standaard en worden ondersteund op (bijna?) alle platforms, talen, enz. Dit maakt ze erg handig als u ooit entiteiten moet maken (of specifiek sets van gerelateerde entiteiten) in onsamenhangende systemen, zonder interactie met de database. U kunt een dataset maken met ID's en externe sleutels en vervolgens de hele grafiek op een bepaald moment in de toekomst zonder conflicten in de database schrijven. Hoewel dit ook mogelijk is met Mongo ObjectID's, zal het vaak moeilijker zijn om code te vinden om ze te genereren/werken met het formaat.
Correcties
In tegenstelling tot sommige andere antwoorden:
- UUID's hebben native Mongo-ondersteuning – U kunt de
UUID(). gebruiken functioneren in de Mongo Shell op precies dezelfde manier waarop uObjectID(). zou gebruiken; om een UUID-string om te zetten in een equivalent BSON-object. - UUID's zijn niet bijzonder groot – Indien gecodeerd met binair subtype
0x04ze zijn 128 bits, vergeleken met 96 bits voor ObjectID's. (Als ze zijn gecodeerd als strings, zullen ze behoorlijk verspillend zijn, ongeveer 288 bits nemen.) - UUID's kunnen een tijdstempel bevatten – In het bijzonder codeert UUIDv1 een tijdstempel met 60 bits precisie, vergeleken met 32 bits in ObjectID's. Dit is meer dan 6 ordes van grootte nauwkeuriger, dus nanoseconden in plaats van seconden. Het kan eigenlijk een fatsoenlijke manier zijn om tijdstempels voor het maken op te slaan met meer nauwkeurigheid dan Mongo/JS Date-objecten ondersteunen, maar...
- De ingebouwde
UUID()functie genereert alleen v4 (willekeurige) UUID's, dus om hier gebruik van te maken, moet u op uw app of Mongo-stuurprogramma leunen voor het maken van ID's. - In tegenstelling tot ObjectID's, geeft de tijdstempel je geen natuurlijke volgorde, vanwege de manier waarop UUID's worden gechunkt. Dit kan goed of slecht zijn, afhankelijk van uw gebruik. (Nieuwe normen kunnen dit veranderen; zie update 2021 hieronder.)
- Het opnemen van tijdstempels in uw ID's is soms een slecht idee. U lekt uiteindelijk de gecreëerde tijd van documenten overal waar een ID wordt weergegeven. (Natuurlijk coderen ObjectID's ook voor een tijdstempel, dus dit geldt gedeeltelijk ook voor hen.)
- Als je dit doet met (spec-compliant) v1 UUID's, codeer je ook een deel van het MAC-adres van de server, wat mogelijk worden gebruikt om de machine te identificeren. Waarschijnlijk geen probleem voor de meeste systemen, maar ook niet ideaal. (Nieuwe normen kunnen dit veranderen; zie update 2021 hieronder.)
- De ingebouwde
Conclusie
Als u alleen over uw Mongo DB nadenkt, zijn ObjectID's de voor de hand liggende keuze. Ze werken goed uit de doos en zijn een perfect capabele standaard. In plaats daarvan UUID's gebruiken doet voeg wat wrijving toe, zowel bij het werken met de waarden (moeten converteren naar binaire typen, enz.) Als in termen van prestaties. Of dit kleine ongemak de moeite waard is om een gestandaardiseerd ID-formaat te hebben, hangt echt af van het belang dat u hecht aan draagbaarheid en uw architecturale keuzes.
Gaat u gegevens synchroniseren tussen verschillende databaseplatforms? Ga je in de toekomst je data migreren naar een ander platform? Moet u ID's buiten genereren? de database, in andere systemen of in de browser? Zo niet nu op een bepaald moment in de toekomst? UUID's zijn misschien de moeite waard.
Aug. 2021-update
De IEFT heeft onlangs een conceptupdate van de UUID-specificatie gepubliceerd die enkele nieuwe versies van het formaat zou introduceren.
In het bijzonder zijn UUIDv6 en UUIDv7 gebaseerd op UUIDv1, maar draaien de tijdstempel-chunks om zodat de bits worden gerangschikt van meest significant naar minst significant. Dit geeft de resulterende waarden een natuurlijke volgorde die (min of meer) de volgorde weerspiegelt waarin ze zijn gemaakt. De nieuwe versies sluiten ook gegevens uit die zijn afgeleid van het MAC-adres van de server, waarmee een al lang bestaande kritiek op v1-UUID's wordt aangepakt.
Het zal enige tijd duren voordat deze wijzigingen zijn doorgevoerd in implementaties, maar (IMHO) ze moderniseren en verbeteren het formaat aanzienlijk.