UUID v4 vs. v7: hvilken unik identifikator skal du vælge?
En UUID er en unik 128-bit-identifikator uden central koordinering. Version 4, fuldstændig tilfældig, har domineret i årevis. Version 7, nyere (RFC 9562, 2024), indlejrer et tidsstempel i begyndelsen for at producere tidsordnede identifikatorer. Denne forskel, tilsyneladende ubetydelig, ændrer radikalt ydeevnen i databasen. Her er, hvilken du skal vælge.
Hvad er en UUID?
En UUID (Universally Unique Identifier) er et 128-bit-tal repræsenteret ved 32 hexadecimale tegn grupperet i fem blokke, for eksempel 550e8400-e29b-41d4-a716-446655440000. Dens formål: at generere en unik identifikator uden at spørge en central myndighed, hvilket gør den ideel til distribuerede systemer. Du kan generere dem med vores UUID-generator.
Der findes flere versioner; de mest relevante i dag til nøgler for poster er v4 (tilfældig) og v7 (tidsordnet).
UUID v4 (tilfældig)
UUID v4 består af 122 tilfældige bit (resten koder versionen og varianten). Sandsynligheden for kollision er så lav, at den i praksis er ubetydelig. Det er standardversionen i de fleste sprog og biblioteker.
- Uforudsigelig: perfekt til tokens eller offentlige identifikatorer, som man ikke ønsker skal kunne gættes
- Ingen informationslækage: afslører hverken dato eller oprettelsesrækkefølge
- Ulempe: fuldstændig uordnet, hvilket plager databaseindekser
UUID v7 (tidsordnet)
UUID v7 placerer et Unix-tidsstempel i millisekunder i sine første 48 bit efterfulgt af tilfældige bit. To UUID v7 genereret på forskellige tidspunkter sorteres derfor i deres oprettelsesrækkefølge, samtidig med at de forbliver unikke og praktisk talt umulige at gætte.
- Sorterbar: den leksikografiske rækkefølge svarer til den kronologiske rækkefølge
- Indeksvenlig: indsættelser sker i slutningen af indekset, som en auto-inkrement
- Modydelse: den afslører oprettelsesøjeblikket, hvilket kan være uønsket for en offentlig identifikator
Sammenligningstabel
| Kriterium | UUID v4 | UUID v7 |
|---|---|---|
| Sammensætning | 122 tilfældige bit | Tidsstempel + tilfældig |
| Tidsordnet | Nej | Ja |
| Sorterbar | Nej | Ja (kronologisk) |
| Indeksydeevne | Lav (fragmentering) | Høj (sekventielle indsættelser) |
| Uforudsigelighed | Total | Høj, men afslører øjeblikket |
| Informationslækage | Ingen | Oprettelsesdato |
| Modenhed / understøttelse | Universel | Nyere (RFC 9562, 2024) |
Indvirkning på databaser
Det er kernen i sagen. Relationelle databaser gemmer deres indekser i B-træer (B-tree). At indsætte tilfældige nøgler (v4) spreder skrivningerne overalt i indekset og forårsager fragmentering, sideopsplitninger og en mindre effektiv cache. Ved store mængder forringes indsættelsesydeevnen markant.
Ordnede nøgler (v7) indsættes altid i slutningen af indekset, som en auto-inkrementeret identifikator. Man får hurtige indsættelser, bedre lokalitet og et mere kompakt indeks. Det er især tydeligt med en primærnøgle i InnoDB (MySQL), hvor primærnøglen bestemmer rækkernes fysiske rækkefølge.
Hvornår skal du vælge den ene eller den anden
Vælg UUID v4, når
- Identifikatoren er eksponeret offentligt og må ikke afsløre noget
- Du genererer tokens, delingslinks, hemmeligheder
- Rækkefølge og oprettelsesdato må ikke kunne gættes
- Du vil have maksimal kompatibilitet med det eksisterende
Vælg UUID v7, når
- UUID'en bruges som primærnøgle i en database
- Indsættelsesmængden er høj, og indeksydeevnen er vigtig
- Du vil sortere efter oprettelsesrækkefølge uden en dedikeret kolonne
- At afsløre oprettelsesøjeblikket ikke er et problem
Anbefaling
Til en databaseprimærnøgle bør du nu foretrække UUID v7: du beholder UUID'ens distribuerede unikhed og undgår samtidig v4's indeksstraf. Behold UUID v4 til offentlige identifikatorer, tokens og hemmeligheder, hvor total uforudsigelighed og fravær af tidsmæssig lækage har forrang.
Kontrollér dog understøttelsen af v7 i dit sprog og din ORM: RFC'en er nyere, men udbredelsen skrider hurtigt frem.
Ofte stillede spørgsmål
Er UUID v7 mindre sikker end v4?
Den forbliver meget svær at gætte takket være sine tilfældige bit, men den afslører oprettelsesøjeblikket via sit tidsstempel. Til en offentlig identifikator, hvor datoen ikke må lække, eller til en hemmelighed bør du foretrække v4.
Hvorfor gør UUID v4 databaser langsommere?
Fordi dens tilfældige værdier spreder indsættelserne over hele B-tree-indekset, hvilket fragmenterer siderne og reducerer cachens effektivitet. v7, ordnet, indsætter i slutningen af indekset og undgår dette problem.
Kan jeg migrere fra v4 til v7?
Ja for nye poster: de to formater kan sameksistere i samme UUID-kolonne. Det er unødvendigt at omskrive historikken; skift blot genereringen af nye nøgler til v7.
Hvad med version v1 og v6?
v1 koder tidsstemplet og MAC-adressen, hvilket giver problemer med privatlivet. v6 omordner v1 for at gøre den sorterbar. Til et nyt projekt er v7 den ordnede version anbefalet af RFC 9562.