Zdaleka to nebude úplná odpověď, je tam příliš mnoho podrobností a mohl bych o této otázce napsat celou esej stejně jako mnoho dalších, ale protože nemám tolik času nazbyt, přidám komentář o tom, co vidím.
Sady replik nejsou navrženy tak, aby fungovaly. Pokud chcete načíst zůstatek, možná ve skutečnosti hledáte sharding, který vám to umožní.
Replikace je pro automatické převzetí služeb při selhání.
Vzhledem k tomu, že vaši členové budou dostávat aktuální informace, budou mít stejný počet operací jako primární, zdá se, že to nemusí příliš pomoci.
Ve skutečnosti místo toho, abyste měli jeden server s mnoha připojeními ve frontě, máte mnoho připojení na mnoha serverech ve frontě na zastaralá data, protože konzistence členů je případná, nikoli okamžitá na rozdíl od technologií ACID, nicméně jak bylo řečeno, jsou nakonec konzistentní pouze o 32 lichých ms, což znamená, že nejsou dostatečně zpožděny, aby poskytovaly slušnou propustnost, pokud je načten primární.
Vzhledem k tomu, že čtení JSOU souběžné, získáte stejnou rychlost, ať čtete z primárního nebo sekundárního zdroje. Předpokládám, že byste mohli zpozdit otroka, aby vytvořil pauzu OP, ale to by na oplátku přineslo zpět masivně zastaralá data.
Nemluvě o tom, že MongoDB není multimaster, jako takový můžete zapisovat pouze do jednoho uzlu, takže slaveOK již není nejužitečnějším nastavením na světě a mnohokrát jsem viděl, že 10gen sami doporučují použít sharding přes toto nastavení.
To by vyžadovalo vlastní kódování. V tomto okamžiku možná budete chtít zvážit použití databáze, která podporuje http://en.wikipedia .org/wiki/Multi-master_replication
Je to proto, že rychlost, kterou hledáte, je s největší pravděpodobností ve skutečnosti ve skutečnosti v zápisech, nikoli čteních, jak jsem popsal výše.
Toto je doporučený způsob, ale našli jste u něj varování. Toto je bohužel něco, co zůstává nevyřešeno a co má vyřešit replikace s více mastery, nicméně replikace s více mastery přidává do samotné Evropy vlastní loď morových krys a důrazně bych vám doporučil udělat seriózní průzkum, než budete přemýšlet, zda MongoDB aktuálně nemůže obsloužit vaše potřeby.
Možná se nemusíte ničeho obávat, protože fronta fsync je navržena tak, aby se vypořádala s IO úzkým hrdlem, které zpomaluje vaše zápisy, jako by tomu bylo v SQL, a čtení probíhá souběžně, takže pokud naplánujete své schéma a pracovní sadu správně, měli byste být schopni získat masivní množství OP.
Ve skutečnosti je zde propojená otázka od zaměstnance 10gen, kterou je velmi dobré si přečíst:https:/ /stackoverflow.com/a/17459488/383478 a ukazuje, jak velké propustnosti může MongoDB dosáhnout při zatížení.
Brzy se rozroste s novým zamykáním na úrovni dokumentů, které je již ve vývojové větvi.