Трудно е да се каже какво е оптималното масово вмъкване - това отчасти зависи от размера на обектите, които вмъквате, и други неизмерими фактори. Можете да опитате няколко диапазона и да видите кое ви дава най-добра производителност. Като алтернатива, някои хора харесват използването на mongoimport, което е доста бързо, но вашите данни за импортиране трябва да са json или csv. Очевидно има mongodrestore, ако данните са във формат BSON.
Mongo може лесно да обработва милиарди документи и може да има милиарди документи в една колекция, но не забравяйте, че максималният размер на документа е 16mb . Има много хора с милиарди документи в MongoDB и има много дискусии за това в Потребителска група на MongoDB Google . Ето един документ върху използването на голям брой колекции, които може да искате да прочетете, ако промените решението си и вместо това искате да имате няколко колекции. Колкото повече колекции имате, толкова повече индекси също ще имате, което вероятно не е това, което искате.
Ето една презентация от Craigslist относно вмъкването на милиарди документи в MongoDB и blogpost .
Изглежда, че шардингът би бил добро решение за вас, но обикновено шардингът се използва за мащабиране в множество сървъри и много хора го правят, защото искат да мащабират записите си или не могат да запазят своя работен набор (данни и индекси) в RAM. Напълно разумно е да започнете с един сървър и след това да преминете към шард или набор от реплики, когато данните ви растат или се нуждаете от допълнително резервиране и устойчивост.
Има обаче други потребители, които използват множество mongods, за да заобиколят ограниченията за заключване на един mongod с много записи. Очевидно е, но все пак си струва да се каже, че настройката с няколко mongod е по-сложна за управление от единичен сървър. Ако вашият IO или процесор не са максимизирани тук, вашият работен набор е по-малък от RAM и вашите данни са лесни за поддържане на баланс (доста произволно разпределени), трябва да видите подобрение (с шардинг на един сървър). За информация има потенциал за спорове за памет и IO. С 2.2 с подобрена конкурентност с db заключване , подозирам, че ще има много по-малко причини за такова внедряване.
Трябва да планирате правилно преминаването си към шардинг, т.е. да обмислите внимателно избора на вашия ключ за шардинг. Ако тръгнете по този начин, най-добре е предварително да разделите и да изключите балансира. Ще бъде контрапродуктивно да премествате данни, за да поддържате нещата балансирани, което означава, че ще трябва да решите предварително как да ги разделите. Освен това понякога е важно да проектирате документите си с идеята, че някое поле ще бъде полезно за шардинг или като първичен ключ.
Ето някои добри връзки -
- Избор на ключ на Shard
- Публикация в блог за ключове на фрагменти
- Обща презентация за шардинг
- Презентация относно най-добрите практики за шардинг
