UUID v4 vs v7: welke unieke identificator kiezen?

Een UUID is een uniek 128-bit identificator zonder centrale coördinatie. Versie 4, volledig willekeurig, domineert al jaren. Versie 7, recenter (RFC 9562, 2024), integreert een tijdstempel aan het begin om tijdgeordende identificatoren te produceren. Dit verschil, ogenschijnlijk onschuldig, verandert de prestaties in de database radicaal. Zo kies je welke.

Wat is een UUID?

Een UUID (Universally Unique Identifier) is een getal van 128 bits, weergegeven door 32 hexadecimale tekens gegroepeerd in vijf blokken, bijvoorbeeld 550e8400-e29b-41d4-a716-446655440000. Zijn bestaansreden: een unieke identificator genereren zonder een centrale autoriteit te raadplegen, wat hem ideaal maakt voor gedistribueerde systemen. Je kunt er genereren met onze UUID-generator.

Er bestaan meerdere versies; de meest relevante vandaag voor recordsleutels zijn v4 (willekeurig) en v7 (tijdgeordend).

UUID v4 (willekeurig)

De UUID v4 bestaat uit 122 willekeurige bits (de rest codeert de versie en de variant). De kans op een botsing is zo laag dat ze in de praktijk verwaarloosbaar is. Het is de standaardversie in de meeste talen en bibliotheken.

• Onvoorspelbaar: perfect voor tokens of publieke identificatoren die niet raadbaar mogen zijn
• Geen informatielek: onthult noch datum noch aanmaakvolgorde
• Nadeel: volledig ongeordend, wat de database-indexen schaadt

UUID v7 (tijdgeordend)

De UUID v7 plaatst een Unix-tijdstempel in milliseconden op zijn eerste 48 bits, gevolgd door willekeurige bits. Twee UUID v7 die op verschillende momenten worden gegenereerd, sorteren zich dus in de volgorde van hun aanmaak, terwijl ze uniek en praktisch onmogelijk te raden blijven.

• Sorteerbaar: de lexicografische volgorde komt overeen met de chronologische volgorde
• Indexvriendelijk: de invoegingen gebeuren aan het einde van de index, zoals een auto-increment
• Keerzijde: het onthult het aanmaakmoment, wat ongewenst kan zijn voor een publieke identificator

Vergelijkingstabel

Impact op databases

Dit is de kern van de zaak. Relationele databases slaan hun indexen op in B-bomen (B-tree). Het invoegen van willekeurige sleutels (v4) verspreidt de schrijfbewerkingen overal in de index, wat fragmentatie, paginasplitsingen en een minder efficiënte cache veroorzaakt. Bij grote volumes verslechteren de invoegprestaties duidelijk.

De geordende sleutels (v7) worden altijd aan het einde van de index ingevoegd, zoals een auto-increment-identificator. Je krijgt snelle invoegingen, een betere lokaliteit en een compactere index. Dit is bijzonder duidelijk met een primaire sleutel in InnoDB (MySQL), waar de primaire sleutel de fysieke volgorde van de rijen bepaalt.

Wanneer de een of de ander kiezen

Kies UUID v4 wanneer

• De identificator publiek wordt blootgesteld en niets mag onthullen
• Je tokens, deellinks of geheimen genereert
• De volgorde en aanmaakdatum niet raadbaar mogen zijn
• Je maximale compatibiliteit met het bestaande wilt

Kies UUID v7 wanneer

• De UUID dient als primaire sleutel in een database
• Het invoegvolume hoog is en de indexprestaties tellen
• Je wilt sorteren op aanmaakvolgorde zonder speciale kolom
• Het onthullen van het aanmaakmoment geen probleem is

Aanbeveling

Voor een primaire databasesleutel verdient UUID v7 voortaan de voorkeur: je behoudt de gedistribueerde uniciteit van de UUID terwijl je de indexstraf van v4 vermijdt. Behoud UUID v4 voor publieke identificatoren, tokens en geheimen, waar de volledige onvoorspelbaarheid en de afwezigheid van een tijdlek vooropstaan.

Controleer toch de ondersteuning van v7 in je taal en je ORM: de RFC is recent, maar de adoptie vordert snel.

Veelgestelde vragen