Esta no será una respuesta completa de lejos, hay demasiados detalles y podría escribir un ensayo completo sobre esta pregunta al igual que muchas otras, sin embargo, dado que no tengo ese tiempo de sobra, agregaré algunos comentarios. sobre lo que veo.
Los conjuntos de réplicas no están diseñados para funcionar así. Si desea equilibrar la carga, es posible que esté buscando fragmentación que le permita hacer esto.
La replicación es para conmutación por error automática.
Dado que, para mantenerse actualizados, sus miembros recibirán tantas operaciones como el principal, parece que esto podría no ser de mucha ayuda.
En realidad, en lugar de tener un servidor con muchas conexiones en cola, tiene muchas conexiones en muchos servidores en cola para obtener datos obsoletos, ya que la coherencia de los miembros es eventual, no inmediata a diferencia de las tecnologías ACID; significa que no se están retrasando lo suficiente como para dar un rendimiento decente si el primario está cargado.
Dado que las lecturas SON simultáneas, obtendrá la misma velocidad ya sea que esté leyendo desde el primario o el secundario. Supongo que podría retrasar un esclavo para crear una pausa de los OP, pero eso traería a cambio datos obsoletos de forma masiva.
Sin mencionar que MongoDB no es multimaestro, como tal, solo puede escribir en un nodo a la vez, lo que hace que SlaveOK ya no sea la configuración más útil del mundo y he visto numerosas veces que 10gen recomienda usar fragmentación sobre esta configuración.
Esto requeriría su propia codificación. En ese momento, es posible que desee considerar el uso de una base de datos que admita http://en.wikipedia .org/wiki/Multi-master_replication
Esto se debe a que lo más probable es que la velocidad que está buscando sea de escritura, no de lectura, como mencioné anteriormente.
Esta es la forma recomendada, pero ha encontrado la advertencia. Desafortunadamente, esto es algo que sigue sin resolverse y que se supone que debe resolver la replicación multimaestro, sin embargo, la replicación multimaestro agrega su propio barco de ratas de plaga a Europa y le recomiendo encarecidamente que haga una investigación seria antes de pensar en si MongoDB no puede satisfacer sus necesidades actualmente.
Es posible que no se preocupe por nada en realidad, ya que la cola fsync está diseñada para lidiar con el cuello de botella de IO que ralentiza sus escrituras como lo haría en SQL y las lecturas son simultáneas, por lo que si planifica su esquema y conjunto de trabajo correctamente, debería poder obtener un gran cantidad de OP.
De hecho, hay una pregunta vinculada por aquí de un empleado de 10gen que es muy buena para leer:https:/ /stackoverflow.com/a/17459488/383478 y muestra cuánto rendimiento puede lograr MongoDB bajo carga.
Pronto crecerá con el nuevo bloqueo de nivel de documento que ya está en la rama de desarrollo.
