Non è una risposta facile perché molto dipende dall'architettura dell'app, dall'utilizzo e dai modelli di query, dalla distribuzione tra i client (ad esempio:i livelli di utilizzo saranno più o meno gli stessi tra i client o potresti avere il 10% dei client che utilizza il 90% del risorse), quanto puoi spendere per il codice rispetto alla gestione delle operazioni e tutta una serie di altri problemi. Ecco alcune cose da considerare:
1) avere un database renderà più semplice la gestione delle operazioni, richiederà meno risorse di elaborazione e potrebbe consentirti di aumentare la scalabilità orizzontale, ma la codifica del livello di accesso sarà più difficile e dovrai davvero progettare bene il tuo livello di sicurezza per ovvi motivi. Inoltre consumerai meno risorse sul lato client/server web poiché ci saranno molte meno connessioni.
Esistono due opzioni di schema popolari quando ci si avvicina a un database monolitico:
- Puoi inserire tutti i dati simili in un'unica raccolta (ad esempio:i profili per tutti gli account vanno nella stessa raccolta) e assegnare a ciascun documento una chiave clientid per identificare quali dati appartengono a quale account. Ciò potrebbe fornire le migliori opzioni (a seconda dell'architettura dello schema) per la scalabilità orizzontale con il minor numero di risorse di elaborazione.
- Un'altra opzione consiste nel separare i dati dei clienti in base alle raccolte:ogni cliente avrà le proprie raccolte all'interno del database identificate con un prefisso clientid (es:clientid_userprofiles).
2) l'opzione database per client ti darà più problemi di gestione delle operazioni e costerà di più poiché avrai bisogno di più risorse di calcolo. D'altra parte, i tuoi costi di codifica dovrebbero essere inferiori poiché il codice sarà più facile da scrivere. Ti consentirà inoltre di distribuire meglio le tue risorse tra utenti pesanti e leggeri. Ad esempio, puoi spostare i client a uso intensivo su macchine più potenti e fornire lo sharding in base al cliente.
3) potresti fornire una combinazione delle due opzioni:database dedicati per utenti di fascia alta (account che pagano di più) e quindi un database condiviso con dati separati dalla raccolta per clienti di fascia bassa e account test/freemium.
Nota che se segui il percorso di molti database, dovresti esaminare l'opzione di avvio --smallfiles. Questo ti aiuterà con le situazioni in cui molte persone impostano "account di prova" ma che non fanno molto con loro.
Ad ogni modo, si spera che quanto sopra ti dia spunti di riflessione. Effettua una ricerca su https://groups.google.com /forum/?fromgroups#!searchin/mongodb-user/multitenant poiché ci sono state numerose discussioni nei forum Mongo su questo problema specifico.
Per quanto riguarda le implicazioni dell'audit, dipende dal livello di conformità dell'audit a cui è necessario attenersi. Se ti aspetti clienti Fortune 1000, i tuoi requisiti di conformità saranno molto più elevati (e molto più costosi - pensa da $ 10 a $ 100 di migliaia di dollari), che se i tuoi clienti fossero startup che potrebbero non aver mai sentito parlare di SAS70, ecc. La risposta dipende anche dal tipo di dati che stai archiviando:si tratta di dati finanziari degli utenti o sono solo forum di utenti? Fondamentalmente, se ci sono dubbi sulla necessità di superare gli audit di sicurezza per le grandi aziende in futuro, non pensare nemmeno all'approccio del database condiviso.
