Notre application a besoin de 5 collections dans une base de données. Lorsque nous ajoutons des clients à notre application, nous souhaitons conserver une base de données distincte pour chaque client. Par exemple, si nous avons 500 clients, nous aurions 500 db et 2500 collections (chaque db a 5 collections). De cette façon, nous pouvons séparer chaque donnée client.
C'est une bonne idée. En plus de la séparation logique que cela vous fournira, vous pourrez également utiliser la sécurité au niveau de la base de données dans MongoDB pour empêcher l'accès par inadvertance aux données d'autres clients.
Ma préoccupation est la suivante :cela entraînera-t-il des problèmes de performances ?
Non, et en fait, cela aidera car avec le verrouillage au niveau de la base de données, une contention de verrouillage extrêmement lourde pour un client (si cela est possible dans votre scénario) n'affectera pas les performances d'un autre client (cela pourrait toujours s'ils sont en concurrence pour la même bande passante d'E/S mais si vous utilisez l'option --directoryperdb, vous avez la possibilité de placer ces bases de données sur des périphériques physiques distincts.
Le partitionnement permettra également une mise à l'échelle facile car vous n'aurez même pas besoin de partitionner des collections - vous pouvez simplement effectuer une rotation circulaire des bases de données sur plusieurs fragments pour permettre à la charge d'être répartie sur des clusters séparés (si et quand vous atteignez ce niveau).
Contrairement à l'affirmation dans l'autre réponse, le thread TTLMonitor ne tire PAS les documents dans la RAM à moins qu'ils ne soient supprimés (et ajoutés à la liste libre). Ils fonctionnent à partir d'index TTL à la fois pour indiquer si des documents doivent expirer et pour localiser directement le document.
Je déconseille fortement la solution de plusieurs collections de base de données, car cela ne vous permet ni de partitionner la charge, ni d'assurer la sécurité, ni d'être plus facile à gérer du côté de l'application.
