La nostra applicazione necessita di 5 raccolte in un db. Quando aggiungiamo clienti alla nostra applicazione, vorremmo mantenere db separati per ogni cliente. Ad esempio, se abbiamo 500 clienti, avremmo 500 db e 2500 raccolte (ogni db ha 5 raccolte). In questo modo possiamo separare i dati di ogni cliente.
Questa è una grande idea. Oltre alla separazione logica che ciò ti fornirà, sarai anche in grado di utilizzare la sicurezza a livello di database in MongoDB per prevenire l'accesso involontario ai dati di altri clienti.
La mia preoccupazione è:porterà a problemi di prestazioni?
No, e in effetti aiuterà poiché con il blocco a livello di database una contesa di blocco estremamente pesante per un cliente (se possibile nel tuo scenario) non influirebbe sulle prestazioni di un altro cliente (potrebbe comunque se sono in competizione per la stessa larghezza di banda di I/O ma se usi l'opzione --directoryperdb, hai la possibilità di posizionare quei DB su dispositivi fisici separati.
Lo sharding consentirà anche un facile ridimensionamento poiché non dovrai nemmeno partizionare alcuna raccolta:puoi semplicemente eseguire il round robin dei database su più shard per consentire la distribuzione del carico su cluster separati (se e quando raggiungi quel livello).
Contrariamente a quanto affermato nell'altra risposta, il thread TTLMonitor NON estrae i documenti nella RAM a meno che non vengano eliminati (e aggiunti all'elenco gratuito). Funzionano con gli indici TTL sia per sapere se dei documenti devono essere scaduti sia per localizzare direttamente il documento.
Consiglio vivamente la soluzione di un database con molte raccolte in quanto non consente né di partizionare il carico, né di fornire sicurezza, né è più facile da gestire sul lato dell'applicazione.
