Idées fausses
Vitesse
Même sans parler d'un index multi-clé, voici ce qui se passe. Il y a une analyse massive de table en cours. Donc mongoDB parcourt les documents, essaie de trouver le champ à indexer, évalue ce champ (en null s'il n'existe pas dans le document courant) et écrit ses conclusions dans pas moins de 6 fichiers puisque nous parlons de 6 index. Faire le calcul :200.000.000 / 86400 * 5 nous indique que mongoDB fait cela pour environ 460 documents par seconde ou ne nécessite que 2,2 millisecondes par document . Je n'appellerais pas cela lent. Cela peut prendre du temps, mais ce n'est pas lent.
{background:true}
L'utilisation de ce paramètre ne fait pas vous exclure des bases de données. Bien au contraire, ce qui est clairement indiqué dans les docs, à la fois sur le Section Création d'index et dans la section tutoriel sur la création d'index en arrière-plan . Cependant, il y a une phrase qui peut facilement être mal interprétée :
Cela signifie que vous ne pouvez pas effectuer d'opérations qui s'appliquent à toutes les bases de données et nécessitent un verrou en lecture ou en écriture.
Moyens d'amélioration (à l'avenir)
Cluster partagé
Utilisez un cluster partagé avec des fragments d'ensemble de répliques. Il est facile à configurer et présente de nombreux avantages en plus de performances améliorées. L'un d'eux est l'évolutivité facile en ajoutant un fragment (et donc en ajoutant de l'espace et de la puissance de calcul à un cluster) est très facile. Les sauvegardes ont moins d'impact sur l'application. Il n'y a plus de point de défaillance unique (lorsque c'est bien fait, cela s'applique même aux pannes à l'échelle de tout un centre de données).
Utiliser un autre système de fichiers
Désolé, l'exécution d'une application dépendante des performances du disque io sur un serveur Windows n'a aucun sens pour moi - du tout. ExtFS4 ou XFS sont entre 25% et 40% plus rapides que NTFS ou ReFS, selon l'optimisation. Cela fait un vrai différence sur les applications qui dépendent autant des E/S de disque que votre cas d'utilisation. Nous parlons d'une question de jours (sans même tenir compte du mappage de mémoire plus efficace et de la consommation de mémoire réduite du système d'exploitation sur les systèmes Linux).
{background:true}
Bien que cela n'améliore pas vraiment les performances (en fait, la construction d'index en arrière-plan prend plus de temps qu'en premier plan pour des raisons évidentes), votre application reste disponible pendant la durée de construction de l'index. Donc, selon vos besoins, cela peut être une option viable.
Remarque :C'est une mauvaise idée™ , à mettre à l'échelle verticalement lors de l'utilisation de mongoDB puisqu'il a été explicitement conçu pour être mis à l'échelle horizontalement. Cela s'applique particulièrement aux grandes collections comme la vôtre, car le traitement parallèle améliorerait considérablement les performances de votre application.
