2. Motivation (Motivazione)

2. Motivation (Motivazione)

Uno dei motivi principali per utilizzare gli UUID è che non è richiesta alcuna autorità centralizzata per amministrarli (sebbene due formati possano sfruttare ID di nodo IEEE 802 opzionali, altri non lo fanno). Di conseguenza, la generazione su richiesta può essere completamente automatizzata e utilizzata per una varietà di scopi. L'algoritmo di generazione UUID descritto qui supporta tassi di allocazione molto elevati di 10 milioni al secondo per macchina o più, se necessario, in modo che possano essere utilizzati anche come ID di transazione.

Gli UUID hanno una dimensione fissa (128 bit), che è ragionevolmente piccola rispetto ad altre alternative. Questo si presta bene all'ordinamento, all'ordinamento e all'hashing di tutti i tipi; alla memorizzazione nei database; all'allocazione semplice; e alla facilità di programmazione in generale.

Poiché gli UUID sono unici e persistenti, costituiscono eccellenti URN. La capacità unica di generare un nuovo UUID senza un processo di registrazione consente agli UUID di essere uno degli URN con il costo di conio più basso.

2.1. Motivazione dell'aggiornamento

Molte cose sono cambiate dal momento in cui gli UUID sono stati originariamente creati. Le applicazioni moderne hanno la necessità di creare e utilizzare UUID come identificatore primario per una varietà di elementi diversi in sistemi computazionali complessi, inclusi ma non limitati a chiavi di database, nomi di file, nomi di macchine o sistemi e identificatori per transazioni basate su eventi.

Un'area in cui gli UUID hanno guadagnato popolarità è quella delle chiavi di database. Ciò deriva dalla natura sempre più distribuita delle applicazioni moderne. In tali casi, gli schemi di "auto-incremento" spesso utilizzati dai database non funzionano bene: lo sforzo richiesto per coordinare gli identificatori numerici sequenziali su una rete può facilmente diventare un onere. Il fatto che gli UUID possano essere utilizzati per creare valori unici e ragionevolmente brevi nei sistemi distribuiti senza richiedere coordinamento li rende una buona alternativa, ma le versioni UUID 1-5, originariamente definite da [RFC4122], mancano di alcune altre caratteristiche desiderabili, come:

1. Le versioni UUID che non sono ordinate nel tempo, come UUIDv4 (descritto nella sezione 5.4), hanno una scarsa località dell'indice del database. Ciò significa che i nuovi valori creati in successione non sono vicini tra loro nell'indice; pertanto, richiedono che gli inserimenti vengano eseguiti in posizioni casuali. Gli effetti negativi sulle prestazioni risultanti sulle strutture comuni utilizzate per questo (B-tree e le sue varianti) possono essere drammatici.

2. L'epoca gregoriana di 100 nanosecondi utilizzata nei timestamp UUIDv1 (descritti nella sezione 5.1) è insolita e difficile da rappresentare accuratamente utilizzando un formato numerico standard come quello descritto in [IEEE754].

3. È richiesta l'introspezione/analisi per ordinare per sequenza temporale, al contrario di poter eseguire un semplice confronto byte per byte.

4. Problemi di privacy e sicurezza di rete derivano dall'uso di un indirizzo Media Access Control (MAC) nel campo del nodo di UUIDv1. Gli indirizzi MAC esposti possono essere utilizzati come superficie di attacco per localizzare le interfacce di rete e rivelare varie altre informazioni su tali macchine (come minimo, il produttore e, potenzialmente, altri dettagli). Inoltre, con l'avvento delle macchine virtuali e dei contenitori, l'unicità dell'indirizzo MAC non è più garantita.

5. Molti dei dettagli di implementazione specificati in [RFC4122] comportavano compromessi che non è possibile specificare per tutte le applicazioni né sono necessari per produrre implementazioni interoperabili.

6. [RFC4122] non distingueva tra i requisiti per generare un UUID e quelli per semplicemente memorizzarne uno, sebbene siano spesso diversi.

A causa dei problemi sopra menzionati, molte applicazioni di database ampiamente distribuite e grandi fornitori di applicazioni hanno cercato di risolvere il problema della creazione di un migliore identificatore unico basato sul tempo e ordinabile da utilizzare come chiave del database. Ciò ha portato a numerose implementazioni negli ultimi 10+ anni che risolvono lo stesso problema in modi leggermente diversi.

Durante la preparazione di questa specifica, sono state analizzate le seguenti 16 diverse implementazioni per tendenze in lunghezza totale dell'ID, layout dei bit, formattazione e codifica lessicale, tipo di timestamp, formato del timestamp, precisione del timestamp, formato e componenti del nodo, gestione delle collisioni e sequenziamento della generazione di tick multi-timestamp:

1. [ULID]
2. [LexicalUUID]
3. [Snowflake]
4. [Flake]
5. [ShardingID]
6. [KSUID]
7. [Elasticflake]
8. [FlakeID]
9. [Sonyflake]
10. [orderedUuid]
11. [COMBGUID]
12. [SID]
13. [pushID]
14. [XID]
15. [ObjectID]
16. [CUID]

Un'ispezione di queste implementazioni e dei problemi descritti sopra ha portato a questo documento, in cui i nuovi UUID sono adattati per affrontare questi problemi.

Inoltre, [RFC4122] stesso aveva bisogno di una revisione per affrontare una serie di argomenti come, ma non limitati a, i seguenti:

1. Implementazione di vari rapporti di errata. Principalmente relative a chiarimenti sul layout dei bit, che hanno portato a implementazioni incoerenti [Err1957], [Err3546], [Err4975], [Err4976], [Err5560], ecc.

2. Disaccoppiamento di altre versioni UUID dal layout dei bit UUIDv1 in modo che campi come "time_hi_and_version" non debbano essere referenziati all'interno di un UUID che non è basato sul tempo, fornendo allo stesso tempo sezioni di definizione simili a quella per UUIDv1 per UUIDv3, UUIDv4 e UUIDv5.

3. Fornire best practice di implementazione attorno a molti scenari del mondo reale e casi limite osservati da implementazioni esistenti e prototipali.

4. Affrontare le best practice di sicurezza e le considerazioni per l'era moderna per quanto riguarda gli indirizzi MAC, gli algoritmi di hashing, la casualità sicura e altri argomenti.

5. Fornire alle implementazioni un'opzione basata su standard per progetti UUID specifici dell'implementazione e/o sperimentali.

6. Fornire più vettori di test che illustrino UUID reali creati secondo la specifica.