Cos’è UUID v7 e perché è diverso da UUID v4
UUID v7 è una variante degli identificatori universali univoci (UUID) definita nella bozza RFC 9562. A differenza del più noto UUID v4, che appoggia interamente su 122 bit casuali (più 6 bit fissi per il campo di versione e variante), UUID v7 inserisce all’inizio della stringa un timestamp Unix in millisecondi a 48 bit. Il resto dei 74 bit è casuale (con i soliti 6 bit di controllo). Il risultato è un identificatore di 36 caratteri (senza trattini sono 32 caratteri esadecimali) che, a parità di lunghezza esterna, si comporta in modo completamente diverso quando viene generato in sequenza.
La differenza pratica è immediata: due UUID v7 creati in momenti diversi avranno i primi 12 caratteri esadecimali quasi sempre differenti e crescenti nel tempo. Con UUID v4, invece, due ID generati a distanza di un’ora possono iniziare con la stessa coppia di caratteri esadecimali o con una coppia minore, impedendo qualsiasi ordinamento implicito.
Questa pagina consente di generare da 1 a 100 UUID v7 alla volta, con opzioni per visualizzarli in maiuscolo e con o senza trattini. La scelta di tornare fino a 100 ID è un compromesso pratico: permette di popolare rapidamente un piccolo batch di test senza appesantire l’interfaccia o la generazione via browser.
Struttura interna: il timestamp da 48 bit e la casualità
Un UUID v7 è un numero di 128 bit. I primi 48 bit contengono il timestamp Unix in millisecondi, cioè il numero di millisecondi trascorsi dal 1° gennaio 1970 00:00:00 UTC. Subito dopo arrivano 4 bit fissi per il campo “versione” (0111, che indica appunto la versione 7), poi 12 bit di “variante e riservati”, poi altri 62 bit casuali. In termini esadecimali, quando si scrive l’UUID con i trattini (xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx), la prima parte a 8 caratteri rappresenta i 32 bit più significativi del timestamp; la seconda parte a 4 caratteri rappresenta i successivi 16 bit del timestamp; la terza parte a 4 caratteri include i 4 bit di versione (sempre 7) e i 12 bit più alti della casualità; la quarta parte a 4 caratteri include i 4 bit di variante (sempre 10xx in binario) e 12 bit casuali; la quinta parte a 12 caratteri copre i rimanenti 48 bit casuali.
Questa architettura fa sì che la stringa nel suo complesso sia ordinabile lessicograficamente per tempo di creazione, ma solo se si confrontano ID generati in millisecondi diversi. Due UUID v7 creati nello stesso millisecondo condividono esattamente gli stessi primi 48 bit (timestamp identico) e l’ordinamento tra loro è puramente casuale, perché la parte successiva è random. Il fatto che la pagina generi fino a 100 ID consecutivi con un solo clic significa che, se il browser esegue la generazione rapidamente entro lo stesso millisecondo, gli ID restituiti potrebbero non essere in ordine cronologico rigoroso tra di loro. Questo non è un bug, ma un comportamento atteso dalla specifica.
Ordinamento cronologico: perché importa per database e indici
La ragione principale per cui si adotta UUID v7 al posto di v4 è la località degli indici. Negli archivi relazionali e in molti database NoSQL, le chiavi primarie vengono spesso indicizzate tramite alberi B+ o varianti. Con UUID v4, ogni nuova chiave cade in una posizione casuale dell’indice, costringendo il database a numerosi split di pagina e a un’elevata frammentazione. Con UUID v7, la parte iniziale del timestamp fa sì che gli ID più recenti si accumulino in una porzione ristretta dell’indice, riducendo gli split e migliorando l’efficienza delle scritture in batch.
Il guadagno è particolarmente evidente quando si inseriscono molti record in rapida successione, come in un sistema di event sourcing o in un flusso di log. Se si generano 100 ID con questa pagina e li si inserisce in ordine crescente, l’indice del database vedrà chiavi con prefisso praticamente identico (se dello stesso millisecondo) o monotonicamente crescente (se di millisecondi diversi). L’effetto collaterale è che, a differenza di ULID (che usa un timestamp a 10 millisecondi e una parte casuale di 80 bit), UUID v7 non garantisce ordinamento stretto nemmeno per ID dello stesso millisecondo: i 74 bit casuali possono far sì che un ID generato dopo in senso temporale (ma entro lo stesso millisecondo) appaia lessicograficamente prima.
Generazione locale nel browser: zero trasmissioni al server
Tutta la generazione avviene interamente lato client, utilizzando l’API crypto.getRandomValues() del browser. Questo significa che nessun dato viene inviato a BroBroGo né a qualunque altro server. La stringa UUID v7 viene composta assemblando il timestamp corrente (ottenuto da Date.now()) e i byte casuali generati localmente. Il conteggio, le opzioni maiuscolo/trattini e lo stato “Ready.” o “Generated.” sono gestiti con JavaScript direttamente nel DOM. La pagina non memorizza mai i UUID generati: ogni modifica a un’opzione (conteggio, maiuscolo, trattini) rigenera immediatamente l’intera lista.
Questa architettura è fondamentale per chi opera con dati sensibili: non c’è latenza di rete, non c’è logging lato server, non c’è possibilità di intercettazione dell’identificatore durante la creazione. La casualità fornita da crypto.getRandomValues() è crittograficamente forte (derivata da una fonte di entropia di sistema come /dev/urandom su Linux o BCryptGenRandom su Windows), quindi i 74 bit casuali sono adatti per identificatori non predicibili anche in contesti di sicurezza.
Opzioni di formattazione: maiuscolo e trattini
La pagina offre due toggle semplici: Uppercase e Include hyphens. Il formato standard di UUID in molti protocolli (RFC 4122, RFC 9562) è in minuscolo e con trattini: 550e8400-e29b-41d4-a716-446655440000. Tuttavia, alcune applicazioni (es. alcuni database, sistemi di logging) preferiscono stringhe esadecimali minuscole senza trattini, oppure maiuscole per leggibilità su schermo. Il toggle hyphens controlla la presenza dei quattro trattini; senza di essi la stringa è lunga 32 caratteri esadecimali. Il toggle uppercase converte tutte le lettere a–f in maiuscolo.
Quando si cambia una qualsiasi opzione, la pagina rigenera immediatamente tutti gli UUID con le nuove impostazioni. Non c’è un pulsante “Genera” separato: la modifica è istantanea. Questo è comodo per confrontare rapidamente lo stesso set di ID in due formati, ma implica anche che se si regola il conteggio (ad esempio da 10 a 20) si perdono i precedenti e se ne ottengono 20 nuovi, non una estensione.
La copia individuale funziona cliccando sul singolo UUID; la copia di tutti gli ID avviene con un pulsante “Copia tutti”, che mostra il feedback “Copied all!”. Lo stato della pagina passa da “Ready.” (inattivo) a “Generated.” dopo la generazione. Non è prevista una funzione di cronologia o di rigenerazione con lo stesso seme: ogni operazione è indipendente.
Confronto con ULID e altre alternative ordinabili
UUID v7 non è l’unico formato di identificatore ordinabile per tempo. I più noti sono ULID (26 caratteri in base32, timestamp a 10 millisecondi, 80 bit casuali) e Snowflake (64 bit interi, timestamp personalizzato, ID di worker). Rispetto a ULID, UUID v7 è formalizzato come standard IETF ed è nativamente supportato da diverse librerie e database (PostgreSQL, recentemente, ha aggiunto funzioni per v7). ULID garantisce ordinamento stretto per ID dello stesso millisecondo (usa una parte casuale incrementale che preserva l’ordine lessicografico), ma è meno diffuso.
Snowflake, invece, usa un ID intero a 64 bit con timestamp, ID di datacenter e ID di sequenza, offrendo ordinamento stretto ma richiedendo configurazione distribuita e un’infrastruttura di coordinamento. UUID v7 non ha bisogno di configurazioni: ogni generatore lato client produce ID validi indipendentemente, pagando il prezzo della mancanza di ordinamento fine entro lo stesso millisecondo.
Per la maggior parte dei carichi di lavoro di un singolo server o di un’applicazione a bassa concorrenza, la differenza tra UUID v7 e ULID è trascurabile. La scelta dipende dall’ecosistema: se si lavora già con UUID in formato standard (es. campi uuid in PostgreSQL), v7 è il percorso più lineare. Se si usa già ULID in altre parti del sistema, mantenere la coerenza può essere preferibile.
Casi d’uso reali: event sourcing, audit trail, sistemi distribuiti
Gli UUID v7 sono particolarmente adatti per:
- Event sourcing: ogni evento ha un timestamp implicito e può essere ordinato cronologicamente anche senza un campo separato. La mancanza di ordinamento stretto entro lo stesso millisecondo è spesso irrilevante, perché gli eventi entro quello stesso millisecondo sono considerati concorrenti.
- Audit trail: la possibilità di leggere l’ora di creazione direttamente dall’ID (decodificando i primi 48 bit in millisecondi) evita di dover memorizzare un timestamp separato, riducendo la dimensione delle righe di log.
- Chiavi primarie in database distribuiti: ogni nodo può generare ID senza consultare un coordinatore centrale, e gli ID risultano comunque ordinabili per tempo di inserimento quando vengono aggregati in un unico indice. L’indice B+ ne beneficia perché le scritture recenti cadono in una zona calda.
- Sistemi di messaggistica: messaggi con UUID v7 possono essere riordinati dal consumatore in base all’ID, senza dipendere da un timestamp esterno che potrebbe essere soggetto a skew dell’orologio.
La generazione via pagina è un banco di prova rapido: si impostano le opzioni desiderate, si copiano gli ID e li si inserisce in un test di carico o in uno script di popolamento. Il fatto che la generazione sia locale permette anche di testare senza connettività di rete.
Domande frequenti
UUID v7 garantisce ordinamento stretto per ID generati nello stesso millisecondo? No. Il timestamp a 48 bit è identico per tutti gli ID dello stesso millisecondo. La parte casuale non ha alcuna relazione di incremento, quindi due UUID v7 generati nello stesso millisecondo possono apparire in qualsiasi ordine lessicografico.
Posso generare più di 100 UUID v7 con questa pagina? No. Il limite massimo è 100 ID per volta. Se servono più identificatori, bisogna eseguire più generazioni successive o usare una libreria programmatica.
I dati generati vengono inviati a qualche server? No. La generazione è interamente locale nel browser. Nessun UUID, timestamp o conteggio viene trasmesso a BroBroGo o a terze parti.
Cosa succede se cambio l’opzione “Maiuscolo” o “Trattini” dopo aver generato i UUID? Tutti gli ID vengono rigenerati da capo con le nuove impostazioni. I precedenti vengono persi. Non c’è una semplice riconversione di formato.
Perché usare UUID v7 invece di UUID v4 per le chiavi di database? UUID v7 migliora la località degli indici B+ perché le chiavi successive tendono a raggrupparsi in una regione ristretta dell’albero. UUID v4, essendo casuale, causa frammentazione e maggiori operazioni di scrittura sull’indice.
UUID v7 è sicuro per identificatori esposti pubblicamente? Sì, perché la parte casuale (74 bit) è generata con una fonte crittografica forte. La parte timestamp rivela l’ora di creazione al millisecondo, ma non l’identità del generatore. Se questo è un problema, si può troncare il timestamp o usare un formato diverso. La pagina non offre opzioni di troncamento.