Vai al contenuto principale
riqo.ioStrumenti per grandi idee

UUID: identificatori univoci, versioni e utilizzi

Struttura degli UUID, variant e versioni, probabilità di collisione e criteri per scegliere un identificatore distribuito.

Che cos'è un UUID

Un UUID è un identificatore di 128 bit pensato per poter essere generato senza un coordinatore centrale. La forma testuale canonica usa 32 cifre esadecimali raggruppate con trattini, ma il valore fondamentale resta la sequenza di 128 bit.

L'unicità non è una proprietà matematica assoluta di ogni UUID: dipende dall'algoritmo di generazione e dal dominio. Lo scopo pratico è rendere le collisioni sufficientemente improbabili o evitarle tramite una struttura definita dalla versione.

Variant e campo version

Alcuni bit identificano il variant e la versione, cioè la famiglia di layout e il metodo con cui sono stati prodotti gli altri bit. La stringa può quindi essere sintatticamente valida ma non appartenere alla versione che un'applicazione si aspetta.

La validazione dovrebbe distinguere formato, variant, versione e policy applicativa. Un parser che accetta qualsiasi UUID non dimostra che quel valore sia appropriato per un dato protocollo.

UUID v4 e casualità

UUID v4 dedica la maggior parte dei bit alla casualità e fissa i bit necessari a version e variant. Con un generatore casuale crittograficamente robusto offre uno spazio enorme e collisioni estremamente improbabili per volumi ordinari.

La probabilità cresce con il numero di identificatori secondo il birthday bound, ma resta trascurabile in moltissimi sistemi. Il rischio operativo più concreto è spesso un RNG difettoso o una generazione non conforme, non l'esaurimento teorico dello spazio.

Versioni temporali e UUID v7

Altre versioni incorporano tempo, namespace o hash. UUID v7 usa un timestamp Unix in millisecondi nella parte più significativa e aggiunge bit casuali, offrendo ordinamento temporale utile per indici e sistemi distribuiti.

Un identificatore time-sortable può migliorare locality in alcuni database, ma espone informazioni temporali e non sostituisce una strategia di ordinamento di business. La versione va scelta in base ai requisiti, non per moda.

Database, API e confini di fiducia

Gli UUID sono comodi come chiavi pubbliche perché non richiedono una sequenza globale e riducono la prevedibilità rispetto a ID incrementali. Possono però essere più pesanti di interi compatti per indici, cache e rappresentazioni testuali.

Un UUID non è un token di autorizzazione. Conoscere o indovinare un identificatore non deve concedere accesso: autenticazione e controlli di permesso devono essere applicati indipendentemente dall'ID.

Best practice

Conserva il valore in un tipo UUID/binary nativo quando il database lo supporta, normalizza la forma testuale ai confini e valida la versione quando il contratto la richiede. Evita di generare UUID con RNG improvvisati.

Definisci anche se l'ID è stabile, pubblico, riutilizzabile e significativo attraverso ambienti diversi. La scelta di un identificatore è parte del modello dati e merita una policy esplicita.

Guide correlate

UUID v1, v4 e v7: generazione, ordinamento, collisioni e design degli ID

Confronto tra versioni UUID e criteri per scegliere identificatori casuali, temporali o ordinabili.