Waarom v7 en ULID bestaan: index-lokaliteit

v4 is 122 willekeurige bits: onvoorspelbaar en ongeordend. v7 (RFC 9562, 2024) begint met een 48-bits timestamp in milliseconden en daarna 74 willekeurige bits, dus een reeks sorteert lexicaal hetzelfde als op aanmaaktijd. ULID (ulid/spec) verpakt datzelfde idee als 26 tekens Crockford base32 in plaats van 32 hexcijfers.

Een geclusterde of B-tree index op de primaire sleutel (InnoDB, Postgres standaard) zet elke rij op de indexpagina die het bereik van zijn sleutel dekt. Een id op tijdvolgorde landt aan de staart en rekt de laatste pagina ter plekke op. Een willekeurige v4 landt op een willekeurige pagina en dwingt een split zodra die pagina vol is, gooit weg wat daar in cache stond en laat de index groter en meer gefragmenteerd achter. Gebruik dus v7 of ULID voor een primaire of sorteersleutel. v4 is prima voor waarden die je alleen op exacte match opzoekt: sessietokens, losse resource-id's, idempotency keys.

Eén beperking: geen monotone teller, die sommige v7- en ULID-bibliotheken er wel bij doen. Twee ids die hier in dezelfde milliseconde gemaakt worden delen een timestamp en sorteren niet gegarandeerd op volgorde van aanmaak. Wil je een harde garantie onder de milliseconde, gebruik dan een bibliotheek die RFC 9562 §6.2 of de monotone variant van ULID implementeert.

Veelvoorkomende problemen

De ids sorteren niet in de database. v4 is met opzet willekeurig en heeft geen volgorde om op te sorteren. Wil je ids die op aanmaaktijd sorteren, dan zijn v7 en ULID daarvoor, en overstappen is de hele oplossing.
Een kolom weigert ze. Een UUID als tekst is 36 tekens met de streepjes en 32 zonder. Als native uuid of BINARY(16)-kolom is het 16 bytes. Een CHAR(32)-kolom kapt de vorm met streepjes stilletjes af.
Ze zien er voorspelbaar uit. v7 zet met opzet een milliseconde timestamp in de voorste bits, dus opeenvolgende ids delen een voorvoegsel. Dat is de bedoeling. Waar het erom gaat dat een id niet te raden is, gebruik v4, en gebruik geen van beide ooit als beveiligingstoken.
Twee ids uit dezelfde milliseconde kwamen er in de verkeerde volgorde uit. v7 ordent tot op de milliseconde en maakt alles daaronder willekeurig, dus gelijkspel binnen één milliseconde heeft geen vastgelegde volgorde. ULID heeft dezelfde eigenschap.

Veelgestelde vragen

Is UUID v7 een standaard of een gewoonte?

Een standaard. RFC 9562 vervangt RFC 4122 en voegt v7 toe. Postgres 18 heeft een ingebouwde uuidv7(), en de meeste gangbare talen hebben er bibliotheken voor.

Hoe groot is de kans dat twee ids botsen?

Verwaarloosbaar. Met de 122 willekeurige bits van v4 ligt de verjaardagsgrens rond 2,6 triljoen ids voor er 50% kans is op één dubbel paar. v7 en ULID houden 74 en 80 willekeurige bits over, elke milliseconde ververst.

Waarom slaat ULID de letters I, L, O en U over?

Crockford base32 laat ze weg zodat een verkeerd gelezen teken niet op een ander geldig teken uitkomt als iemand een id met de hand overtypt. Hoofdletters tellen niet mee, niet in ULID en niet in UUID (RFC 9562 §4).

Blijven mijn instellingen in de link staan?

Versie, aantal en de twee schakelaars blijven in de URL. De gegenereerde ids niet: elk bezoek maakt een verse reeks.