Това далеч няма да е пълен отговор, има твърде много подробности и бих могъл да напиша цяло есе по този въпрос, както и много други, но тъй като нямам толкова свободно време, ще добавя малко коментар за това, което виждам.
Комплектите реплики не са проектирани да работят по този начин. Ако искате да балансирате натоварването, може всъщност да търсите шардинг, който ще ви позволи да направите това.
Репликацията е за автоматично преминаване при срив.
Тъй като, за да бъдат в крак с новостите, вашите членове ще получават точно толкова операции, колкото и основните, изглежда, че това може да не помогне много.
В действителност вместо да имате един сървър с много връзки на опашка, вие имате много връзки на много сървъри на опашка за остарели данни, тъй като съгласуваността на членовете е евентуална, а не незабавна, за разлика от ACID технологиите, като се казва, че те са само в крайна сметка съгласувани с 32 странни ms, което означава, че не изостават достатъчно, за да осигурят прилична производителност, ако основният е зареден.
Тъй като четенията СА едновременни, вие ще получите една и съща скорост, независимо дали четете от основния или вторичния. Предполагам, че бихте могли да забавите подчинено устройство, за да създадете пауза на OP, но това ще върне масово остарели данни в замяна.
Да не говорим, че MongoDB не е multi-master като такъв, можете да пишете само на един възел наведнъж, което прави slaveOK вече не най-полезната настройка в света и съм виждал много пъти, когато самите 10gen препоръчват да използвате шардинг над тази настройка.
Това ще изисква собствено кодиране. В този момент можете да обмислите действително използване на база данни, която поддържа http://en.wikipedia .org/wiki/Multi-master_replication
Това е така, тъй като скоростта, която търсите, най-вероятно всъщност е при писане, а не при четене, както споменах по-горе.
Това е препоръчителният начин, но сте открили предупреждението с него. За съжаление това е нещо, което остава неразрешено и което се предполага, че репликацията с множество главни компетенции трябва да разреши, но репликацията с много основни компютри наистина добавя свой собствен кораб от чумни плъхове в самата Европа и аз силно бих ви препоръчал да направите сериозно проучване, преди да мислите дали В момента MongoDB не може да обслужва вашите нужди.
Може да не се тревожите за нищо наистина, тъй като опашката fsync е проектирана да се справя с пречките на IO, забавяйки вашите записи, както би било в SQL, а четенията са едновременно, така че ако планирате схемата и работния си набор правилно, трябва да можете да получите огромен количество ОП.
Всъщност тук има свързан въпрос от служител на 10gen, който е много добре да се прочете:https:/ /stackoverflow.com/a/17459488/383478 и показва каква производителност може да постигне MongoDB при натоварване.
Скоро ще нарасне с новото заключване на ниво документ, което вече е в клона за разработка.
