Esta não será uma resposta completa de longe, há muitos detalhes e eu poderia escrever um ensaio inteiro sobre essa questão como muitos outros, no entanto, como não tenho esse tempo de sobra, adicionarei alguns comentários sobre o que vejo.

Os conjuntos de réplicas não foram projetados para funcionar assim. Se você deseja balancear a carga, pode estar procurando por fragmentação que permitirá que você faça isso.

A replicação é para failover automático.

Como, para se manter atualizado, seus membros receberão tantas operações quanto o principal, parece que isso pode não ajudar muito.

Na realidade, em vez de ter um servidor com muitas conexões enfileiradas, você tem muitas conexões em muitos servidores enfileirados para dados obsoletos, pois a consistência dos membros é eventual, não imediata, ao contrário das tecnologias ACID, no entanto, dito que elas são apenas eventualmente consistentes por 32 ms ímpares que significa que eles não estão atrasados ​​o suficiente para fornecer uma taxa de transferência decente se o primário estiver carregado.

Como as leituras SÃO simultâneas, você obterá a mesma velocidade se estiver lendo do primário ou do secundário. Suponho que você poderia atrasar um escravo para criar uma pausa de OPs, mas isso traria de volta dados massivamente obsoletos em troca.

Sem mencionar que o MongoDB não é multi-mestre, como tal, você só pode gravar em um nó por vez, tornando slaveOK não mais a configuração mais útil do mundo e eu já vi várias vezes em que a própria 10gen recomenda que você use sharding sobre essa configuração.

Isso exigiria sua própria codificação. Nesse ponto, você pode considerar usar um banco de dados que suporte http://en.wikipedia .org/wiki/Multi-master_replication

Isso ocorre porque a velocidade que você está procurando é mais provável de fato em gravações, não em leituras, como discuti acima.

Esta é a maneira recomendada, mas você encontrou a ressalva com ela. Infelizmente, isso é algo que permanece sem solução que a replicação multimestre deve resolver, no entanto, a replicação multimestre adiciona seu próprio navio de ratos da peste à própria Europa e eu recomendo fortemente que você faça uma pesquisa séria antes de pensar se Atualmente, o MongoDB não pode atender às suas necessidades.

Você pode estar se preocupando com nada realmente, já que a fila fsync foi projetada para lidar com o gargalo de IO, diminuindo a velocidade de suas gravações, como aconteceria no SQL e as leituras são simultâneas; portanto, se você planejar seu esquema e conjunto de trabalho corretamente, poderá obter um enorme quantidade de OPs.

Na verdade, há uma pergunta vinculada por aqui de um funcionário da 10ª geração que é muito boa de ler:https:/ /stackoverflow.com/a/17459488/383478 e mostra a quantidade de throughput que o MongoDB pode alcançar sob carga.

Ele crescerá em breve com o novo bloqueio de nível de documento que já está na ramificação dev.