Hva er UUID v7, og hvorfor skiller den seg fra UUID v4?
UUID v7 er en 128-bit identifikator representert som 36 tegn i standard UUID-format. De første tegnene er et 48-bit Unix millisekund-tidsstempel, etterfulgt av tilfeldige bits. Til sammen 128 bits gir 2^128 mulige verdier, men den kritiske forskjellen ligger i hvordan de er organisert.
I UUID v4 er alle 122 tilfeldige bits (de resterende 6 bits er for versjon og variant) – hver ID er fullstendig tilfeldig. Det betyr at to UUID v4-er opprettet rett etter hverandre kan ha helt forskjellige starttegn, noe som fører til dårlig indekslokalitet i B-trær. Når en database setter inn en ny rad med UUID v4 som primærnøkkel, må B-treet balanseres oftere fordi nye verdier ikke nødvendigvis havner i samme bladnode som de forrige. Dette gir økt fragmentering, flere disk-I/O og dårligere skriveytelse.
UUID v7 løser dette ved å la tidsstempelet styre plasseringen. For ID-er generert med samme millisekund vil de første tegnene være identiske, og for ID-er generert i påfølgende millisekunder vil de være monotont økende. Dette gjør at B-treet kan holde nye rader samlet i samme område, noe som reduserer side-splitting og cache-tap.
Men – og dette er viktig – UUID v7 garanterer ikke streng rekkefølge for ID-er generert i samme millisekund. Hvis to systemer eller to tråder genererer hver sin ID i løpet av samme millisekund, kan de havne i hvilken som helst rekkefølge innbyrdes. For de fleste bruksområder er dette akseptabelt; den kronologiske grovsorteringen er nok til å oppnå bedre indeksytelse, samtidig som man beholder uforutsigbarhet.
Slik fungerer uuid-v7-generatoren
Generatoren på denne siden er en ren nettleserløsning. Inndataene du gir – antall ID-er (mellom 1 og 100), om de skal vises med store eller små bokstaver, og om bindestreker skal inkluderes – behandles lokalt via JavaScript. Ingenting sendes til BroBroGo eller noen annen ekstern server.
Når du endrer en innstilling, regenereres hele listen umiddelbart. Dette skyldes at alle valg påvirker utdataformatet: å slå av bindestreker gir en 32-tegns streng uten bindestreker, å velge store bokstaver gir en versjon der a-f-komponentene er store.
Utdataene presenteres som en liste. Du kan klikke på en enkelt ID for å kopiere den til utklippstavlen, eller bruke "Kopier alle" for å kopiere hele listen. Statusfeltet viser "Klar" før generering, "Generert" etter, og "Kopiert alle!" når kopiering er fullført.
En viktig detalj: generatoren bruker nettleserens egne kryptografiske tilfeldigheter (window.crypto.getRandomValues). Dette gir samme styrke som serverbaserte løsninger, men uten nettverkskostnader eller personvernrisiko. For de fleste bruksområder er dette fullt tilstrekkelig; for svært høyvolum-systemer kan man vurdere å generere på server for å unngå at nettleserens entropi-kilde blir en flaskehals, men for 1–100 ID-er av gangen er det uproblematisk.
Avveininger med tidsbaserte UUID-er
Den største avveiningen er mellom streng sorterbarhet og parallellitetsytelse. UUID v7 er designet for å være grovt sorterbar, ikke strengt. Hvis to hendelser oppstår i samme millisekund, kan ID-enes rekkefølge avvike fra hendelsesrekkefølgen. I praksis betyr dette at UUID v7 ikke er egnet som eneste kilde for hendelsesrekkefølge i et distribuert system med høy samtidighet. For slike tilfeller trenger man enten en logisk klokke (som Lamport-klokker) eller en sekvensgenerator.
Sammenlignet med ULID (Universally Unique Lexicographically Sortable Identifier) har UUID v7 en annen bit-distribusjon: ULID bruker 48 bit for tidsstempel og 80 bit tilfeldighet, totalt 128 bit, men representeres som 26 tegn i base32. UUID v7 bruker samme 48 bit tidsstempel, men bare 74 bit tilfeldighet (de resterende 6 bit er fastsatt for versjon og variant). ULID har dermed høyere tilfeldig kapasitet, men UUID v7 er en offisiell IETF-standard (RFC 9562) og har bredere støtte i verktøy og biblioteker.
Den kryptografiske tilfeldigheten i UUID v7 er sterk nok til å gjøre ID-ene uforutsigbare for praktiske angrep. Hvis du trenger å forhindre at noen kan gjette neste ID basert på tidligere ID-er, er UUID v7 et godt valg. Men for scenarier der man ønsker full sporbarhet eller der uforutsigbarhet er uønsket, er sekvensielle ID-er et bedre alternativ.
Hvem har nytte av UUID v7
Utviklere av distribuerte systemer trenger ID-er som kan genereres uavhengig på ulike noder uten at det kreves koordinering. UUID v7 gir dette, samtidig som ID-ene kan sorteres grovt kronologisk – nyttig for hendelseslogging, meldingskøer og replikering.
Databaseadministratorer som sliter med indeksfragmentering forårsaket av UUID v4, kan bytte til UUID v7 og oppnå bedre skriveytelse uten å måtte endre skjemaet vesentlig. Effekten er mest synlig i B-tre-baserte databaser som PostgreSQL, MySQL og SQLite. For eksempel: i PostgreSQL vil en UUID v4-primærnøkkel føre til at indeksen hyppig må splitte sider, mens UUID v7 legger nye rader i samme sideområde.
Sikkerhetsbevisste utviklere verdsetter at UUID v7 ikke lekker informasjon om rekkefølgen av hendelser på en måte som gjør det mulig å utlede antall objekter eller tidspunkt for opprettelse. Tidsstempelet er bare millisekund-presist, og den tilfeldige delen gjør at man ikke kan se hvor mange ID-er som ble generert i et gitt tidsrom med mindre man har tilgang til alle ID-ene.
De som migrerer fra UUID v4 finner at overgangen til v7 krever minimal endring. Skjemaet forblir det samme (36 tegn eller 128 bit), og de fleste ORM-er og databasebiblioteker støtter UUID som datatype uavhengig av versjon. Man trenger bare å bytte genereringsmetode.
Teknisk struktur og standarder
UUID v7 er definert i RFC 9562, som spesifiserer bit-oppsettet:
- Bits 0-47 (48 bit): Unix millisekund-tidsstempel (heltall, big-endian)
- Bits 48-51 (4 bit): Versjonsnummer (0111 = 7)
- Bits 52-55 (4 bit): Variant (10xx for standard UUID)
- Bits 56-127 (72 bit): Tilfeldige bits
Totalt 128 bit, hvorav 48 + 72 = 120 bit er fleksible (tidsstempel + tilfeldighet). De 6 bitene for versjon og variant er faste.
Tidsstempelet er antall millisekunder siden Unix-epoch (1. januar 1970 00:00 UTC). Dette betyr at UUID v7-ID-er sorterer leksikografisk i tekstform for ID-er fra forskjellige millisekunder, fordi de første tegnene i den heksadesimale representasjonen tilsvarer de mest signifikante bitene av tidsstempelet. For eksempel: en ID generert kl. 12:00:00.000 har tidsstempel 1700000000000 (avhengig av dato), som i heks blir 18B2... – tegnene "18" vil være de samme for alle ID-er i det millisekundet.
Formateringsvalg: store bokstaver og bindestreker
Standard UUID-representasjon bruker bindestreker og små bokstaver: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Bindestrekene er valgfrie; uten dem får man en 32-tegns streng. Store bokstaver endrer bare visningen: 550E8400-E29B-41D4-A716-446655440000 i stedet for 550e8400-e29b-41d4-a716-446655440000.
Hvilket format du bør velge avhenger av bruksområdet:
- Bindestreker forbedrer lesbarheten og er ofte påkrevd av standarder når UUID-er utveksles i tekstform.
- Uten bindestreker sparer plass og er vanlig i lagring (f.eks. som CHAR(32) i databaser).
- Store bokstaver brukes noen ganger av estetiske årsaker, men påvirker ikke unikhet eller sortering fordi heksadesimale tegn behandles uavhengig av store/små bokstaver i de fleste sammenhenger.
En advarsel: Hvis du lagrer UUID-er uten bindestreker, må du være konsekvent i det hele systemet. Blanding av formater kan føre til duplikater eller søkeproblemer. Generatoren på denne siden lar deg velge format fritt, men i produksjon bør du beslutte ett format og holde deg til det.
Ofte stilte spørsmål
Er UUID v7 garantert unik?
Ja, med astronomisk høy sannsynlighet. Sjansen for kollisjon er omtrent 2^(-72) per par, gitt at tidsstemplet er forskjellig. For ID-er i samme millisekund er sannsynligheten for kollisjon 2^(-72), noe som er ekstremt lavt. I praksis vil du aldri oppleve en kollisjon med mindre du genererer milliarder av ID-er per millisekund.
Kan jeg bruke UUID v7 som primærnøkkel i en database?
Absolutt. Det er en av de viktigste bruksområdene. UUID v7 gir bedre indeksytelse enn UUID v4, spesielt i B-tre-indekser. Men vær oppmerksom på at ingen UUID-versjon er like rask som en sekvensiell heltallsnøkkel – avveiningen er global unikhet vs. ytelse.
Hva er forskjellen mellom UUID v7 og ULID?
Begge har 48-bit tidsstempel og 80/72 bit tilfeldighet. ULID er 26 tegn langt i base32, UUID v7 er 36 tegn i heksadesimal. ULID er ikke en offisiell RFC-standard, men støttes av mange biblioteker. UUID v7 har bredere støtte i offisielle UUID-biblioteker og er standardisert.
Hvorfor bør jeg bytte fra UUID v4 til UUID v7?
Hvis du opplever dårlig databaseytelse på grunn av indeksfragmentering, eller hvis du ønsker kronologisk sorterbare ID-er uten å miste uforutsigbarhet, er UUID v7 et naturlig valg. Migrasjonen er triviell: du trenger bare å bytte genereringsfunksjon.
Er generatoren trygg å bruke i produksjon?
Ja, fordi all generering skjer lokalt i nettleseren. Ingen data sendes til noen server. Nettleserens kryptografiske tilfeldigheter er tilstrekkelig for de fleste formål. Hvis du genererer ID-er i stor skala på server, bør du bruke et dedikert bibliotek, men for mindre batch-behov (1–100 om gangen) fungerer nettleserløsningen utmerket.
Hva skjer hvis jeg endrer innstillingene etter at ID-er er generert?
Listen regenereres umiddelbart med de nye innstillingene. Du mister de forrige ID-ene, med mindre du har kopiert dem separat. Dette er designet for å sikre at utdataene alltid samsvarer med gjeldende valg.