MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Ci sono dei vantaggi nell'usare un _id personalizzato per i documenti in MongoDB?

Vantaggi della generazione del tuo _id s:

  • Puoi renderli più a misura d'uomo, assegnando numeri crescenti:1 , 2 , 3 , ...

  • Oppure puoi renderli più a misura d'uomo, usando stringhe casuali:t3oSKd9q

    (Ciò non occupa troppo spazio sullo schermo, potrebbe essere selezionato da un elenco e potrebbe essere potenzialmente copiato manualmente se necessario. Tuttavia è necessario renderlo abbastanza lungo per evitare collusioni.)

  • Se si utilizzano stringhe generate casualmente, avranno una distribuzione di partizionamento orizzontale approssimativamente uniforme, a differenza degli ObjectId mongo standard, che tende a raggruppare i record creati nello stesso momento sullo stesso shard. (Il fatto che sia utile o meno dipende davvero dalla tua strategia di partizionamento orizzontale.)

  • Oppure potresti voler generare il tuo _id personalizzato s che raggrupperanno oggetti correlati su uno shard, ad es. per proprietario, o regione geografica, o una combinazione. (Di nuovo, se ciò sia desiderabile o meno dipende da come intendi interrogare i dati e/o dalla rapidità con cui li stai producendo e archiviandoli. Puoi anche farlo specificando una chiave shard, anziché _id si. Vedi la discussione di seguito.)

Vantaggi dell'utilizzo di ObjectId s:

  • Gli ObjectId sono molto efficaci nell'evitare le collisioni. Se generi il tuo _id s in modo casuale o simultaneo, devi gestire tu stesso il rischio di collisione.

  • Gli ObjectId contengono al loro interno il tempo di creazione. Questo può essere un modo semplice ed economico per conservare la data di creazione di un documento e per ordinare i documenti in ordine cronologico. (D'altra parte, se non vuoi esporre/divulgare la data di creazione di un documento, allora non devi esporre il suo ObjectId!)

Il nanoide il modulo può aiutarti a generare brevi ID casuali. Forniscono anche un calcolatore che può aiutarti a scegliere una buona lunghezza dell'ID, a seconda di quanti documenti/ID stai generando ogni ora.

In alternativa, ho scritto mongoose-generate-unique-key per generare molto ID casuali brevi (a condizione che tu stia utilizzando la libreria mangusta).

Strategie di ripartizione

Non pretenderò di essere un esperto del modo migliore per frammentare i dati, ma ecco alcune situazioni che potremmo prendere in considerazione:

  1. Un osservatorio astronomico o un acceleratore di particelle gestisce gigabyte di dati al secondo. Quando viene rilevato un evento interessante, potrebbero voler memorizzare un'enorme quantità di dati in pochi secondi. In questo caso, probabilmente vogliono una distribuzione uniforme dei documenti tra gli shard, in modo che ogni shard lavorerà allo stesso modo per archiviare i dati e nessuno sarà sopraffatto.

  2. Hai un'enorme quantità di dati e talvolta devi elaborarli tutti subito. In questo caso (ma a seconda dell'algoritmo) potrebbe essere di nuovo desiderabile una distribuzione uniforme, in modo che tutti gli shard possano lavorare allo stesso modo sull'elaborazione della loro porzione di dati, prima di combinare i risultati alla fine. (Anche se in questo scenario, potremmo essere in grado di fare affidamento sul bilanciatore di MongoDB, piuttosto che sulla nostra chiave shard, per la distribuzione uniforme. Il bilanciatore viene eseguito in background dopo che i dati sono stati archiviati. Dopo aver raccolto molti dati, potrebbe essere necessario lascia che ridistribuisca i pezzi durante la notte.)

  3. Hai un'app di social media con una grande quantità di dati, ma questa volta molti utenti diversi stanno facendo molte query leggere relativi principalmente ai propri dati, o ai loro amici o argomenti specifici. In questo caso, non ha senso coinvolgere ogni shard ogni volta che un utente fa una piccola query. Potrebbe avere senso shard per userId (o per argomento o per area geografica) in modo che tutti i documenti appartenenti a un utente vengano archiviati su uno shard e quando quell'utente effettua una query, solo uno shard deve funzionare. Ciò dovrebbe lasciare gli altri shard liberi di elaborare le query per altri utenti, quindi è possibile servire più utenti contemporaneamente.

  4. Sharding dei documenti in base al momento della creazione (che gli ObjectId predefiniti ti daranno) potrebbe essere desiderabile se hai molte query leggere che esaminano i dati per periodi di tempo simili. Ad esempio molti utenti diversi che interrogano diversi grafici storici.

    Ma potrebbe non essere così desiderabile se la maggior parte dei tuoi utenti interroga solo i documenti più recenti (una situazione comune sulle piattaforme di social media) perché ciò significherebbe che uno o due frammenti otterrebbero la maggior parte del lavoro. La distribuzione per argomento o forse per regione potrebbe fornire una distribuzione complessiva più piatta, consentendo anche ai documenti correlati di raggrupparsi in un unico shard.

Ti potrebbe piacere leggere i documenti ufficiali su questo argomento: