Ho lo stesso problema da risolvere e considerando anche le varianti. Poiché ho anni di esperienza nella creazione di applicazioni SaaS multi-tenant, avrei anche selezionato la seconda opzione in base alla mia precedente esperienza con i database relazionali.
Durante le mie ricerche ho trovato questo articolo sul sito di supporto di mongodb (aggiunto molto tempo fa da quando è scomparso):https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html
I ragazzi hanno dichiarato di evitare la seconda opzione ad ogni costo, che da quanto ho capito non è particolarmente specifica per mongodb. La mia impressione è che questo sia applicabile per la maggior parte dei dbs NoSQL che ho ricercato (CoachDB, Cassandra, CouchBase Server, ecc.) A causa delle specifiche del design del database.
Le raccolte (o bucket o comunque lo chiamano in DB diversi) non sono la stessa cosa degli schemi di sicurezza in RDBMS nonostante si comportino come contenitori di documenti sono inutili per applicare una buona separazione dei tenant. Non sono riuscito a trovare database NoSQL in grado di applicare restrizioni di sicurezza in base alle raccolte.
Naturalmente è possibile utilizzare la sicurezza basata sui ruoli mongodb per limitare l'accesso a livello di database/server. (http://docs.mongodb.org/manual/core/authorization/)
Consiglierei la prima opzione quando:
- Hai tempo e risorse sufficienti per affrontare la complessità della progettazione, implementazione e test di questo scenario.
- Se non hai molte differenze nella struttura e nella funzionalità nel database per i diversi inquilini.
- La progettazione dell'applicazione consentirà ai tenant di effettuare solo personalizzazioni minime in fase di esecuzione.
- Se vuoi ottimizzare lo spazio e ridurre al minimo l'utilizzo delle risorse hardware.
- Se hai migliaia di inquilini.
- Se vuoi scalare velocemente e a buon prezzo.
- Se NON si intende eseguire il backup dei dati in base ai tenant (mantenere backup separati per ciascun tenant). È possibile farlo anche in questo scenario, ma lo sforzo sarà enorme.
Sceglierei la variante 3 se:
- Avrai un piccolo elenco di inquilini (diverse centinaia).
- Le specifiche del business richiedono che tu sia in grado di supportare grandi differenze nella struttura del database per i diversi tenant (ad es. integrazione con sistemi di terze parti, import-export di dati).
- La progettazione dell'applicazione consentirà ai clienti (tenant) di apportare modifiche significative al runtime dell'applicazione (aggiunta di moduli, personalizzazione dei campi, ecc.).
- Se disponi di risorse sufficienti per scalare rapidamente con nuovi nodi hardware.
- Se è necessario mantenere versioni/backup dei dati per tenant. Anche il ripristino sarà facile.
- Esistono restrizioni legali/normative che ti obbligano a mantenere inquilini diversi in database diversi (anche data center).
- Se desideri utilizzare appieno le funzionalità di sicurezza pronte all'uso di mongodb come i ruoli.
- Ci sono grandi differenze in termini di dimensioni tra gli inquilini (hai molti piccoli inquilini e pochi molto grandi).
Se pubblichi ulteriori dettagli sulla tua domanda, forse posso darti consigli più dettagliati.
