Dit zal bij lange na geen volledig antwoord zijn, er zijn te veel details en ik zou een heel essay over deze vraag kunnen schrijven, zoals vele anderen, maar aangezien ik niet zoveel tijd over heb, zal ik wat commentaar toevoegen over wat ik zie.
Replica-sets zijn niet ontworpen om zo te werken. Als u de balans wilt laden, zoekt u misschien naar sharding waarmee u dit kunt doen.
Replicatie is voor automatische failover.
Omdat, om op de hoogte te blijven, je leden net zoveel operaties zullen krijgen als de primaire, lijkt het erop dat dit niet al te veel zal helpen.
In werkelijkheid, in plaats van één server met veel verbindingen in de wachtrij te hebben staan, heb je veel verbindingen op veel servers die in de rij staan voor verouderde gegevens, aangezien ledenconsistentie uiteindelijk is, niet onmiddellijk in tegenstelling tot ACID-technologieën, maar dat gezegd hebbende, zijn ze uiteindelijk pas consistent met 32-tal ms die betekent dat ze niet genoeg achterblijven om een behoorlijke doorvoer te geven als de primaire is geladen.
Aangezien lezen gelijktijdig ZIJN, krijgt u dezelfde snelheid, of u nu van de primaire of secundaire leest. Ik veronderstel dat je een slaaf zou kunnen uitstellen om een pauze van OP's te creëren, maar dat zou enorm oude gegevens terugbrengen.
Om nog maar te zwijgen van het feit dat MongoDB geen multi-master is, omdat je maar naar één knooppunt per keer kunt schrijven, waardoor slaveOK niet meer de meest bruikbare instelling ter wereld is en ik heb talloze keren gezien dat 10gen zelf aanbeveelt om sharding over deze instelling te gebruiken.
Hiervoor heeft u eigen codering nodig. Op dat moment zou je kunnen overwegen om een database te gebruiken die http://en.wikipedia ondersteunt .org/wiki/Multi-master_replication
Dit komt omdat de snelheid die u zoekt hoogstwaarschijnlijk in schrijft en niet leest, zoals ik hierboven heb besproken.
Dit is de aanbevolen manier, maar je hebt het voorbehoud ermee gevonden. Dit is helaas iets dat onopgelost blijft dat multi-master replicatie zou moeten oplossen, maar multi-master replicatie voegt zijn eigen schip van pestratten toe aan Europa zelf en ik zou je ten zeerste aanraden om serieus onderzoek te doen voordat je nadenkt of MongoDB kan momenteel niet aan uw behoeften voldoen.
U maakt zich misschien zorgen om niets, aangezien de fsync-wachtrij is ontworpen om de IO-bottleneck aan te pakken, waardoor uw schrijfbewerkingen worden vertraagd zoals in SQL, en leesbewerkingen gelijktijdig zijn, dus als u uw schema en werkset goed plant, zou u een enorme aantal OP's.
Er is hier in feite een gekoppelde vraag van een 10gen-medewerker die heel goed te lezen is:https:/ /stackoverflow.com/a/17459488/383478 en het laat zien hoeveel doorvoer MongoDB kan bereiken onder belasting.
Het zal snel groeien met de nieuwe vergrendeling op documentniveau die al in dev-tak zit.