UUID v4 vs v7 (en GUID vs UUID): welke u gebruikt | We.Inc
Hoe UUID v7 verschilt van v4 volgens RFC 9562, waarom tijdgeordende ID's geschikt zijn als databasekeys, wat een GUID is, en een browsertool om v4- en v7-ID's te maken en een v7-timestamp te decoderen.
Beide zijn 128-bit identifiers, geschreven als 36 tekens. Een v4-UUID bestaat uit 122 willekeurige bits, dus nieuwe waarden komen overal in een gesorteerde index terecht. Een v7-UUID begint met een 48-bit Unix-timestamp in milliseconden, gevolgd door willekeurige bits, dus waarden sorteren ongeveer op aanmaaktijd. RFC 9562 raadt v7 aan boven de oudere tijdgebaseerde v1 en v6.
v4 en v7 vergeleken
UUID v4
UUID v7
Gemaakt van
122 willekeurige bits
48-bit timestamp in milliseconden plus 74 willekeurige bits
Sorteervolgorde
Willekeurig
Ongeveer op aanmaaktijd
Verraadt aanmaaktijd
Nee
Ja, tot op de milliseconde
Ingebouwd in browsers
crypto.randomUUID()
Nee, gebruik een paar regels code of een library
Geschikt voor
Tokens, publieke ID's, alles wat geen timing mag lekken
Primaire keys in databases, logs, event-ID's
Een UUID-versie kiezen is vooral een databasevraag. Willekeurige v4-keys verspreiden inserts over een index, terwijl v7-keys op volgorde binnenkomen, net als een auto-increment-nummer, maar zonder centrale teller. Genereer hieronder beide soorten en plak daarna een willekeurige UUID om de versie te zien en, bij v7, het moment waarop hij is gemaakt.
Druk op een genereerknop om in uw browser een nieuwe v4- of v7-UUID te maken.
Kopieer hem, of plak een willekeurige UUID in het decodeervak.
De decoder leest het versiecijfer en de variant-bits, en zet bij v7 de eerste 48 bits om in een datum en tijd.
Genereer een paar v7-waarden achter elkaar en zie hoe hun eerste tekens nauwelijks veranderen.
Sla UUID's op in een native uuid-kolom als uw database die heeft. Zestien bytes is beter dan een string van 36 tekens, voor zowel omvang als vergelijkingen.
Gebruik geen v7 waar de aanmaaktijd gevoelig is, zoals bij tokens voor wachtwoordherstel. Iedereen met het ID kan aflezen wanneer het is gemaakt.
crypto.randomUUID() werkt alleen op beveiligde pagina's (HTTPS of localhost). Via gewoon HTTP is het niet beschikbaar.
Twee v7-ID's die in dezelfde milliseconde zijn gemaakt, worden geordend op hun willekeurige bits, niet op welke eerst kwam, tenzij uw library de optionele tellermethoden uit de RFC gebruikt.
Veelgestelde vragen
Wat is het verschil tussen een GUID en een UUID?
In de praktijk geen enkel verschil dat ertoe doet. RFC 9562 definieert UUID's en vermeldt dat ze ook bekendstaan als GUID's, Globally Unique Identifiers, de naam die tools van Microsoft gebruiken. Een GUID die .NET of SQL Server genereert, is een UUID in hetzelfde formaat van 36 tekens.
Is UUID v7 een officiële standaard?
Ja. RFC 9562, gepubliceerd in 2024, definieert de versies 6, 7 en 8 naast de oudere en vervangt RFC 4122, het document dat UUID's eerder beschreef.
Is UUID v7 uniek genoeg?
Elke milliseconde heeft 74 willekeurige bits om over te verdelen, ruim genoeg voor bijna elk systeem. Voor botsingen zouden enorme aantallen ID's in precies dezelfde milliseconde moeten worden gemaakt.
Kan ik de aanmaaktijd uit een v7-UUID halen?
Ja. De eerste 12 hexcijfers zijn de Unix-tijd in milliseconden. Plak er een in de decoder hierboven om hem als datum te zien, of lees die cijfers zelf als hexadecimaal getal.
Moet ik bestaande v4-keys omzetten naar v7?
Meestal niet. Beide zijn geldige UUID's en kunnen in dezelfde kolom staan, dus nieuwe rijen kunnen v7 gebruiken terwijl oude rijen hun v4-waarden houden. Primaire keys herschrijven betekent elke foreign key herschrijven die ernaar verwijst.
Waarom volgorde ertoe doet voor databases
De meeste databases bewaren primaire keys in een B-tree. Als elke nieuwe key groter is dan de vorige, komen inserts aan het einde van de boom en blijven recent beschreven pagina's in het geheugen. Willekeurige keys dwingen schrijfacties naar pagina's verspreid over de hele boom, wat meer page splits en meer schijfleesacties betekent naarmate een tabel groeit.
RFC 9562 noemt dit localiteitsprobleem als een van de redenen om tijdgeordende versies toe te voegen, en v7 is de versie die het aanraadt voor nieuwe systemen.
De opbouw lezen
In de tekstvorm is het 13e hexcijfer (het eerste van de derde groep) de versie, dus een v7-UUID heeft daar altijd een 7 en een v4 een 4. Het eerste cijfer van de vierde groep is 8, 9, a of b voor de standaardvariant.
Bij v7 vormen de 12 cijfers vóór de versie de timestamp. Alles na het versiecijfer, behalve de twee variant-bits, is willekeurig.
Alle acht UUID-versies
UUID-versies in RFC 9562
Versie
Gemaakt van
Opmerkingen
Gregoriaanse tijd plus een node-ID, vaak het MAC-adres
Verouderd; kies liever v7
DCE Security-versie, niet gespecificeerd door RFC 9562
Zeldzaam
Op naam gebaseerd, MD5-hash van een namespace en een naam
Zelfde invoer, zelfde UUID
Willekeurige of pseudowillekeurige bits
De gangbare standaard
Op naam gebaseerd, SHA-1-hash van een namespace en een naam
Te verkiezen boven v3
De timestamp van v1 herschikt zodat waarden op tijd sorteren
Kies voor nieuwe systemen liever v7
Unix Epoch-tijd in milliseconden plus willekeurige bits
Sorteerbare keys
Eigen opbouw, gekozen door de implementatie
Experimentele of leveranciersformaten
Code om te kopiëren
UUID v4 in de browser of Node
Ingebouwd in huidige browsers op beveiligde pagina's en in Node 19 en later via het globale crypto-object. Geeft een string van 36 tekens terug.
UUID v7 zonder library
Schrijft de huidige tijd in de eerste zes bytes en zet daarna de versie- en variant-bits. De rest blijft willekeurig.
De tijd uit een v7-UUID lezen
De eerste 12 hexcijfers zijn milliseconden sinds 1970, dus ze parsen geeft een Date.
Genereren en decoderen
v4 genereren
v7 genereren
Gegenereerd
Druk op een knop om een UUID te maken. Hij wordt in uw browser gemaakt en nergens naartoe gestuurd.
Plak een UUID om te decoderen
Versie: {v}
RFC 9562 (de standaardvariant)
Niet de RFC 9562-variant
Gemaakt: {v} (UTC)
Deze versie bevat geen Unix-timestamp.
Dat is geen UUID. Verwacht 32 hexcijfers in groepen van 8-4-4-4-12.