Brug af UUID'er i Mongo er bestemt muligt og rimeligt godt understøttet. For eksempel viser Mongo-dokumenterne UUID'er som en af de almindelige muligheder for _id felt.
Overvejelser
- Ydeevne – Som andre svar nævner, viser benchmarks UUID'er forårsager et ydelsesfald for indsatser. I værste tilfælde målt (fra 10 millioner til 20 millioner dokumenter i en samling) er de ca. ~2-3 gange langsommere – forskellen mellem at indsætte 2.000 (UUID) og 7.500 (ObjectID) dokumenter pr. sekund. Dette er en stor forskel, men dens betydning afhænger helt af din brugssituation. Vil du batch-indsætte millioner af dokumenter ad gangen? For de fleste apps, jeg har bygget, er det almindelige tilfælde at indsætte individuelle dokumenter. De samme benchmarks viser, at forskellen for det brugsmønster er meget mindre (6.250 -vs- 7.500; ~20%). Ikke ubetydeligt.. men heller ikke jordskælvende.
- Portabilitet – Mange andre DB-platforme har god UUID-understøttelse, så portabiliteten ville blive forbedret. Alternativt, da UUID'er er større (flere bits), er det muligt at ompakke et ObjectID til "formen" af et UUID. Denne tilgang er ikke så god som direkte portabilitet, men den giver dig en måde at "kortlægge" mellem eksisterende ObjectID'er og UUID'er.
- Decentralisering - Et af de store salgsargumenter ved UUID'er er, at de er universelt unikke. Dette gør det praktisk at generere dem hvor som helst, på en decentral måde (i modsætning til f.eks. en automatisk stigende værdi, der kræver en centraliseret kilde til sandhed for at bestemme den "næste" værdi). Selvfølgelig bekender Mongo Object ID'er også denne fordel. Forskellen er, at UUID'er er baseret på en 15+ år gammel standard og understøttes på (næsten?) alle platforme, sprog osv. Dette gør dem meget nyttige, hvis du nogensinde har brug for at oprette entiteter (eller specifikt sæt af relaterede) enheder) i usammenhængende systemer uden at interagere med databasen. Du kan oprette et datasæt med id'er og fremmednøgler på plads, og derefter skrive hele grafen ind i databasen på et tidspunkt i fremtiden uden konflikt. Selvom dette også er muligt med Mongo ObjectID'er, vil det ofte være sværere at finde kode til at generere dem/arbejde med formatet.
Rettelser
I modsætning til nogle af de andre svar:
- UUID'er har indbygget Mongo-understøttelse – Du kan bruge
UUID()fungerer i Mongo Shell nøjagtigt på samme måde, som du ville brugeObjectID(); at konvertere en UUID-streng til tilsvarende BSON-objekt. - UUID'er er ikke særlig store – Når den er kodet ved hjælp af binær undertype
0x04de er 128 bit sammenlignet med 96 bit for ObjectID'er. (Hvis de er kodet som strenge, vil det være temmelig spild, idet den tager omkring 288 bit.) - UUID'er kan indeholde et tidsstempel – Specifikt koder UUIDv1 et tidsstempel med 60 bits præcision sammenlignet med 32 bits i ObjectID'er. Dette er over 6 størrelsesordener mere præcision, så nano-sekunder i stedet for sekunder. Det kan faktisk være en anstændig måde at gemme oprette tidsstempler med mere nøjagtighed end Mongo/JS Date-objekter understøtter, dog...
- Den indbyggede
UUID()funktionen genererer kun v4 (tilfældige) UUID'er, så for at udnytte dette, skal du læne dig op af din app eller Mongo-driver for at oprette id. - I modsætning til ObjectID'er giver tidsstemplet dig ikke en naturlig rækkefølge på grund af den måde, UUID'er er opdelt i. Dette kan være godt eller dårligt afhængigt af din brugssituation. (Nye standarder kan ændre dette; se 2021-opdatering nedenfor.)
- At inkludere tidsstempler i dine id'er er nogle gange en dårlig idé. Du ender med at lække den oprettede tid af dokumenter overalt, hvor et ID er afsløret. (Selvfølgelig koder ObjectID'er også for et tidsstempel, så dette er til dels også sandt for dem.)
- Hvis du gør dette med (specifikke kompatible) v1 UUID'er, koder du også en del af serverens MAC-adresse, som potentielt kan bruges til at identificere maskinen. Sandsynligvis ikke et problem for de fleste systemer, men heller ikke ideelt. (Nye standarder kan ændre dette; se 2021-opdatering nedenfor.)
- Den indbyggede
Konklusion
Hvis du tænker på din Mongo DB isoleret, er ObjectID'er det oplagte valg. De fungerer godt ud af boksen og er en perfekt stand standard. Brug af UUID'er i stedet gør tilføje noget friktion, både når man arbejder med værdierne (skal konvertere til binære typer osv.) og i forhold til ydeevne. Hvorvidt denne lille besvær er værd at have et standardiseret ID-format, afhænger virkelig af den betydning, du lægger på portabilitet og dine arkitektoniske valg.
Vil du synkronisere data mellem forskellige databaseplatforme? Vil du migrere dine data til en anden platform i fremtiden? Har du brug for at generere ID'er udenfor databasen, i andre systemer eller i browseren? Hvis ikke nu på et tidspunkt i fremtiden? UUID'er kan være besværet værd.
Opdatering august 2021
IEFT offentliggjorde for nylig et udkast til opdatering af UUID-specifikationen, der ville introducere nogle nye versioner af formatet.
Specifikt er UUIDv6 og UUIDv7 baseret på UUIDv1, men vend tidsstemplets bidder, så bits er arrangeret fra mest signifikant til mindst signifikant. Dette giver de resulterende værdier en naturlig orden, der (mere eller mindre) afspejler den rækkefølge, de blev skabt i. De nye versioner udelukker også data, der stammer fra serverens MAC-adresse, hvilket imødekommer en langvarig kritik af v1 UUID'er.
Det vil tage tid for disse ændringer at flyde igennem til implementeringer, men (IMHO) de moderniserer og forbedrer formatet markant.