UUID v4 vs v7: ce identificator unic să alegi?

Un UUID este un identificator de 128 de biți unic fără coordonare centrală. Versiunea 4, complet aleatorie, domină de ani de zile. Versiunea 7, mai recentă (RFC 9562, 2024), integrează o marcă temporală la început pentru a produce identificatori ordonați în timp. Această diferență, aparent banală, schimbă radical performanțele în baza de date. Iată pe care s-o alegi.

Ce este un UUID?

Un UUID (Universally Unique Identifier) este un număr de 128 de biți reprezentat prin 32 de caractere hexazecimale grupate în cinci blocuri, de exemplu 550e8400-e29b-41d4-a716-446655440000. Rațiunea sa de a fi: a genera un identificator unic fără a cere unei autorități centrale, ceea ce îl face ideal pentru sistemele distribuite. Poți genera unii cu generatorul de UUID.

Există mai multe versiuni; cele mai pertinente astăzi pentru chei de înregistrare sunt v4 (aleatorie) și v7 (ordonată în timp).

UUID v4 (aleatoriu)

UUID v4 este constituit din 122 de biți aleatorii (restul codifică versiunea și variantul). Probabilitatea de coliziune este atât de redusă încât este neglijabilă în practică. Este versiunea implicită în majoritatea limbajelor și bibliotecilor.

• Imprevizibil: perfect pentru token-uri sau identificatori publici care nu se vor a fi ghicibili
• Nicio scurgere de informație: nu dezvăluie nici data nici ordinea de creare
• Dezavantaj: complet dezordonat, ceea ce maltratează indexurile de bază de date

UUID v7 (ordonat în timp)

UUID v7 plasează o marcă temporală Unix în milisecunde pe primii săi 48 de biți, urmată de biți aleatorii. Doi UUID v7 generați în momente diferite se sortează deci în ordinea creării lor, rămânând unici și practic imposibil de ghicit.

• Sortabil: ordinea lexicografică corespunde ordinii cronologice
• Prietenos cu indexurile: inserările se fac la sfârșitul indexului, ca un auto-increment
• Contrapartidă: dezvăluie momentul creării, ceea ce poate fi nedorit pentru un identificator public

Tabel comparativ

Impact asupra bazelor de date

Acesta este miezul subiectului. Bazele relaționale stochează indexurile lor în arbori B (B-tree). Inserarea de chei aleatorii (v4) dispersează scrierile peste tot în index, provocând fragmentare, divizări de pagini și un cache mai puțin eficient. Pe volume mari, performanțele de inserare se degradează net.

Cheile ordonate (v7) se inserează mereu la sfârșitul indexului, ca un identificator auto-incrementat. Se regăsesc inserări rapide, o localitate mai bună și un index mai compact. Este deosebit de net cu o cheie primară în InnoDB (MySQL), unde cheia primară determină ordinea fizică a rândurilor.

Când să alegi unul sau altul

Alege UUID v4 când

• Identificatorul este expus public și nu trebuie să dezvăluie nimic
• Generezi token-uri, linkuri de partajare, secrete
• Ordinea și data de creare nu trebuie să fie ghicibile
• Vrei o compatibilitate maximă cu existentul

Alege UUID v7 când

• UUID-ul servește drept cheie primară într-o bază de date
• Volumul de inserări este ridicat și performanța de index contează
• Vrei să sortezi după ordinea de creare fără coloană dedicată
• Dezvăluirea momentului de creare nu este o problemă

Recomandare

Pentru o cheie primară de bază de date, preferă de acum UUID v7: păstrezi unicitatea distribuită a UUID-ului evitând penalizarea de index a v4. Conservă UUID v4 pentru identificatorii publici, token-uri și secrete, unde imprevizibilitatea totală și absența scurgerii temporale primează.

Verifică totuși suportul v7 în limbajul tău și în ORM-ul tău: RFC-ul este recent, dar adoptarea progresează repede.

Întrebări frecvente