Dette vil langtfra være et fuldstændigt svar, der er for mange detaljer, og jeg kunne skrive et helt essay om dette spørgsmål ligesom mange andre, men da jeg ikke har den slags tid til overs, vil jeg tilføje nogle kommentarer om, hvad jeg ser.
Replika-sæt er ikke designet til at fungere sådan. Hvis du ønsker at load balance, er du måske i virkeligheden på udkig efter sharding, som vil give dig mulighed for at gøre dette.
Replikering er til automatisk failover.
Da dine medlemmer, for at holde sig opdateret, får lige så mange ops som de primære, ser det ud til, at dette måske ikke hjælper for meget.
I virkeligheden, i stedet for at have én server med mange forbindelser i kø, har du mange forbindelser på mange servere, der står i kø efter forældede data, da medlemskonsistensen er eventuel, ikke umiddelbar i modsætning til ACID-teknologier, men når det er sagt, er de kun i sidste ende konsistente med 32 ms. betyder, at de ikke halter nok til at give en anstændig gennemstrømning, hvis den primære er indlæst.
Da aflæsninger ER samtidige, vil du få samme hastighed, uanset om du læser fra den primære eller sekundære. Jeg formoder, at du kunne forsinke en slave for at skabe en pause med OP'er, men det ville bringe massivt forældede data tilbage til gengæld.
For ikke at nævne, at MongoDB ikke er multi-master, da du kun kan skrive til én node ad gangen, gør slaveOK ikke til den mest nyttige indstilling i verden længere, og jeg har set adskillige gange, hvor 10gen selv anbefaler dig at bruge sharding over denne indstilling.
Dette vil kræve din egen kodning. På hvilket tidspunkt vil du måske overveje rent faktisk at bruge en database, der understøtter http://en.wikipedia .org/wiki/Multi-master_replication
Dette skyldes, at den hastighed, du leder efter, højst sandsynligt faktisk er i skrivninger, der ikke læser, som jeg diskuterede ovenfor.
Dette er den anbefalede måde, men du har fundet forbeholdet med det. Dette er desværre noget, der forbliver uløst, som multi-master-replikation formodes at løse, men multi-master-replikering tilføjer sit eget skib af pestrotter til selve Europa, og jeg vil kraftigt anbefale dig at gøre noget seriøst research, før du tænker på, om MongoDB kan i øjeblikket ikke servicere dine behov.
Du bekymrer dig måske ikke rigtigt, da fsync-køen er designet til at håndtere IO-flaskehalsen, der bremser dine skrivninger, som den ville gøre i SQL, og læsninger er samtidige, så hvis du planlægger dit skema og arbejdssæt rigtigt, burde du være i stand til at få en massiv antal OP'er.
Der er faktisk et linket spørgsmål her omkring fra en 10gen medarbejder, som er meget godt at læse:https:/ /stackoverflow.com/a/17459488/383478 og det viser, hvor meget gennemstrømning MongoDB kan opnå under belastning.
Det vil snart vokse med den nye dokumentniveaulåsning, der allerede er i udviklergrenen.