Si MongoDB a un talon d'Achille, c'est qu'il ne prend en charge que les écritures monothread et les mappages map single-thread.
Comme toujours, il y a des compromis ici. Les écritures à un seul thread sont le moyen le plus simple d'éviter les problèmes de verrouillage et de minimiser les frais généraux. De la même manière, la réduction de la carte multithread est un excellent moyen de verrouiller vos données. Ainsi, la réduction de la carte à un seul thread sur un système de production est probablement plus facile et plus sûre.
Cependant, vous n'êtes pas sans outils ici. MongoDB fournira un thread d'écriture à chaque instance. Donc, si vous tuez MongoDB, vous obtiendrez un thread d'écriture pour chaque fragment.
Si vous voulez plusieurs index sur 2 milliards de lignes, vous voudrez de toute façon considérer le sharding. Quelques maths rapides ici: MongoID est de 12 octets. L'index sur MongoID sera 2B * 12 octets = 22GB +. Si vous voulez maintenant ajouter deux index supplémentaires (même seulement deux entiers de 4 octets), nous parlons de 7,5 Go pour chacun. Donc, à 2B lignes, vous parlez d'avoir plus de 37GB dans les index (minimum). Sur la plupart des serveurs 8-core, cela signifie que vous ne serez même pas en mesure de conserver vos index en mémoire, sans parler des données. Donc, si vous voulez des performances sérieuses ici, vous aurez envie de commencer à regarder sharding. Juste basé sur les chiffres généraux. FWIW, MySQL ne serait plus adepte de la gestion des documents 2B. Avec autant de données, vous allez vraiment vouloir plusieurs serveurs pour faire face à la charge.
Je ne pense pas que vous pouvez gérer efficacement l'insertion de données à partir de nombreux cœurs à la fois. – zneak
@zneak: Je pensais en fait à insérer des données dans plusieurs collections (tables). Juste que je n'étais pas vraiment sûr si la séparation de cette façon serait bénéfique. Je veux dire, au lieu d'ajouter un index sur une grande table, je créerais beaucoup de petites tables et ensuite créerais un index sur chacune d'entre elles. Et puis à partir du front-end, je vais interroger toutes les tables pour obtenir les valeurs requises. Avez-vous des suggestions sur cette approche? – Legend
Je ne suis pas un expert NoSQL. Tout ce que je sais, c'est que vous ne pouvez pas modifier en toute sécurité les données de plusieurs threads sans le verrouiller, d'où mon commentaire. :/Désolé je ne peux pas aider. (Cependant, je sais aussi que vous devez remplir vos collections, puis créer les index, sinon vous perdez beaucoup de temps à réindexer les données à chaque insertion.) – zneak