Strumenti per sviluppatori · Generatore UUID
ULID, Snowflake, KSUID e UUIDv7: ID ordinabili a confronto
· Sfondo
uuid crittografia API del browser
Gli UUID casuali non vengono ordinati in base all'ora di creazione, quindi diversi formati inseriscono prima un timestamp. Questo post mette a confronto ULID, Snowflake, KSUID e UUIDv7 su layout, dimensioni, monotonicità e compatibilità.
ID casuali e l'indice che li odia: il problema risolto dagli identificatori ordinati nel tempo
Gli UUID v4 casuali spargono i punti di inserimento su una chiave primaria dell'albero B quando arrivano nuovi record, causando suddivisioni e riorganizzazione della pagina. Gli inserimenti in posizioni casuali riducono le prestazioni di scrittura e aumentano significativamente la frammentazione del disco. I database ad alto rendimento tollerano questo costo, il prezzo di identificatori veramente indipendenti e non coordinati, ma il costo è reale. Se hai bisogno che gli UUID vengano ordinati in base all'ora di creazione, puoi migliorare notevolmente le caratteristiche dell'indice aggiungendo un prefisso timestamp. Sono emersi diversi formati: ULID, Snowflake, KSUID e RFC 9562 v7. Ciascuno di essi prevede compromessi diversi in termini di dimensioni (caratteri da 26 a 128 bits), precisione del timestamp (da secondi a nanosecondi), compatibilità UUID e se il coordinamento del generatore di ID richiede la centralizzazione. I benchmark del database mostrano che le prestazioni di inserimento migliorano significativamente.
ULID: un timestamp in millisecondi da 48-bit più 80 bit casuali nei caratteri 26 Crockford base32, con un'opzione monotona
ULID (identificatore lessicograficamente univoco ordinabile universale) codifica un timestamp in millisecondi da 48 bit e un payload casuale da 80 bit in caratteri 26 di Crockford base32. La rappresentazione del testo viene ordinata correttamente in ordine lessicografico, rendendo gli ULID adatti a sistemi in cui l'ordine del timestamp e la leggibilità sono importanti: elaborazione dei log, tracciamento distribuito, microservizi in cui gli identificatori devono essere facilmente leggibili nell'output rivolto all'uomo. ULID offre una variante monotona in cui più identificatori generati nello stesso millisecondo incrementano la porzione casuale invece di ripetersi, garantendo che anche i burst di ID rapidi mantengano un rigoroso ordine di generazione. Il compromesso è che ULID non è un UUID: non si adatta a una colonna di database 128-bit standard UUID senza codifica della conversione. La precisione di ULID copre circa 8925 anni.
Fiocco di neve: ID 64-bit da un timestamp, un ID lavoratore e una sequenza e il coordinamento richiesto
Snowflake è un identificatore a 64-bit originariamente progettato da Twitter, strutturato come un timestamp in millisecondi a 41-bit, un ID lavoratore a 10-bit e un numero di sequenza a 12-bit. Il timestamp di 41-bit copre circa 69 anni e supera 2106, richiedendo il coordinamento dell'epoca e la pianificazione della migrazione. L'ID lavoratore distingue gli identificatori generati da diversi server o processi: ciascun generatore Snowflake deve conoscere il proprio ID lavoratore univoco senza entrare in conflitto con gli altri. Snowflake è 64 bits invece di 128, il che lo rende grande la metà di un UUID, più veloce da indicizzare e più efficiente in termini di archiviazione per identificatore. Ordina per ora e ID lavoratore, utile per instradare richieste o log in base all'origine. Lo svantaggio è operativo: a ogni generatore deve essere assegnato un ID lavoratore, gli orologi devono essere mantenuti sincronizzati.
KSUID: un timestamp di secondi con un grande payload casuale, ordinato in byte
KSUID (identificatore univoco K-Sortable) è un identificatore a 128 bit costituito da un secondo timestamp Unix a 32 bit e un payload casuale a 96 bit, in genere codificato come caratteri 27 base62. Il formato è ordinabile in ordine lessicografico e la porzione casuale è crittograficamente corretta per le sue dimensioni. KSUID è adottato meno ampiamente di ULID o Snowflake ma offre una semantica distinta: il timestamp è facilmente decodificato in un secondo leggibile dall'uomo (utile nei log e nel debug) e la porzione casuale di 96 bit è abbastanza grande che più KSUID generati nello stesso secondo hanno effettivamente zero probabilità di duplicazione senza coordinamento della sequenza. A differenza di Snowflake, KSUID non richiede alcun coordinamento dell'ID lavoratore o allocazione centrale. KSUID opera in secondi anziché in millisecondi, quindi più ID entro un secondo vengono ordinati in modo casuale a meno che non si implementi una logica aggiuntiva.
UUIDv7: la risposta basata sugli standard che si adatta alle colonne e agli strumenti uuid esistenti
RFC 9562 v7 è un identificatore 128 bit costituito da un timestamp Unix in millisecondi 48 bit, 12 bits con precisione inferiore al millisecondo (utilizzabile come contatore di sequenza) e 62 bit casuali, tutti combinati. Ordina correttamente sia come stringa lessicografica che come byte a 128bit nei database. Fondamentalmente, è uno UUID valido: imposta il nibble della versione su 7 e i bit delle varianti su RFC 9562 standard, rendendolo compatibile con ogni strumento, colonna di database e API che gestisce gli UUID. Non è necessaria alcuna conversione della codifica e l'infrastruttura UUID esistente non richiede modifiche. Se vengono generati più identificatori v7 nello stesso millisecondo, RFC 9562 consiglia di utilizzare il campo inferiore al millisecondo come contatore monotono anziché bit casuali. V7 rappresenta una scelta pragmatica per mantenere la compatibilità UUID.
Monotonia entro un millisecondo: come ciascun formato gestisce i burst e perché è importante per l'ordinazione delle garanzie
La monotonia è la proprietà per cui se due eventi si verificano in ordine osservabile, i loro ID vengono confrontati nello stesso ordine. Con una granularità a livello di millisecondo sull'hardware moderno, più eventi si verificano regolarmente all'interno dello stesso tick di orologio, quindi qualsiasi schema di ID ordinabili deve gestire correttamente l'ordinamento inferiore al millisecondo. ULID offre una modalità monotona esplicita in cui la porzione casuale aumenta invece di essere randomizzata. Snowflake include un numero di sequenza di 12 bit che aumenta con un tick di millisecondo. KSUID non dispone di un meccanismo integrato, quindi gli eventi inferiori al secondo vengono ordinati in modo casuale a meno che non venga aggiunta logica aggiuntiva. RFC 9562 v7 consiglia di utilizzare il campo inferiore al millisecondo come contatore monotono. Se il tuo sistema genera migliaia di UUID al secondo, la monotonia entro un millisecondo ha un impatto significativo sull'ordine delle query.
Cosa non copre: benchmark del throughput, che dipendono dall'hardware e dalla lingua; il post rimane qualitativo
I benchmark di throughput e i dati sulle prestazioni non sono inclusi perché dipendono fortemente dall'architettura hardware, dall'implementazione del linguaggio, dal motore del database e dalla strategia di memorizzazione nella cache. Le caratteristiche delle prestazioni del database variano in modo significativo a seconda che si stiano misurando inserimenti casuali, query di intervallo, sovraccarico dell'indice o velocità effettiva totale con un carico di produzione realistico. Il post rimane qualitativo, confrontando i formati concettualmente in base alla loro progettazione piuttosto che fornire numeri specifici dell’ambiente che potrebbero essere fuorvianti. La valutazione delle prestazioni nel mondo reale richiede test nel tuo ambiente con il tuo carico di lavoro, base di codice e vincoli operativi. Il confronto tra diversi formati di ID è un esercizio prezioso.
Conclusione: spesso è la compatibilità a decidere: il generatore ToolAcre produce UUID casuali; usa il suo controllo ben formato per confermare che un UUIDv7 dalla tua libreria viene analizzato come UUID
La compatibilità spesso decide quale formato scegliere. Se lo schema del tuo database richiede già colonne UUID, v7 è la risposta moderna all'ordinabilità senza abbandonare l'ecosistema UUID. Se si crea un nuovo sistema con tipi di ID personalizzati, ULID offre una rappresentazione del testo più piccola e vantaggi in termini di precisione al millisecondo. Se hai bisogno di spazio di archiviazione a 64 bit e puoi gestire il coordinamento degli ID dei lavoratori tramite l'allocazione centralizzata, Snowflake è una scelta comprovata nei sistemi ad alto volume. Il compromesso fondamentale è tra la compatibilità standard (scegliere v7) e proprietà alternative come dimensioni più piccole (Snowflake) o leggibilità base32 (ULID). Fare scelte basate sui vincoli del sistema e sulle decisioni dell’ecosistema.