Il est difficile de dire quel est l'insert en vrac optimal - cela dépend en partie de la taille des objets que vous insérez et d'autres facteurs incommensurables. Vous pouvez essayer quelques gammes et voir ce qui vous donne les meilleures performances. Comme alternative, certaines personnes aiment utiliser mongoimport, qui est assez rapide, mais vos données d'importation doivent être json ou csv. Il y a évidemment mongodrestore, si les données sont au format BSON.
Mongo peut facilement gérer des milliards de documents et peut avoir des milliards de documents dans une seule collection, mais rappelez-vous que le la taille maximale du document est de 16 Mo . Il y a beaucoup de gens avec des milliards de documents dans MongoDB et il y a beaucoup de discussions à ce sujet sur le Groupe d'utilisateurs Google MongoDB . Voici un document sur l'utilisation d'un grand nombre de collections que vous aimeriez lire, si vous changez d'avis et souhaitez plutôt avoir plusieurs collections. Plus vous avez de collections, plus vous aurez également d'index, ce qui n'est probablement pas ce que vous voulez.
Voici une présentation de Craigslist sur l'insertion de milliards de documents dans MongoDB et article de blog .
Il semble que le partage soit une bonne solution pour vous, mais le partage est généralement utilisé pour la mise à l'échelle sur plusieurs serveurs et beaucoup de gens le font parce qu'ils veulent mettre à l'échelle leurs écritures ou qu'ils ne peuvent pas conserver leur ensemble de travail (données et index) dans la RAM. Il est tout à fait raisonnable de commencer avec un seul serveur, puis de passer à une partition ou à un ensemble de répliques à mesure que vos données augmentent ou que vous avez besoin de redondance et de résilience supplémentaires.
Cependant, d'autres utilisateurs utilisent plusieurs mongods pour contourner les limites de verrouillage d'un seul mongod avec de nombreuses écritures. C'est évident mais ça vaut quand même la peine de le dire mais une configuration multi-mongod est plus complexe à gérer qu'un seul serveur. Si votre IO ou votre processeur n'est pas maximisé ici, votre ensemble de travail est plus petit que la RAM et vos données sont faciles à maintenir équilibrées (distribuées de manière assez aléatoire), vous devriez voir une amélioration (avec le sharding sur un seul serveur). En tant que FYI, il existe un potentiel de conflit de mémoire et d'E/S. Avec 2.2 ayant amélioré la concurrence avec db verrouillage , je soupçonne qu'il y aura beaucoup moins de raisons pour un tel déploiement.
Vous devez planifier correctement votre passage au sharding, c'est-à-dire bien réfléchir au choix de votre clé de shard. Si vous suivez cette voie, il est préférable de pré-séparer et d'éteindre l'équilibreur. Il sera contre-productif de déplacer des données pour maintenir l'équilibre, ce qui signifie que vous devrez décider à l'avance comment les diviser. De plus, il est parfois important de concevoir vos documents avec l'idée que certains champs seront utiles pour le partage ou comme clé primaire.
Voici quelques bons liens -
- Choisir une clé de partition
- Article de blog sur les clés de partitionnement
- Présentation générale sur le sharding
- Présentation sur les meilleures pratiques de partage
