Generator UUID v7

Struktura UUID v7: zakaj je časovni žig na prvem mestu

UUID v7 je 128‑bitni identifikator, zapisan kot 36‑znakovni niz v obliki xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx. Prvih 48 bitov (12 šestnajstiških znakov) je Unixov milisekundni časovni žig, ki se začne od epohe (1. januar 1970). Sledi 74 bitov naključnih podatkov, pri čemer so 4 biti rezervirani za različico (»7«) in 2 bita za variantno polje (»10«). To pomeni, da je celotna entropija za naključni del 2⁷⁴ ~ 1,8 × 10²² možnosti – zadostna za izogibanje kolizijam v večini praktičnih scenarijev.

Pomembna posledica te strukture: prvi znaki UUID v7 niso naključni, temveč naraščajo s časom. Ko jih razvrstimo leksikografsko, so avtomatsko urejeni po vrstnem redu nastanka. To je ključna prednost pred UUID v4, kjer so prvi znaki popolnoma naključni, kar povzroča raztresenost v indeksih B‑dreves.

Orodje na tej strani generira UUID v7 lokalno v brskalniku z uporabo močnega kriptografskega generatorja naključij (crypto.getRandomValues). Vsaka sprememba vnosa (število ID‑jev, velike črke, vezaji) sproži takojšnjo regeneracijo celotnega seznama. Nič se ne pošilja na strežnik – zasebnost je v celoti ohranjena.

Vhodni parametri in izhodni format

Orodje sprejema tri nastavitve:

Izhod je seznam identifikatorjev, prikazan pod vnosnimi polji. Tik nad seznamom se izpiše status:

• Ready. – ko stran še ni generirala (začetno stanje).
• Generated. – po uspešni generaciji.
• Copied all! – ko uporabnik klikne gumb za kopiranje vseh ID‑jev v odložišče.

Posamezni ID se kopira s klikom nanj. Orodje ne ponuja možnosti izvoza v datoteko – kopiranje v odložišče je edini način prenosa.

Zakaj je časovna urejenost pomembna za indekse v podatkovnih bazah

Pri UUID v4 so ID‑ji zapisani kot naključni nizi. Ko jih vstavljamo v indeks B‑drevesa (npr. primarni ključ v PostgreSQL, MySQL ali SQL Server), se novi vnosi pojavljajo na naključnih straneh indeksa. To povzroča:

• Fragmentacijo strani – veliko strani je le delno zapolnjenih.
• Pogosto preurejanje (rebalancing) – naključno vstavljanje sili drevo k pogostim delitvam strani.
• Slabšo zmogljivost pisanja – vsaka vstavitev zahteva več naključnih I/O operacij.

Pri UUID v7 so ID‑ji monotono naraščajoči (v grobem – o natančnosti v isti milisekundi kasneje). Nov ID se v indeks vstavi na konec trenutne strani ali na bližnjo naslednjo. To ohranja lokalnost, zmanjša fragmentacijo in pospeši vstavljanje za faktor 2–3 v primerjavi z UUID v4 pri velikih tabelah.

Vendar pa UUID v7 ne zagotavlja strogge urejenosti znotraj iste milisekunde. Če se v isti milisekundi generira več ID‑jev, je njihov medsebojni vrstni red odvisen izključno od naključnega dela. To je načrtovana lastnost – omogoča paralelno generiranje na več vozliščih brez sinhronizacije ure. ULID (ki uporablja 48‑bitni časovni žig + 80‑bitno naključje) ima enako omejitev.

Primerjava UUID v7 z UUID v4 in ULID

UUID v7 je edini izmed teh treh, ki je del uradnega IETF standarda (RFC 9562) in ohranja 36‑znakovno obliko, združljivo z obstoječimi shemami, ki pričakujejo UUID.

Lokalno generiranje in varnost

Ker orodje vso obdelavo opravi v brskalniku, ni nikakršnega omrežnega prometa, razen samega nalaganja strani. To je pomembno za:

• Zasebnost – identifikatorji ostanejo na uporabnikovi napravi.
• Hitrost – generiranje 100 ID‑jev traja običajno manj kot 10 ms.
• Zanesljivost – ni odvisnosti od zunanjega API‑ja ali strežnika.

Uporabljeni generator crypto.getRandomValues je definiran v specifikaciji Web Crypto API in zagotavlja kriptografsko močna naključja, primerna za generiranje identifikatorjev, ki morajo biti neuganljivi. To je ključno za primere, kjer bi napadalec z ugibanjem ID‑jev lahko pridobil dostop do virov (npr. v URL‑jih z ID‑ji objektov).

Napake, ki se jim je treba izogniti

• Predpostavljanje stroge urejenosti znotraj iste milisekunde – če potrebujete absolutni vrstni red v istem trenutku, uporabite dodatne mehanizme (npr. monotono število znotraj vozlišča).
• Uporaba vezajev le za prikaz – pri shranjevanju v bazo se vezaji pogosto odstranijo; orodje omogoča izklop vezajev za neposredno kopiranje v bazo.
• Zamenjava velikih/malih črk – standardni UUID uporablja male črke, vendar orodje ponuja možnost velikih črk za združljivost z obstoječimi sistemi.
• Generiranje preveč ID‑jev naenkrat – omejitev 100 je postavljena zaradi berljivosti; za večje količine uporabite programsko rešitev.

Pogosta vprašanja

Ali UUID v7 zagotavlja, da so ID‑ji urejeni po vrstnem redu nastanka, tudi če so generirani na različnih napravah? Da, ker časovni žig temelji na Unixovem času v milisekundah. Vendar se lahko ura na različnih napravah razlikuje (drift). Za globalno urejanje uporabite sinhronizacijo NTP.

Kaj se zgodi, če generiram 100 ID‑jev v isti milisekundi? Vsak ID bo imel enak časovni žig, vrstni red pa bo naključen (odvisen od naključnega dela). Za urejanje znotraj iste milisekunde ni garancij.

Ali je UUID v7 primeren za primarni ključ v MySQL? Da, veliko boljši od UUID v4, saj zmanjšuje fragmentacijo indeksa. Še vedno pa je 128‑bitni tip večji od 64‑bitnega celega števila – presodite glede na količino podatkov.

Zakaj orodje ne omogoča izvoza v datoteko? Orodje je zasnovano za hitro generiranje manjšega števila ID‑jev; kopiranje v odložišče je dovolj za večino primerov. Za večje količine priporočamo uporabo programskih knjižnic.

Ali lahko zaupam, da so ID‑ji resnično naključni? Da, uporabljen je kriptografski generator brskalnika – isti mehanizem, ki ga uporabljajo varni ključi in žetoni. Ne skrbite – ni shranjenega stanja.

Kaj pomeni »v7« v imenu? Različica 7 po RFC 9562 (v pripravi). Različica 4 je naključna, različica 1 temelji na MAC‑naslovu in času, vendar je manj zasebna. UUID v7 združuje prednosti časovne urejenosti in naključnosti.