UUID v4 vs v7: quale identificatore univoco scegliere?

Un UUID è un identificatore di 128 bit univoco senza coordinamento centrale. La versione 4, interamente casuale, domina da anni. La versione 7, più recente (RFC 9562, 2024), integra un timestamp in testa per produrre identificatori ordinati nel tempo. Questa differenza, apparentemente innocua, cambia radicalmente le prestazioni nel database. Ecco quale scegliere.

Cos'è un UUID?

Un UUID (Universally Unique Identifier) è un numero di 128 bit rappresentato da 32 caratteri esadecimali raggruppati in cinque blocchi, ad esempio 550e8400-e29b-41d4-a716-446655440000. La sua ragion d'essere: generare un identificatore univoco senza chiedere a un'autorità centrale, il che lo rende ideale per i sistemi distribuiti. Puoi generarne con il nostro generatore di UUID.

Esistono diverse versioni; le più pertinenti oggi per le chiavi di record sono la v4 (casuale) e la v7 (ordinata nel tempo).

UUID v4 (casuale)

L'UUID v4 è costituito da 122 bit casuali (il resto codifica la versione e il variant). La probabilità di collisione è così bassa da essere trascurabile in pratica. È la versione predefinita nella maggior parte dei linguaggi e delle librerie.

• Imprevedibile: perfetto per token o identificatori pubblici che non si vogliono indovinabili
• Nessuna fuga di informazioni: non rivela né data né ordine di creazione
• Svantaggio: completamente disordinato, il che penalizza gli indici di database

UUID v7 (ordinato nel tempo)

L'UUID v7 colloca un timestamp Unix in millisecondi sui suoi primi 48 bit, seguito da bit casuali. Due UUID v7 generati in istanti diversi si ordinano quindi nell'ordine della loro creazione, pur restando univoci e praticamente impossibili da indovinare.

• Ordinabile: l'ordine lessicografico corrisponde all'ordine cronologico
• Amico degli indici: gli inserimenti avvengono in fondo all'indice, come un auto-incremento
• Contropartita: rivela l'istante di creazione, il che può essere indesiderato per un identificatore pubblico

Tabella comparativa

Impatto sui database

È il cuore della questione. I database relazionali memorizzano i loro indici in alberi B (B-tree). Inserire chiavi casuali (v4) disperde le scritture ovunque nell'indice, provocando frammentazione, suddivisioni di pagina e una cache meno efficiente. Su grandi volumi, le prestazioni di inserimento si degradano nettamente.

Le chiavi ordinate (v7) si inseriscono sempre alla fine dell'indice, come un identificatore auto-incrementato. Si ritrovano inserimenti rapidi, una migliore località e un indice più compatto. Questo è particolarmente evidente con una chiave primaria in InnoDB (MySQL), dove la chiave primaria determina l'ordine fisico delle righe.

Quando scegliere l'uno o l'altro

Scegliere UUID v4 quando

• L'identificatore è esposto pubblicamente e non deve rivelare nulla
• Generi token, link di condivisione, segreti
• L'ordine e la data di creazione non devono essere indovinabili
• Vuoi la massima compatibilità con l'esistente

Scegliere UUID v7 quando

• L'UUID funge da chiave primaria in un database
• Il volume di inserimenti è elevato e le prestazioni dell'indice contano
• Vuoi ordinare per ordine di creazione senza una colonna dedicata
• Rivelare l'istante di creazione non è un problema

Raccomandazione

Per una chiave primaria di database, preferisci ormai UUID v7: mantieni l'unicità distribuita dell'UUID evitando al contempo la penalità di indice della v4. Conserva UUID v4 per gli identificatori pubblici, i token e i segreti, dove l'imprevedibilità totale e l'assenza di fuga temporale hanno la priorità.

Verifica comunque il supporto della v7 nel tuo linguaggio e nel tuo ORM: la RFC è recente, ma l'adozione progredisce in fretta.

Domande frequenti