Nasza aplikacja potrzebuje 5 kolekcji w db. Kiedy dodajemy klientów do naszej aplikacji, chcielibyśmy zachować oddzielną bazę danych dla każdego klienta. Na przykład, jeśli mamy 500 klientów, mielibyśmy 500 db i 2500 kolekcji (każdy db ma 5 kolekcji). W ten sposób możemy oddzielić dane każdego klienta.
To świetny pomysł. Oprócz logicznej separacji, która zapewni Ci to, będziesz także mógł korzystać z zabezpieczeń na poziomie bazy danych w MongoDB, aby zapobiec przypadkowemu dostępowi do danych innych klientów.
Obawiam się, czy doprowadzi to do jakichkolwiek problemów z wydajnością?
Nie, i w rzeczywistości pomoże, ponieważ w przypadku blokady na poziomie bazy danych bardzo duża rywalizacja o blokadę dla jednego klienta (jeśli jest to możliwe w twoim scenariuszu) nie wpłynie na wydajność innego klienta (nadal może, jeśli konkurują o tę samą przepustowość I/O ale jeśli użyjesz opcji --directoryperdb, masz możliwość umieszczenia tych baz danych na osobnych urządzeniach fizycznych.
Dzielenie na fragmenty pozwoli również na łatwe skalowanie, ponieważ nie będziesz nawet musiał partycjonować żadnych kolekcji — możesz po prostu krążyć wokół baz danych w wielu fragmentach, aby umożliwić dystrybucję obciążenia do oddzielnych klastrów (jeśli i kiedy osiągniesz ten poziom).
W przeciwieństwie do twierdzenia w drugiej odpowiedzi, wątek TTLMonitor NIE ściąga dokumentów do pamięci RAM, chyba że są one usuwane (i dodawane do wolnej listy). Działają w oparciu o indeksy TTL, aby stwierdzić, czy jakiekolwiek dokumenty mają wygasnąć, a także bezpośrednio zlokalizować dokument.
Zdecydowanie odradzałbym korzystanie z jednej bazy danych z wieloma kolekcjami, ponieważ nie pozwala ona ani na partycjonowanie obciążenia, ani nie zapewnia bezpieczeństwa, ani nie jest łatwiejsza w obsłudze po stronie aplikacji.
