È difficile dire quale sia l'inserimento di massa ottimale:questo dipende in parte dalle dimensioni degli oggetti che stai inserendo e da altri fattori incommensurabili. Potresti provare alcune gamme e vedere cosa ti offre le migliori prestazioni. In alternativa, ad alcune persone piace usare mongoimport, che è piuttosto veloce, ma i dati di importazione devono essere json o csv. C'è ovviamente mongodrestore, se i dati sono in formato BSON.
Mongo può facilmente gestire miliardi di documenti e avere miliardi di documenti in un'unica raccolta, ma ricorda che il la dimensione massima del documento è 16 MB . Ci sono molte persone con miliardi di documenti in MongoDB e ci sono molte discussioni a riguardo su Gruppo utenti Google MongoDB . Ecco un documento sull'utilizzo di un gran numero di raccolte che potresti voler leggere, se cambi idea e desideri invece avere più raccolte. Più raccolte hai, più indici avrai anche, che probabilmente non è quello che vuoi.
Ecco una presentazione da Craigslist sull'inserimento di miliardi di documenti in MongoDB e sul blogpost .
Sembra che lo sharding sarebbe una buona soluzione per te, ma in genere lo sharding viene utilizzato per il ridimensionamento su più server e molte persone lo fanno perché vogliono ridimensionare le loro scritture o non sono in grado di mantenere il loro set di lavoro (dati e indici) nella RAM. È perfettamente ragionevole iniziare con un singolo server e poi passare a uno shard o a un set di repliche man mano che i tuoi dati crescono o hai bisogno di ridondanza e resilienza extra.
Tuttavia, ci sono altri utenti che usano più mongod per aggirare i limiti di blocco di un singolo mongod con molte scritture. È ovvio ma vale comunque la pena dirlo, ma una configurazione multi-mongod è più complessa da gestire rispetto a un singolo server. Se il tuo IO o CPU non è al massimo qui, il tuo set di lavoro è più piccolo della RAM e i tuoi dati sono facili da mantenere bilanciati (distribuiti abbastanza casualmente), dovresti vedere un miglioramento (con lo sharding su un singolo server). Come FYI, esiste il potenziale per la memoria e la contesa IO. Con 2.2 che ha migliorato la concorrenza con db blocco , sospetto che ci saranno molte meno ragioni per una tale distribuzione.
Devi pianificare correttamente la tua mossa verso lo sharding, ad es. riflettere attentamente sulla scelta della chiave shard. Se si procede in questo modo, è meglio pre-dividere e spegnere il bilanciatore. Sarà controproducente spostare i dati per mantenere le cose in equilibrio, il che significa che dovrai decidere in anticipo come dividerli. Inoltre, a volte è importante progettare i documenti con l'idea che alcuni campi possano essere utili per il partizionamento orizzontale o come chiave primaria.
Ecco alcuni buoni collegamenti -
- Scelta di una chiave shard
- Post del blog sulle chiavi shard
- Presentazione panoramica sullo sharding
- Presentazione sulle migliori pratiche di sharding
