UUID-generator

UUID-standaarden en Gedistribueerde Identiteit

De Universally Unique Identifier werd voor het eerst gestandaardiseerd in RFC 4122 (2005), hoewel de wortels teruggaan naar het Apollo Network Computing System in de jaren 1980 en het Distributed Computing Environment (DCE) van de Open Software Foundation. Het fundamentele probleem dat UUID's oplossen is het genereren van wereldwijd unieke identifiers zonder centrale coordinatie-autoriteit — essentieel voor gedistribueerde systemen waar meerdere machines onafhankelijk ID's moeten aanmaken die nooit zullen botsen. RFC 4122 definieerde vijf UUID-versies voor verschillende gebruikssituaties. Versie 1 bevat een 60-bits timestamp (intervallen van 100 nanoseconden sinds 15 oktober 1582 — de Gregoriaanse kalenderhervorming) gecombineerd met een 48-bits node-identifier oorspronkelijk afgeleid van het MAC-adres. Hoewel het uniciteit garandeerde, lekte v1 hardware-identiteit en aanmaaktijd. Versies 3 en 5 zijn op naam gebaseerd: ze hashen een namespace-identifier gecombineerd met een naam met MD5 (v3) of SHA-1 (v5), wat deterministische UUID's oplevert. Versie 4 verving determinisme door 122 bits cryptografische willekeur en werd de meest gebruikte versie. De nieuwste standaard, RFC 9562 (2024), introduceerde UUID v7 als aanbevolen keuze voor database-vriendelijke identifiers. Versie 7 bevat een 48-bits Unix-milliseconde-timestamp in de meest significante bits, gevolgd door willekeurige vulbits. Dit ontwerp creëert identifiers die chronologisch sorteren — een cruciaal voordeel voor B-tree-database-indexen waar willekeurige v4-UUID's excessieve paginasplitsingen veroorzaken. Benchmarks tonen consistent aan dat v7-UUID's de invoegdoorvoer met 20-40% verbeteren vergeleken met v4. De botsingskans van UUID v4 wordt bepaald door de verjaardagsparadox. Met 122 willekeurige bits bevat de ruimte 5,3 x 10^36 mogelijke waarden. De kans om een duplicaat te genereren bereikt 50% pas na het produceren van ongeveer 2,71 x 10^18 UUID's. Concurrerende formaten zijn Twitters Snowflake-ID's (64-bit), ULID's (128-bit met Crockford Base32-codering), NanoID's (compacte URL-veilige strings) en database auto-increment-sequenties. Elk brengt afwegingen met zich mee tussen uniciteitsgaranties, sorteerbaarheid, opslaggrootte en coordinatievereisten.

Methodologie

UUID v4-generatie is gebaseerd op de crypto.randomUUID()-methode van de browser uit de Web Crypto API, die 128 bits produceert waarvan 122 cryptografisch willekeurig zijn en 6 gereserveerd zijn voor versie- (4 bits ingesteld op 0100) en variantmarkeringen (2 bits ingesteld op 10). Dit zorgt ervoor dat elke UUID zelfbeschrijvend is — u kunt de versie identificeren door het 13e hexadecimale teken te inspecteren. UUID v7 sluit een 48-bits Unix-timestamp in milliseconden in de meest significante bits in, gevolgd door willekeurige vulbits. Dit ontwerp produceert identifiers die zowel uniek als natuurlijk tijdgeordend zijn, waardoor ze ideaal zijn voor database-primaire sleutels waar B-tree-indexprestaties belangrijk zijn. UUID v1 gebruikt een 60-bits timestamp met een resolutie van 100 nanoseconden sinds 15 oktober 1582 (de datum van de Gregoriaanse kalenderhervorming), een 14-bits kloksequentie om duplicaten bij klokaanpassingen te voorkomen, en een 48-bits node-identificatie die willekeurig wordt gegenereerd voor privacybescherming. ULID's coderen een 48-bits milliseconde-timestamp gevolgd door 80 willekeurige bits, weergegeven in Crockford Base32 voor compacte, hoofdletterongevoelige representatie. NanoID's gebruiken een configureerbaar alfabet en lengte, standaard 21 tekens uit een URL-veilige set, wat 126 bits entropie biedt.

Je resultaten begrijpen

Elke UUID is een 128-bits waarde weergegeven als 32 hexadecimale tekens in 5 groepen gescheiden door streepjes, volgens het patroon 8-4-4-4-12. Het canonieke formaat is xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, waarbij de M-positie (13e hex-teken) de versie aangeeft en de N-positie (17e hex-teken) de variant aangeeft. Voor UUID v4 is M altijd '4' en N is een van '8', '9', 'a' of 'b', wat RFC 4122-conformiteit bevestigt. Voor UUID v7 is M '7' en coderen de eerste 12 hex-tekens de milliseconde-timestamp, waardoor de aanmaaktijd direct leesbaar is. UUID v1 plaatst M als '1' met de timestamp verdeeld over de eerste drie groepen in een herschikt volgorde. ULID's worden weergegeven als 26 hoofdletter Crockford Base32-tekens — de eerste 10 coderen de timestamp en de overige 16 coderen willekeur. NanoID's verschijnen als compacte strings met URL-veilige tekens (A-Z, a-z, 0-9, streepje, underscore), zonder inherente structurele markers. Bij het kiezen van een formaat, overweeg dat UUID's met accolades gebruikelijk zijn in Microsoft-ecosystemen, terwijl UUID's zonder streepjes opslag besparen in databases.

Praktische voorbeelden

Database-primaire sleutels: Gebruik UUID v7 voor PostgreSQL- of MySQL-tabellen waar invoegvolgorde belangrijk is. De ingebedde timestamp zorgt voor sequentiële sleutelwaarden, waardoor willekeurige I/O-spreiding die UUID v4 veroorzaakt op geclusterde indexen wordt vermeden. Microservice-eventtracking: Genereer UUID v4 voor correlatie-ID's die door berichtenwachtrijen (Kafka, RabbitMQ) worden doorgegeven. De pure willekeur garandeert nul botsingen, zelfs wanneer duizenden services tegelijkertijd ID's produceren. Frontend-sessietokens: Gebruik NanoID voor compacte, URL-veilige sessie-identifiers in single-page applicaties. Met 21 tekens zijn ze korter dan UUID's terwijl ze gelijkwaardige botsingsresistentie behouden. Bestandsnaamgeving en deduplicatie: Genereer ULID's voor geüploade bestandsidentifiers. Hun lexicografische sorteerbaarheid betekent dat een eenvoudige alfabetische lijst bestanden in chronologische uploadvolgorde toont.

Tips en Aanbevelingen

Kies uw UUID-versie op basis van uw gebruikssituatie in plaats van standaard v4 te gebruiken. Als uw identifiers als database-primaire sleutels dienen, bieden UUID v7 of ULID aanzienlijk betere invoegprestaties omdat hun tijdgeordende aard B-tree-indexen sequentieel houdt, waardoor paginasplitsingen en fragmentatie worden verminderd. Voor gedistribueerde systemen waar meerdere nodes onafhankelijk ID's genereren, elimineert de pure willekeur van UUID v4 elk risico op timestamp-gebaseerde botsingen. Bij het werken met URL's of gebruikersgerichte identifiers is het compacte 21-tekens formaat van NanoID praktischer dan een 36-tekens UUID. Sla UUID's altijd op als hun native 128-bits binaire type in databases wanneer beschikbaar (bijv. PostgreSQL's uuid-type of MySQL's BINARY(16)) in plaats van als VARCHAR(36)-strings. Dit halveert de opslag en verbetert de vergelijkingsprestaties. Bij het debuggen vertelt het versiecijfer (positie 13) u direct welke UUID-variant u bekijkt.

Bronnen

• RFC 4122 – UUID-specificatie
• MDN – Crypto.randomUUID()