Нашето приложение се нуждае от 5 колекции в db. Когато добавяме клиенти към нашето приложение, бихме искали да поддържаме отделна база данни за всеки клиент. Например, ако имаме 500 клиенти, ще имаме 500 dbs и 2500 колекции (всеки db има 5 колекции). По този начин можем да разделим данните за всеки клиент.
Това е чудесна идея. Освен логическото разделяне, това ще ви осигури, също така ще можете да използвате сигурността на ниво база данни в MongoDB, за да предотвратите неволен достъп до данните на други клиенти.
Притеснението ми е дали това ще доведе до проблеми с производителността?
Не, и всъщност това ще помогне, тъй като при заключването на ниво база данни изключително тежката конкуренция за заключване за един клиент (ако това е възможно във вашия сценарий) няма да повлияе на производителността на друг клиент (все пак може, ако те се конкурират за същата I/O честотна лента но ако използвате опцията --directoryperdb, тогава имате възможността да поставите тези БД на отделни физически устройства.
Разделянето също така ще позволи лесно мащабиране, тъй като дори няма да ви се налага да разделяте колекции – можете просто да обединявате бази данни в множество фрагменти, за да позволите натоварването да бъде разпределено в отделни клъстери (ако и когато достигнете това ниво).
Противно на твърдението в другия отговор, TTLMonitor нишката НЕ изтегля документи в RAM, освен ако не бъдат изтрити (и добавени към безплатния списък). Те работят с TTL индексите както за да разберат дали някой документи трябва да изтече, така и за директно намиране на документа.
Силно бих препоръчал срещу решението с една база данни с много колекции, тъй като това не ви позволява нито да разделите натоварването, нито да осигурите сигурност, нито е по-лесно да се справите от страна на приложението.
