Si MongoDB a un talon d'Achille, c'est le fait qu'il ne prend en charge que les écritures à un seul thread et les réductions de carte à un seul 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 la surcharge. De la même manière, les réductions de carte multithread sont un excellent moyen de verrouiller vos données. Ainsi, les réductions de carte à un seul thread sur un système de production sont probablement plus faciles et plus sûres.
Cependant, vous n'êtes pas sans outils ici. MongoDB fournira un thread d'écriture à chaque instance. Donc, si vous partitionnez MongoDB, vous obtiendrez un thread d'écriture pour chaque partition.
Si vous voulez plusieurs index sur 2 milliards de lignes, vous voudrez quand même envisager le sharding. Quelques calculs rapides ici :MongoID est de 12 octets. L'index sur MongoID sera de 2B * 12 octets =22 Go +. Si vous souhaitez maintenant ajouter deux index supplémentaires (même seulement deux entiers de 4 octets), nous parlons d'environ 7,5 Go pour chacun.
Ainsi, à 2 milliards de lignes, vous parlez d'avoir plus de 37 Go dans les index (minimum ). Sur la plupart des serveurs à 8 cœurs, cela signifie que vous ne pourrez même pas conserver vos index en mémoire, sans parler des données.
Donc, si vous voulez des performances sérieuses ici, vous voudrez commencer à regarder le sharding. Juste basé sur les chiffres généraux. FWIW, MySQL ne serait plus apte à gérer les documents 2B. Avec autant de données, vous aurez vraiment besoin de plusieurs serveurs pour faire face à la charge.
