Qual è l'approccio consigliato verso i database multi-tenant in MongoDB?

Sto pensando di creare un'app multi-tenant utilizzando MongoDB. Non ho idea di quanti inquilini avrei ancora, ma vorrei essere in grado di scalare fino a migliaia.

Posso pensare a tre strategie:

1. Tutti i tenant nella stessa raccolta, utilizzando i campi specifici del tenant per la sicurezza
2. 1 raccolta per tenant in un unico DB condiviso
3. 1 database per tenant

La voce nella mia testa mi suggerisce di scegliere l'opzione 2.

Pensieri e implicazioni, chiunque?

Ho lo stesso problema da risolvere e anche considerando le varianti. Dato che ho anni di esperienza nella creazione di applicazioni multi-tenant SaaS, avrei selezionato anche 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 (molto indietro aggiunto 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 a quanto ho capito non è particolarmente specifica per mongodb. La mia impressione è che questo sia applicabile per la maggior parte dei db 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 per i documenti, sono inutili per applicare una buona separazione dei tenant. Non sono riuscito a trovare un database NoSQL in grado di applicare restrizioni di sicurezza in base alle raccolte.

Ovviamente puoi usare 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 abbastanza tempo e risorse per affrontare la complessità della progettazione, implementazione e test di questo scenario.
• Se non si avranno molte differenze nella struttura e funzionalità nel database per diversi tenant.
• La progettazione dell'applicazione consentirà ai tenant di effettuare solo personalizzazioni minime in fase di esecuzione.
• Se desideri ottimizzare lo spazio e ridurre al minimo l'utilizzo delle risorse hardware.
• Se hai migliaia di inquilini.
• Se vuoi scalare rapidamente e a un buon costo.
• 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.

Preferirei la variante 3 se:

• Avrai un piccolo elenco di inquilini (diverse centinaia).
• Le specifiche del business richiedono di essere in grado di supportare grandi differenze nella struttura del database per 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 ti viene richiesto di conservare versioni / backup dei dati per tenant. Anche il ripristino sarà facile.
• Esistono restrizioni legali / normative che obbligano a mantenere tenant diversi in database diversi (anche data center).
• Se desideri utilizzare appieno le funzionalità di sicurezza predefinite di mongodb come i ruoli.
• Ci sono grandi differenze in materia di dimensioni tra gli inquilini (ci sono molti piccoli inquilini e pochi inquilini molto grandi).

Se pubblichi ulteriori dettagli sulla tua domanda, forse posso darti consigli più dettagliati.

Ho trovato una buona risposta nei commenti a questo link:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Fondamentalmente l'opzione n. 2 sembra essere il modo migliore per andare.

Citazione dal commento di David Mytton:

Abbiamo deciso di non avere un database per cliente a causa del modo in cui MongoDB alloca i suoi file di dati. Ogni database utilizza il proprio set di file:

Il primo file per un database è dbname.0, quindi dbname.1, ecc. Dbname.0 sarà 64 MB, dbname.1 128 MB, ecc., Fino a 2 GB. Una volta che i file raggiungono le dimensioni di 2 GB, anche ogni file successivo è di 2 GB.

Pertanto, se l'ultimo file di dati presente è, ad esempio, 1 GB, quel file potrebbe essere vuoto al 90% se è stato raggiunto di recente.

dal manuale.

Man mano che gli utenti si iscrivono alla versione di prova e provano, avremmo sempre più database con dimensioni di almeno 2 GB, anche se l'intero file di dati non veniva utilizzato. Abbiamo riscontrato che questo utilizzava un'enorme quantità di spazio su disco rispetto ad avere diversi database per tutti i clienti in cui lo spazio su disco può essere utilizzato con la massima efficienza.

Lo sharding sarà in base alla raccolta come standard, il che presenta un problema in cui la raccolta non raggiunge mai la dimensione minima per iniziare lo sharding, come nel caso di alcuni dei nostri (ad esempio le raccolte che memorizzano i dettagli di accesso dell'utente). Tuttavia, abbiamo richiesto che ciò possa essere fatto anche a livello di database. Vedi http://jira.mongodb.org/browse/SHARDING-41

Non ci sono compromessi sulle prestazioni utilizzando molte raccolte. Vedi http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

C'è un articolo ragionevole su MSDN sull'architettura dei dati multi-tenant a cui potresti fare riferimento. Alcuni argomenti chiave toccati da questo articolo:

• Considerazioni economiche
• Sicurezza
• Considerazioni sul tenant
• Regolamentazione (legale)
• Abilità impostate preoccupazioni

Vengono anche toccati alcuni modelli per la configurazione SaaS (Software as a Service).

Inoltre, vale la pena dare un'occhiata a un interessante articolo dei ragazzi di SQL Anywhere .

La mia opinione personale: a meno che tu non sia certo della sicurezza / fiducia applicata, sceglierei l'opzione 3 o se i problemi di scalabilità vietano il fallback all'opzione 2 come minimo. Detto questo ... non sono un professionista con MongoDB. Divento piuttosto nervoso usando uno "schema" condiviso, ma rimanderò felicemente a praticanti più esperti.

Preferirei l'opzione 2.

Tuttavia è possibile impostare l'opzione della riga di comando di mongod.exe --smallfiles. Ciò significa che la dimensione massima del file di un extent sarà 0,5 gigabyte e non 2 gigabyte. L'ho provato con mongo 1.42. Quindi l'opzione 3 non è impossibile.

Secondo la mia ricerca in MongoDB. Trucos y consejos. Aplicaciones multitenant. questa opzione è sconsigliata se non sai quanti inquilini puoi avere, potrebbero essere migliaia e sarebbe complicato quando si tratta di sharding, immagina anche di avere migliaia di raccolte in un unico database ... Quindi nel tuo caso è si consiglia di utilizzare l'opzione uno. Ora, se hai un numero limitato di utenti, è già diverso e sì, potresti usare l'opzione due come pensavi.

Mentre la discussione qui è su NoSQL e principalmente su MongoDB, noi di Citus stiamo usando PostgreSQL e costruendo un database multi-tenant distribuito / frammentato.

La nostra guida ai casi d'uso illustra un'app di esempio, coprendo lo schema e varie funzionalità specifiche del multi-tenant.

Per dati più non strutturati, utilizziamo la colonna JSONB di PostgreSQL per archiviare tali dati e dati specifici del tenant.