Nuestra aplicación necesita 5 colecciones en una base de datos. Cuando agregamos clientes a nuestra aplicación, nos gustaría mantener una base de datos separada para cada cliente. Por ejemplo, si tenemos 500 clientes, tendríamos 500 dbs y 2500 colecciones (cada db tiene 5 colecciones). De esta forma podemos separar los datos de cada cliente.
Es una gran idea. Además de la separación lógica que esto le proporcionará, también podrá utilizar la seguridad a nivel de base de datos en MongoDB para ayudar a evitar el acceso involuntario a los datos de otros clientes.
Mi preocupación es, ¿dará lugar a algún problema de rendimiento?
No, y de hecho ayudará, ya que con el bloqueo de nivel de base de datos, la contención de bloqueo extremadamente pesada para un cliente (si eso es posible en su escenario) no afectaría el rendimiento de otro cliente (todavía podría hacerlo si compiten por el mismo ancho de banda de E/S pero si usa la opción --directoryperdb, entonces tiene la capacidad de colocar esas bases de datos en dispositivos físicos separados.
La fragmentación también permitirá escalar fácilmente, ya que ni siquiera tendrá que particionar ninguna colección; puede simplemente hacer un round-robin de las bases de datos en múltiples fragmentos para permitir que la carga se distribuya a clústeres separados (siempre y cuando alcance ese nivel).
Contrariamente al reclamo en la otra respuesta, el subproceso TTLMonitor NO extrae documentos a la RAM a menos que se eliminen (y se agreguen a la lista gratuita). Funcionan a partir de índices TTL tanto para saber si algún documento va a caducar como para localizar el documento directamente.
Recomiendo encarecidamente la solución de una base de datos con muchas colecciones, ya que no le permite dividir la carga, ni proporcionar seguridad, ni es más fácil de manejar en el lado de la aplicación.
