Inte ett lätt svar eftersom mycket beror på din apparkitektur, användning och frågemönster, fördelningen mellan klienter (dvs:kommer användningsnivåerna att vara ungefär desamma mellan klienterna, eller kan du låta 10 % av klienterna använda 90 % av resurser), hur mycket du kan spendera på kod vs ops-hantering och en mängd andra problem. Här är några saker att tänka på:
1) att ha en databas kommer att göra din operationshantering enklare, kräver mindre datorresurser och kan göra det möjligt för dig att skala ut bättre, men kodning av åtkomstlagret blir svårare och du måste verkligen utforma ditt säkerhetslager väl av uppenbara skäl. Du kommer också att förbruka mindre resurser på klient-/webserveränden eftersom det blir många färre anslutningar.
Det finns två populära schemaalternativ när man närmar sig en monolitisk databas:
- Du kan lägga alla liknande data i en samling (dvs. profiler för alla konton går in i samma samling) och ge varje dokument en klient-id-nyckel för att identifiera vilken data som hör till vilket konto. Detta kan ge dig de bästa alternativen (beroende på din schemaarkitektur) för att skala ut med minsta möjliga datorresurser.
- Ett annat alternativ är att separera klientdata efter samlingar - varje klient kommer att ha sina egna samlingar i databasen identifierade med ett klientid-prefix (dvs. klientid_användarprofiler).
2) alternativet för databas per klient kommer att ge dig mer operationshanteringshuvudvärk och kosta mer eftersom du kommer att behöva fler mer datorresurser. Å andra sidan bör dina kodningskostnader vara mindre eftersom koden blir lättare att skriva. Det kommer också att tillåta dig att bättre fördela dina resurser mellan tunga och lätta användare. Du kan till exempel flytta klienter med hög användning till mer kraftfulla maskiner och tillhandahålla sönderdelning per kund.
3) du kan tillhandahålla en kombination av de två alternativen - dedikerade databaser för avancerade användare (konton som betalar mer), och sedan en delad databas med data separerade genom insamling för low-end-kunder och test-/freemium-konton.
Observera att om du går den många databasvägen, bör du titta på --smallfiles startalternativ. Detta kommer att hjälpa dig i situationer där du har många människor som konfigurerar "testkonton" men som inte gör så mycket med dem.
Hur som helst, förhoppningsvis ger ovanstående tankeställare. Gör en sökning på https://groups.google.com /forum/?fromgroups#!searchin/mongodb-user/multitenant eftersom det har förekommit ett antal diskussioner i Mongo-forumen om denna specifika fråga.
När det gäller revisionskonsekvenserna, beror på vilken nivå av revisionsefterlevnad du måste följa. Om du förväntar dig Fortune 1000-kunder kommer dina efterlevnadskrav att vara mycket högre (och mycket dyrare - tänk $10s till $100s av tusentals dollar), än om dina kunder är startups som kanske aldrig har hört talas om SAS70, etc. Svaret beror också på vilken typ av data du lagrar – är det användarekonomisk data, eller är det bara användarforum? I grund och botten, om det finns några farhågor om att behöva klara säkerhetsrevisioner för stora företag i framtiden, tänk inte ens på den delade databasmetoden.