Vår applikation behöver 5 samlingar i en db. När vi lägger till klienter till vår applikation vill vi behålla separata db för varje kund. Till exempel, om vi har 500 kunder, skulle vi ha 500 dbs och 2500 samlingar (varje db har 5 samlingar). På så sätt kan vi separera varje kunddata.
Det är en bra idé. Utöver logisk separation som detta ger dig, kommer du också att kunna använda databasnivåsäkerhet i MongoDB för att förhindra oavsiktlig åtkomst till andra kunders data.
Min oro är, kommer det att leda till prestationsproblem?
Nej, och i själva verket kommer det att hjälpa eftersom med databasnivålås extremt tunga låsstridigheter för en kund (om det är möjligt i ditt scenario) inte skulle påverka prestanda för en annan kund (det kanske fortfarande kan om de konkurrerar om samma I/O-bandbredd men om du använder alternativet --directoryperdb så har du möjlighet att placera dessa DB:er på separata fysiska enheter.
Sharding tillåter också enkel skalning eftersom du inte ens behöver partitionera några samlingar - du kan bara round-robin-databaser över flera skärvor för att tillåta att belastningen distribueras till separata kluster (om och när du når den nivån).
Tvärtemot påståendet i det andra svaret drar TTLMonitor-tråden INTE dokument till RAM-minnet om de inte raderas (och läggs till i gratislistan). De arbetar utifrån TTL-index både för att avgöra om några dokument ska upphöra att gälla och för att hitta dokumentet direkt.
Jag skulle starkt rekommendera lösningen för en databas med många samlingar eftersom det inte tillåter dig att vare sig partitionera belastningen eller tillhandahålla säkerhet, och det är inte heller lättare att hantera på applikationssidan.