Creazione di ID oggetto personalizzato in MongoDB

Question

Sto creando un servizio per il quale userò MongoDB come back-end di archiviazione. Il servizio produrrà un hash dell'input dell'utente e quindi vedrà se lo stesso hash (+ input) esiste già nel nostro set di dati.

L'hash sarà unica ancora casuale (= non incrementale/sequenziale), quindi la mia domanda è:

1. E '-legitimate- ad utilizzare un valore casuale per un ID oggetto? Esempio:

$object_id = new MongoId(HEX-OF-96BIT-HASH);

O sarà MongoDB trattare l'ObjectID in modo diverso da altri quelli del server di produzione, dal momento che un "vero" ObjectID contiene anche timestamp, machine_id, ecc?

Quali sono i pro e i contro dell'uso di un valore "casuale"? Immagino che sarebbe statisticamente più lento per il motore aggiornare l'indice sugli inserti quando i nuovi _id non sono in alcun modo incrementali - sono corretti su questo?

Answer 1

Sì, è perfettamente corretto utilizzare un valore casuale per un ID oggetto, se un valore è presente nel campo _id di un documento che viene archiviato, viene considerato come oggetto ID.

Poiché il campo _id è sempre indicizzato e la chiave primaria, è necessario assicurarsi che venga creato un objectid diverso per ciascun oggetto. Esistono alcune linee guida per ottimizzare gli ID oggetto definiti dall'utente:

http://www.mongodb.org/display/DOCS/Optimizing+Object+IDs#OptimizingObjectIDs-Usethecollections%27naturalprimarykey%27intheidfield.

Answer 2

Il fatto che sia buono o cattivo dipende dalla sua unicità. Ovviamente l'ObjectId fornito da MongoDB è piuttosto unico quindi questa è una buona cosa. Finché riesci a replicare quell'unicità, dovresti stare bene.

Non ci sono rischi intrinseci/prestazioni perse utilizzando il proprio ID. Immagino che usarlo in forma di stringa possa usare più potenza di indice/memoria/interrogazione ma lì lo stai usando in forma MongoID (ObjectId) che dovrebbe preservare i punti di forza di non memorizzarlo in una semplice stringa.

Answer 3

ho appena scoperto una risposta a una delle mie domande, riguardo alle prestazioni di indicizzazione:

Se i _id di trovano in un ordine in qualche modo ben definito, su inserti tutto il B-tree per l'indice _id non è necessario essere caricato I BONI ObjectId hanno questa proprietà.

Fonte: http://www.mongodb.org/display/DOCS/Optimizing+Object+IDs

Answer 4

Mentre tutti i valori, tra cui hash, possono essere utilizzati per il campo _id, consiglio di non usare valori casuali per due motivi:

1. Potrebbe essere necessario sviluppare una strategia di gestione delle collisioni nel caso in cui si producano valori casuali identici per due oggetti diversi. Nella domanda, implichi che genererai ID usando un qualche tipo di algoritmo di hash. Non considererei questi valori "casuali" poiché sono basati sul contenuto che stai digerendo con l'hash. La probabilità di una collisione è quindi una funzione della diversità di contenuti e dell'algoritmo di hash. Se stai usando qualcosa come MD5 o SHA-1, non mi preoccuperei dell'algoritmo, solo del contenuto che stai facendo.Se hai bisogno di sviluppare una strategia di gestione delle collisioni, non devi assolutamente utilizzare ID casuali o basati su hash come la gestione delle collisioni in un ambiente cluster è complicato e richiede ulteriori query.

2. I valori casuali così come i valori hash sono intenzionalmente destinati a essere dispersi sulla linea numerica. Questo (a) richiederà sempre più indici B-tree da conservare in memoria e (b) potrebbe causare prestazioni di inserimento variabili a causa del ribilanciamento dell'albero B. MongoDB è ottimizzato per gestire gli ObjectID, che vengono in ordine crescente (con una granularità di un secondo). Probabilmente starai meglio con loro.