Utilizzo di UUID anziché ID oggetto in MongoDB

Question

Stiamo migrando un database da MySQL a MongoDB per motivi di prestazioni e considerando cosa utilizzare per gli ID dei documenti MongoDB. Stiamo discutendo tra l'uso di ObjectIDs, che è l'impostazione predefinita di MongoDB, o l'uso di UUID (che è quello che abbiamo usato fino ad ora in MySQL). Finora, gli argomenti che devono sostenere una di queste opzioni sono i seguenti:

objectIds: objectIds sono il default MongoDB e presumo (anche se non sono sicuro) che questo è per una ragione, che significa mi aspetto che MongoDB possa gestirli in modo più efficiente degli UUID o ha un altro motivo per preferirli. Ho anche trovato this stackoverflow answer che menziona che l'uso di ObjectID rende l'indicizzazione più efficiente, sarebbe comunque bello avere alcune metriche su quanto questo "più efficiente" sia.

UUID: Il nostro argomento di base a favore di usare gli UUID (ed è un uno abbastanza importante) è che essi sono sostenuti, in un modo o nell'altro, praticamente da qualsiasi database. Ciò significa che se in qualche modo decidiamo di passare da MongoDB a qualcos'altro per qualsiasi motivo e abbiamo già un'API che recupera documenti dal DB in base ai loro ID, nulla cambia per i client di questa API poiché gli ID possono continuare essere esattamente lo stesso Se dovessimo usare ObjectIDs, non sono sicuro di come faremmo per migrarli su un altro DB.

Qualcuno ha qualche idea se una di queste opzioni potrebbe essere migliore dell'altro e perché? Hai mai usato UUID in MongoDB invece di ObjectID e se sì quali sono stati i vantaggi/i problemi che hai riscontrato?

Answer 1

Il campo _id di MongoDB può avere qualsiasi valore desiderato purché sia ​​possibile garantire che sia univoco per la raccolta. Quando i tuoi dati hanno già una chiave naturale, non c'è ragione di non usarli al posto degli ObjectID generati automaticamente.

Gli ObjectID sono forniti come una soluzione predefinita ragionevole per generare un tempo sicuro che genera una propria chiave univoca (e scoraggiare i principianti dal provare a copiare lo AUTO INCREMENT di SQL che è una cattiva idea in un database distribuito).

Non utilizzando ObjectIDs si perde anche un'altra funzione di comodità: Un ObjectID include anche un timestamp unix quando è stato generato e molti driver forniscono una funzione per estrarlo e convertirlo in una data. A volte ciò può rendere ridondante un campo separato create-date.

Ma quando nessuno dei due è un problema per te, sei libero di utilizzare i tuoi UUID come campo _id.

Answer 2

Considerare la quantità di dati che si desidera memorizzare in ciascun caso.

Un MongoDB ObjectID ha una dimensione di 12 byte, viene compresso per l'archiviazione e le sue parti sono organizzate per le prestazioni (ad esempio, la data/ora è memorizzata per prima, che è un criterio di ordinamento logico).

Al contrario, un UUID standard è di 36 byte, contiene trattini e viene in genere memorizzato come stringa. Inoltre, anche se si eliminano i caratteri non numerici e si intende archiviare numericamente, è comunque necessario accontentarsi della parte "indicizzata" (la parte di un UUID v1 basato sul timestamp) nel mezzo dell'UUID e non esegue si prestano bene allo smistamento. Ci sono studies completati che consentono l'archiviazione UUID performante e ho persino scritto un Node.js library per facilitare la sua gestione.

Se si intende utilizzare un UUID, prendere in considerazione la possibilità di riorganizzarlo per l'indicizzazione e l'ordinamento ottimali; altrimenti probabilmente colpirai un muro delle prestazioni.

Answer 3

Ho trovato questi Benchmarks qualche tempo fa quando ho avuto la stessa domanda. Fondamentalmente mostrano che l'utilizzo di un Guid invece di ObjectId causa un calo delle prestazioni dell'indice.

Vorrei comunque consigliare di personalizzare i Benchmark per imitare il tuo specifico scenario di vita reale e vedere come appaiono i numeri, uno non può contare al 100% su Benchmark generici.