Ако MongoDB има ахилесова пета, това е фактът, че поддържа само еднонишкови записи и еднонишкови map-reduces.
Както винаги, тук има компромиси. Записите с една нишка са най-лесният начин за избягване на проблеми със заключването и минимизиране на режийните разходи. По същия начин многонишковите map-reduces са чудесен начин да заключите вашите данни. Така че еднонишковите карт-редукции в производствена система вероятно са по-лесни и по-безопасни.
Тук обаче не сте без инструменти. MongoDB ще предостави една нишка за запис на всеки екземпляр. Така че, ако разделите MongoDB, тогава ще получите една нишка за запис за всеки шард.
Ако искате множество индекси на 2 милиарда реда, все пак ще искате да разгледате шардинга. Малко бърза математика тук:MongoID е 12 байта. Индексът на MongoID ще бъде 2B * 12 байта =22GB+. Ако сега искате да добавите още два индекса (дори само две 4-байтови цели числа), говорим за 7,5 GB за всеки.
Така че при 2B редове, вие говорите, че имате над 37GB в индекси (минимум ). На повечето 8-ядрени сървъри това означава, че дори няма да можете да запазите индексите си в паметта, камо ли каквито и да било данни.
Така че, ако искате сериозна производителност тук, ще искате да започнете да разглеждате шардинга. Само въз основа на общите числа. FWIW, MySQL не би бил по-умел в обработката на 2B документи. С толкова много данни наистина ще искате множество сървъри, за да поддържате натоварването.
