Nosso aplicativo precisa de 5 coleções em um banco de dados. Quando adicionamos clientes ao nosso aplicativo, gostaríamos de manter um banco de dados separado para cada cliente. Por exemplo, se tivéssemos 500 clientes, teríamos 500 dbs e 2500 coleções (cada db tem 5 coleções). Desta forma podemos separar os dados de cada cliente.
Essa é uma ótima ideia. Além da separação lógica que isso fornecerá, você também poderá usar a segurança no nível do banco de dados no MongoDB para ajudar a evitar o acesso inadvertido aos dados de outros clientes.
Minha preocupação é, isso levará a algum problema de desempenho?
Não, e de fato ajudará, pois com o bloqueio de nível de banco de dados a contenção de bloqueio extremamente pesada para um cliente (se isso for possível em seu cenário) não afetaria o desempenho de outro cliente (ainda poderia se eles estivessem competindo pela mesma largura de banda de E/S mas se você usar a opção --directoryperdb, poderá colocar esses bancos de dados em dispositivos físicos separados.
O sharding também permitirá dimensionamento fácil, pois você nem precisará particionar nenhuma coleção - você pode apenas fazer rodízio de bancos de dados em vários shards para permitir que a carga seja distribuída para clusters separados (se e quando você atingir esse nível).
Ao contrário da afirmação na outra resposta, o thread TTLMonitor NÃO puxa documentos para a RAM, a menos que estejam sendo excluídos (e adicionados à lista gratuita). Eles trabalham com índices TTL tanto para informar se algum documento deve expirar quanto para localizar o documento diretamente.
Eu recomendo fortemente contra a solução de um banco de dados com muitas coleções, pois isso não permite particionar a carga, nem fornecer segurança, nem é mais fácil de manusear no lado do aplicativo.
