Ce ne sera pas une réponse complète de loin, il y a trop de détails et je pourrais écrire un essai entier sur cette question comme beaucoup d'autres cependant, comme je n'ai pas ce genre de temps à perdre, j'ajouterai quelques commentaires à propos de ce que je vois.
Les ensembles de répliques ne sont pas conçus pour fonctionner comme ça. Si vous souhaitez équilibrer la charge, vous recherchez peut-être en fait un partitionnement qui vous permettra de le faire.
La réplication est destinée au basculement automatique.
Étant donné que, pour rester à jour, vos membres recevront autant d'opérations que le primaire, il semble que cela n'aide pas trop.
En réalité, au lieu d'avoir un serveur avec de nombreuses connexions en file d'attente, vous avez de nombreuses connexions sur de nombreux serveurs en file d'attente pour des données obsolètes, car la cohérence des membres est éventuelle, pas immédiate contrairement aux technologies ACID, cependant, cela étant dit, ils ne sont finalement cohérents que par 32 ms impairs qui signifie qu'ils ne sont pas suffisamment en retard pour donner un débit décent si le primaire est chargé.
Étant donné que les lectures SONT simultanées, vous obtiendrez la même vitesse, que vous lisiez à partir du primaire ou du secondaire. Je suppose que vous pourriez retarder un esclave pour créer une pause d'OP, mais cela ramènerait des données massivement obsolètes en retour.
Sans oublier que MongoDB n'est pas multi-maître en tant que tel, vous ne pouvez écrire que sur un nœud à la fois, ce qui fait que slaveOK n'est plus le paramètre le plus utile au monde et j'ai vu de nombreuses fois où 10gen eux-mêmes vous recommandent d'utiliser le sharding sur ce paramètre.
Cela nécessiterait votre propre codage. À ce stade, vous voudrez peut-être envisager d'utiliser une base de données qui prend en charge http://en.wikipedia .org/wiki/Multi-master_replication
En effet, la vitesse que vous recherchez est très probablement en écriture et non en lecture, comme je l'ai expliqué ci-dessus.
C'est la méthode recommandée, mais vous avez trouvé la mise en garde avec elle. C'est malheureusement quelque chose qui reste non résolu que la réplication multi-maître est censée résoudre, cependant, la réplication multi-maître ajoute son propre navire de rats pesteux à l'Europe elle-même et je vous recommande fortement de faire des recherches sérieuses avant de vous demander si MongoDB ne peut pas actuellement répondre à vos besoins.
Vous ne vous souciez peut-être de rien, car la file d'attente fsync est conçue pour gérer le goulot d'étranglement des E/S qui ralentit vos écritures comme dans SQL et les lectures sont simultanées, donc si vous planifiez correctement votre schéma et votre ensemble de travail, vous devriez pouvoir obtenir un énorme nombre d'OP.
Il y a en fait une question liée ici d'un employé de 10gen qui est très bonne à lire :https:/ /stackoverflow.com/a/17459488/383478 et cela montre à quel point MongoDB peut atteindre un débit en charge.
Il se développera bientôt avec le nouveau verrouillage au niveau du document qui est déjà dans la branche de développement.
