Unsere Anwendung benötigt 5 Sammlungen in einer Datenbank. Wenn wir Clients zu unserer Anwendung hinzufügen, möchten wir für jeden Kunden eine separate Datenbank verwalten. Wenn wir beispielsweise 500 Kunden haben, hätten wir 500 Datenbanken und 2500 Sammlungen (jede Datenbank hat 5 Sammlungen). Auf diese Weise können wir die einzelnen Kundendaten trennen.
Das ist eine großartige Idee. Zusätzlich zu der logischen Trennung, die Ihnen dies bietet, können Sie auch die Sicherheit auf Datenbankebene in MongoDB verwenden, um einen unbeabsichtigten Zugriff auf die Daten anderer Kunden zu verhindern.
Meine Sorge ist, wird dies zu Leistungsproblemen führen?
Nein, und in der Tat wird es hilfreich sein, da bei einer Sperre auf Datenbankebene ein extrem starker Sperrkonflikt für einen Kunden (falls dies in Ihrem Szenario möglich ist) die Leistung für einen anderen Kunden nicht beeinträchtigen würde (es könnte immer noch der Fall sein, wenn sie um die gleiche E/A-Bandbreite konkurrieren). aber wenn Sie die Option --directoryperdb verwenden, haben Sie die Möglichkeit, diese DBs auf separaten physischen Geräten zu platzieren.
Das Sharding ermöglicht auch eine einfache Skalierung, da Sie nicht einmal Sammlungen partitionieren müssen – Sie können einfach Datenbanken über mehrere Shards verteilen, damit die Last auf separate Cluster verteilt werden kann (falls und sobald Sie dieses Niveau erreichen). P>
Entgegen der Behauptung in der anderen Antwort zieht der TTLMonitor-Thread KEINE Dokumente in den Arbeitsspeicher, es sei denn, sie werden gelöscht (und zur freien Liste hinzugefügt). Sie arbeiten mit TTL-Indizes, um festzustellen, ob Dokumente abgelaufen sind, und um das Dokument direkt zu lokalisieren.
Ich würde dringend gegen die Lösung mit einer Datenbank und vielen Sammlungen raten, da Sie damit weder die Last partitionieren noch Sicherheit bieten können, noch auf der Anwendungsseite einfacher zu handhaben ist.
