Generator UUID v7

Generați valori UUID v7 online: UUID-uri sortabile cronologic, cu un timestamp pe 48 de biți în milisecunde și 74 de biți aleatori.

Format
ID-uri generate
Pregătit. Generați valori UUID v7 direct în browser.

Cum este construit acest ID

Structură
Timestamp Unix pe 48 de biți în milisecunde, biți de versiune 7, biți de variantă RFC și umplere aleatorie.
Entropie
74 de biți aleatori în această implementare; nu există un contor monoton.
Timp
Da. Primii 48 de biți codifică timpul creării, astfel încât ID-urile se sortează cronologic chiar și între milisecunde diferite.
Risc de coliziune
În cadrul aceleiași milisecunde, coliziunile depind de cei 74 de biți aleatori; volumele extrem de mari în aceeași milisecundă ar trebui să folosească un serviciu coordonat de ID-uri.
Exemplu
01a044bc-5ddc-7f82-ad14-b421b6c13496

ID-urile dumneavoastră sunt generate local folosind funcții criptografice din browser. Nimic nu este trimis către BroBroGo.

Întrebări frecvente

De ce să aleg UUID v7 în locul UUID v4?

UUID v7 păstrează structura UUID, dar se sortează cronologic, ceea ce ajută jurnalele, indexurile de baze de date și fluxurile de evenimente să rămână în ordine aproximativ cronologică.

Ascunde UUID v7 timpul creării?

Nu. Timestamp-ul face parte din ID. Utilizați UUID v4 sau NanoID dacă aveți nevoie de un identificator opac, fără date temporale.

Generator UUID v7: Identificatori sortabili cronologic, generați local în browser

Ce este UUID v7 și de ce diferă de UUID v4

UUID v7 este un format de identificator universal unic de 36 de caractere, care înglobează la început un marcaj temporal de 48 de biți reprezentând timestampul Unix în milisecunde, urmat de biți aleatori. Spre deosebire de UUID v4, care este complet aleator, UUID v7 face ca identificatorii să fie sortabili cronologic după momentul creării. Aceasta rezolvă problema majoră de indexare a bazelor de date: UUID v4, prin distribuția sa uniform aleatoare, fragmenta indecșii B-tree și degrada performanța la inserții. UUID v7 menține proprietăți criptografice puternice de neguessabilitate, deoarece partea aleatoare rămâne suficient de mare (80 de biți) pentru a preveni enumerarea.

Un aspect important: UUID v7 nu garantează ordonarea strictă pentru ID-urile generate în aceeași milisecundă. Dacă două UUID-uri v7 sunt create în același milisecund (timestamp identic), ordinea lor relativă este aleatoare și nu poate fi dedusă din șir. Acest compromis este intenționat: permite generarea paralelă pe mai multe noduri fără sincronizare, spre deosebire de monotoanele crescătoare bazate pe contoare secvențiale.

Structura internă a UUID v7: timestamp + aleator

Standardul UUID v7 (propus în RFC 9562, în lucru la IETF) definește o reprezentare pe 128 de biți, exprimată ca 36 de caractere hexazecimale grupate în forma xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Primii 48 de biți (primele 12 caractere hex, grupate în 8-4-4) reprezintă timestampul Unix exprimat în milisecunde de la 1 ianuarie 1970. Următorii 4 biți sunt câmpul de versiune (valoarea 7, de unde și numele), urmați de 12 biți pentru varianta UUID (0100 în binar), iar restul de 56 de biți sunt aleatori.

Exemplu: 018f73a0-9b7c-7f00-8000-1c27f3a9b4c2 – primele 12 caractere (018f73a09b7c) codifică timestampul, iar al 13-lea caracter (7) indică versiunea 7. În format cu majuscule: 018F73A0-9B7C-7F00-8000-1C27F3A9B4C2.

Capacitatea maximă: 48 de biți de timestamp acoperă aproximativ 8,9 miliarde de milisecunde, adică ~284 de ani de la epoca Unix. Acest interval este suficient pentru aplicații curente și viitoare.

Comparație UUID v7 vs UUID v4: indexare, coliziuni, neguessabilitate

Caracteristică UUID v4 UUID v7
Bază 122 biți aleatori + 6 biți de variantă 48 biți timestamp + 74 biți aleatori + 6 biți de variantă
Sortabilitate Nu Da, cronologică (cu excepția milisecundelor identice)
Indexare B-tree Fragmentare puternică Localitate temporală bună
Coliziuni 2^61 până la 2^71 (extrem de rare) Similar, practic zero în uz normal
Neguessabilitate 122 biți aleatori 74 biți aleatori (suficienți pentru unicitate și imprevizibilitate)
Lungime text 36 caractere (32 hex + 4 cratime) 36 caractere (32 hex + 4 cratime)
Format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx tttttttt-tttt-7xxx-yxxx-xxxxxxxxxxxx

Marea diferență practică: UUID v4 produce identificatori distribuiți uniform, ceea ce forțează bazele de date să reechilibreze constant paginile de index. UUID v7, prin timestampul crescător, inserează rânduri noi aproape de „coada” arborelui B-tree, reducând fragmentarea și îmbunătățind rata de umplere a paginilor.

Generare locală în browser: confidențialitate și performanță

Generatorul rulează exclusiv în browserul utilizatorului, folosind API-ul crypto.getRandomValues() pentru biții aleatori. Timestampul este preluat din Date.now(). Nu se trimite nicio cerere către server (BroBroGo sau altul). Acest lucru are consecințe importante:

  • Confidențialitate: datele nu părăsesc mașina utilizatorului.
  • Viteză: generarea a 100 de UUID-uri durează sub o milisecundă (depinde de implementare).
  • Disponibilitate: funcționează offline, fiinddependență exclusiv de mediul browser.

Modul de generare: pentru fiecare UUID, se construiește un buffer de 16 octeți (128 biți). Primii 6 octeți (48 biți) sunt scriși cu timestampul curent (în big-endian). Al șaptelea octet primește versiunea 7 prin setarea biților 7-4 la 0111 (0x70), iar al 9-lea octet primește varianta UUID (biții 8-7 setați 10, adică 0x80). Restul biților sunt umpluți cu octeți aleatori. Rezultatul este apoi transformat în șir hexazecimal, cu sau fără cratime și majuscule, conform preferințelor.

Formatarea output-ului: majuscule, cratime și efectul asupra stocării

Generatorul oferă două opțiuni de afișare: majuscule (toggle) și includerea cratimelor (toggle). Fiecare combinație produce un șir diferit:

  • 018f73a0-9b7c-7f00-8000-1c27f3a9b4c2 (minuscule, cu cratime)
  • 018F73A0-9B7C-7F00-8000-1C27F3A9B4C2 (majuscule, cu cratime)
  • 018f73a09b7c7f0080001c27f3a9b4c2 (minuscule, fără cratime)
  • 018F73A09B7C7F0080001C27F3A9B4C2 (majuscule, fără cratime)

Cratimele sunt opționale conform standardului UUID (sunt recomandate pentru lizibilitate, dar nu obligatorii). Fără cratime, șirul are 32 de caractere hex, ceea ce poate fi mai eficient pentru stocare ca text (economie de 4 octeți) sau pentru parsare ca hex direct în binar. Majusculele nu afectează valoarea numerică, dar unele sisteme (de ex. Java, PostgreSQL) preferă litere mari prin convenție. Important: toate variantele reprezintă același UUID la nivel binar; doar reprezentarea textuală diferă.

Schimbarea oricărei opțiuni (număr, majuscule, cratime) declanșează imediat regenerarea tuturor ID-urilor.

Cine are nevoie de UUID v7 și cazuri reale de utilizare

Dezvoltatori de sisteme distribuite care trebuie să creeze chei primare sortabile cronologic pe mai multe noduri fără coordonare centrală. Spre exemplu, un serviciu de microservicii care înregistrează comenzi (event sourcing) poate genera UUID-uri v7 independent pe fiecare instanță, iar apoi le poate sorta global după timestamp pentru a reconstrui ordinea evenimentelor.

Administratori de baze de date care migrează de la UUID v4 la un format temporal pentru a evita fragmentarea indecșilor. Benchmark-urile arată că inserțiile cu UUID v7 pot fi de 2-3 ori mai rapide în PostgreSQL sau MySQL comparativ cu UUID v4, deoarece paginile de index sunt umplute secvențial.

Ingineri axați pe securitate care au nevoie de identificatori neguessabili pentru tokenuri de acces, ID-uri de sesiune sau chei de API, dar care doresc și afișarea timestampului la o inspecție rapidă. UUID v7 oferă exact acest echilibru: partea aleatoare (74 biți) este suficient de mare pentru a preveni atacurile de enumerare.

Cazuri specifice:

  • Audit trails: Se înregistrează evenimente cu UUID-uri v7; sortarea lexicografică dă automat ordinea temporală.
  • Sisteme de mesagerie: Mesajele pot fi ordonate după UUID, facilitând recunoașterea secvenței.
  • Migrarea de la ULID sau NanoID: UUID v7 este standardizat IETF și nativ suportat în multe biblioteci (Python uuid7, Node.js uuid, Rust uuid7), spre deosebire de formate proprietare.

Limitare importantă: nu garantează ordonarea strictă în aceeași milisecundă. Pentru cazuri unde ordinea intra-milisecundă este critică (de ex. loguri de tranzacții cu frecvență sub milisecundă), sunt necesare mecanisme suplimentare (contor monoton, ceas logic).

Întrebări frecvente

1. Pot genera mai mult de 100 de UUID-uri o dată?

Nu. Generatorul acceptă un număr între 1 și 100 inclusiv. Limita este impusă de design pentru a preveni blocarea browserului la numere foarte mari. Dacă aveți nevoie de mai multe, rulați de mai multe ori.

2. UUID-urile sunt cu adevărat unice global?

Da, probabilitatea de coliziune este extrem de mică. Cu 74 de biți aleatori, riscul de coliziune este de ordinul 2^(-74) per pereche. În practică, chiar și generând miliarde de UUID-uri zilnic, coliziunile sunt imposibile statistic.

3. Cum verific că timestampul este corect?

Puteți decoda primii 48 de biți (primele 12 caractere hex) din formatul fără cratime. De exemplu, 018F73A09B7C reprezintă un timestamp Unix în milisecunde. Convertiți în număr zecimal (de obicei se face cu parseInt('018F73A09B7C', 16)) și apoi împărțiți la 1000 pentru secunde. Există convertoare online, dar generatorul nu oferă această funcție.

4. Care este diferența dintre UUID v7 și ULID?

Ambele includ un timestamp și sunt sortabile cronologic. ULID are 26 de caractere (base32 Crockford), în timp ce UUID v7 are 36 de caractere (hex). UUID v7 este standardizat IETF, în timp ce ULID este un standard informal. Ambele nu garantează ordonarea în aceeași milisecundă.

5. Pot stoca UUID v7 ca număr întreg (BIGINT)?

Nu direct, pentru că UUID v7 are 128 de biți, iar BIGINT standard are 64 de biți. Puteți stoca ca două BIGINT-uri (high + low), ca șir de 36 de caractere (VARCHAR(36)), sau ca BINARY(16) – cea mai eficientă. Generatorul produce un șir text, dar puteți converti la binar în aplicație.

6. De ce generatorul afișează „Ready.” și „Generated.”?

Acestea sunt stări ale interfeței: „Ready.” arată că pagina este încărcată și așteaptă comenzi, iar „Generated.” apare după ce UUID-urile au fost create. Când copiați toate ID-urile, apare „Copied all!”.