Generatore UUID

Standard UUID e Identità Distribuita

L'Universally Unique Identifier fu standardizzato per la prima volta nel RFC 4122 (2005), sebbene le sue radici risalgano all'Apollo Network Computing System negli anni '80 e al Distributed Computing Environment (DCE) della Open Software Foundation. Il problema fondamentale che risolvono gli UUID e la generazione di identificatori globalmente univoci senza un'autorità di coordinamento centrale — essenziale per i sistemi distribuiti dove più macchine devono creare indipendentemente ID che non entreranno mai in collisione. RFC 4122 defini cinque versioni UUID per diversi casi d'uso. La versione 1 incorpora un timestamp a 60 bit (intervalli di 100 nanosecondi dal 15 ottobre 1582 — la riforma del calendario gregoriano) combinato con un identificativo di nodo a 48 bit originariamente derivato dall'indirizzo MAC. Sebbene garantisse l'univocita, v1 esponeva l'identità hardware è il momento di creazione. Le versioni 3 e 5 sono basate sui nomi: eseguono l'hash di un identificativo di namespace combinato con un nome usando MD5 (v3) o SHA-1 (v5), producendo UUID deterministici. La versione 4 sostitui il determinismo con 122 bit di casualita crittografica, diventando la versione più adottata. Lo standard più recente, RFC 9562 (2024), ha introdotto UUID v7 come scelta raccomandata per identificatori compatibili con i database. La versione 7 incorpora un timestamp Unix a 48 bit in millisecondi nei bit più significativi, seguiti da bit casuali di riempimento. Questo design crea identificatori che si ordinano cronologicamente — un vantaggio critico per gli indici B-tree dei database dove gli UUID v4 casuali causano frammentazione eccessiva. I benchmark mostrano che gli UUID v7 migliorano la produttivita di inserimento del 20-40% rispetto a v4. La probabilita di collisione di UUID v4 e governata dal paradosso del compleanno. Con 122 bit casuali, lo spazio contiene 5,3 x 10^36 valori possibili. La probabilita di generare un duplicato raggiunge il 50% solo dopo aver prodotto circa 2,71 x 10^18 UUID. I formati concorrenti includono gli Snowflake ID di Twitter (64 bit), gli ULID (128 bit con codifica Crockford Base32), i NanoID (stringhe compatte sicure per URL) e le sequenze auto-incrementali dei database. Ciascuno comporta compromessi tra garanzie di unicita, ordinabilita, dimensione di archiviazione e requisiti di coordinamento.

Metodologia

La generazione di UUID v4 si basa sul metodo crypto.randomUUID() del browser dalla Web Crypto API, che produce 128 bit di cui 122 sono crittograficamente casuali e 6 sono riservati per i marcatori di versione (4 bit impostati a 0100) e variante (2 bit impostati a 10). Questo garantisce che ogni UUID sia autodescrittivo — può identificare la sua versione ispezionando il 13° carattere esadecimale. UUID v7 incorpora un timestamp Unix a 48 bit in millisecondi nei bit più significativi, seguiti da bit casuali di riempimento. Questo design produce identificatori che sono sia unici che naturalmente ordinati nel tempo, rendendoli ideali per le chiavi primarie dei database dove le prestazioni dell'indice B-tree contano. UUID v1 usa un timestamp a 60 bit con risoluzione di 100 nanosecondi dal 15 ottobre 1582 (la data della riforma del calendario gregoriano), una sequenza di clock a 14 bit per prevenire duplicati durante gli aggiustamenti dell'orologio, è un identificativo di nodo a 48 bit generato casualmente per la protezione della privacy. Gli ULID codificano un timestamp a 48 bit in millisecondi seguito da 80 bit casuali, rappresentati in Crockford Base32 per una rappresentazione compatta e insensibile alle maiuscole. I NanoID utilizzano un alfabeto è una lunghezza configurabili, per impostazione predefinita 21 caratteri da un set sicuro per URL, fornendo 126 bit di entropia.

Capire i tuoi risultati

Ogni UUID è un valore a 128 bit visualizzato come 32 caratteri esadecimali in 5 gruppi separati da trattini, seguendo il pattern 8-4-4-4-12. Il formato canonico è xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, dove la posizione M (13° carattere hex) indica la versione e la posizione N (17° carattere hex) indica la variante. Per UUID v4, M è sempre '4' e N è uno tra '8', '9', 'a' o 'b', confermando la conformità RFC 4122. Per UUID v7, M è '7' e i primi 12 caratteri hex codificano il timestamp in millisecondi, rendendo il tempo di creazione direttamente leggibile. UUID v1 pone M come '1' con il timestamp suddiviso nei primi tre gruppi in un ordine riorganizzato. Gli ULID sono visualizzati come 26 caratteri Crockford Base32 maiuscoli — i primi 10 codificano il timestamp e i restanti 16 codificano la casualità. I NanoID appaiono come stringhe compatte che utilizzano caratteri sicuri per URL (A-Z, a-z, 0-9, trattino, underscore), senza marcatori strutturali intrinseci. Nella scelta di un formato, considera che gli UUID con parentesi graffe sono comuni negli ecosistemi Microsoft, mentre gli UUID senza trattini risparmiano spazio di archiviazione nei database.

Esempi pratici

Chiavi primarie del database: Usa UUID v7 per tabelle PostgreSQL o MySQL dove l'ordine di inserimento conta. Il timestamp incorporato garantisce valori chiave sequenziali, evitando la dispersione I/O casuale che UUID v4 causa sugli indici cluster. Tracciamento eventi microservizi: Genera UUID v4 per gli ID di correlazione passati attraverso code di messaggi (Kafka, RabbitMQ). La pura casualità garantisce zero collisioni anche quando migliaia di servizi producono ID simultaneamente. Token di sessione frontend: Usa NanoID per identificatori di sessione compatti e sicuri per URL nelle applicazioni a pagina singola. Con 21 caratteri, sono più corti degli UUID mantenendo una resistenza alle collisioni equivalente. Denominazione file e deduplicazione: Genera ULID per gli identificatori dei file caricati. La loro ordinabilità lessicografica significa che un semplice elenco alfabetico mostra i file in ordine cronologico di caricamento.

Consigli e Buone Pratiche

Scelga la versione UUID in base al Suo caso d'uso invece di usare v4 per impostazione predefinita. Se i Suoi identificatori serviranno come chiavi primarie del database, UUID v7 o ULID forniscono prestazioni di inserimento significativamente migliori perché la loro natura ordinata nel tempo mantiene gli indici B-tree sequenziali, riducendo le suddivisioni di pagina e la frammentazione. Per i sistemi distribuiti dove più nodi generano ID indipendentemente, la pura casualità di UUID v4 elimina qualsiasi rischio di collisioni basate su timestamp. Quando lavora con URL o identificatori visibili all'utente, il formato compatto di 21 caratteri di NanoID è più pratico di un UUID di 36 caratteri. Archivia sempre gli UUID come il loro tipo binario nativo a 128 bit nei database quando disponibile (ad es. il tipo uuid di PostgreSQL o BINARY(16) di MySQL) invece che come stringhe VARCHAR(36). Questo dimezza lo spazio di archiviazione e migliora le prestazioni di confronto. Durante il debug, ricordi che la cifra della versione (posizione 13) Le dice istantaneamente quale variante UUID sta esaminando.

Fonti

• RFC 4122 – Specifica UUID
• MDN – Crypto.randomUUID()