I DB multi-tenant hanno più database o tabelle condivise?

È un database multi-tenant:

Un server DB che ha un database / schema diverso (identico) per ciascun cliente / tenant ?; o
Un server DB con un database / schema in cui i clienti / i tenant condividono i record all'interno delle stesse tabelle?

Ad esempio, sotto l'opzione n. 1 sopra, potrei avere un server MySQL, per esempio mydb01.example.com, e potrebbe avere un customer1database al suo interno. Questo customer1database potrebbe contenere, diciamo, 10 tabelle che alimentano la mia applicazione per quel particolare cliente (Cliente n. 1). Potrebbe anche contenere un customer2database con le stesse 10 tabelle esatte, ma contenente solo dati per il cliente n. 2. Potrebbe avere un customer3database, un customer4database e così via.

Nell'opzione n. 2 sopra, ci sarebbe solo un singolo database / schema, diciamo myapp_db, di nuovo con 10 tabelle (stesse come sopra). Ma qui, i dati per tutti i clienti esistono all'interno di quelle 10 tabelle e quindi "condividono" le tabelle. E a livello di applicazione, controllo logico e di sicurezza a cui i clienti hanno accesso a quali record in quelle 10 tabelle e grande attenzione è rivolta a garantire che il Cliente n. 1 non acceda mai all'app e visualizzi i dati del Cliente n. 3, ecc.

Quale di questi paradigmi costituisce un DB "multi-tenant" tradizionale? E se nessuno dei due, allora qualcuno può fornirmi un esempio (usando gli scenari sopra descritti) di cosa sia un DB multi-tenant?

database-design multitenancy

— smeeb
fonte

"multi-tenant" implica una forte sicurezza - implementata da qualche parte - in modo che un tenant non possa vedere i dati degli altri, non possa modificarli, non possa negarne l'accesso, ecc. Tale sicurezza deve essere implementata in qualche modo. Le opzioni n. 1 e n. 2 del PO funzionano entrambe, ma l'analisi della sicurezza e il lavoro necessari per implementare la sicurezza sono diversi. Per quello che vale, ho lavorato in una startup che implementava la multi-tenancy tramite l'opzione n. 2 in cui le tabelle - con righe appartenenti a più tenant - erano nascoste (tramite autorizzazioni) da tutti gli utenti finali e la sicurezza era implementata interamente nelle procedure memorizzate.

— davidbak,

Possibile duplicato di multi-tenancy - database singolo vs database multiplo

— JeffO

Se questo finisce per essere chiuso come duplicato, penso che dovremmo contrassegnarlo per unirlo al target dupe perché entrambe le domande hanno delle risposte davvero buone.

Risposte:

Quale di questi paradigmi costituisce un DB "multi-tenant" tradizionale

Entrambi i concetti sono chiamati multi-tenancy, poiché è solo un concetto logico "in cui una singola istanza di software viene eseguita su un server e serve più tenant" (da Wikipedia ). Ma come implementare questo concetto "fisicamente" dipende da te.

Naturalmente, l'applicazione necessita di un concetto di database che consenta di separare i dati di diversi tenant e l'idea di multi-tenancy è quella di condividere alcune risorse del server (almeno l'hardware) per un migliore utilizzo delle risorse e un'amministrazione più semplice. Quindi un "DB multi-tenant" è uno che supporta direttamente questo , dove parti del modello db o tabelle sono condivise.

Per essere precisi, è possibile creare un'applicazione multi-tenant con un DB non multi-tenant, fornendo un'istanza DB individuale per client. Tuttavia, ciò preclude la condivisione di qualsiasi risorsa DB direttamente tra i tenant e il livello dell'applicazione deve assicurarsi di collegare il tenant giusto al database giusto.

— Doc Brown
fonte

Grazie @Doc Brown (+1) ma poi, come hai potuto avere un database che non fosse multi-tenant?!?

— Smeeb

@smeeb: multi-tenancy è una proprietà dell'applicazione utilizzata da diversi tenant, non del database "dietro" all'applicazione. Naturalmente, il concetto di db deve supportare il multi-tenancy per renderlo possibile.

— Doc Brown,

@smeeb: supponiamo di avere una tabella utente con il vincolo che il nome utente sia univoco, ora un dipendente di un inquilino non può più utilizzare un nome utente solo perché un altro che lavora in un altro inquilino lo sta già utilizzando.

— RemcoGerlich,

@smeeb: se l'unico modo di servire due tenant è installare ed eseguire un'applicazione due volte, su due server diversi, con due database separati, penso che uno non chiamerebbe questo multi-tenancy.

— Doc Brown,

Sono andato a una presentazione su Azure qualche tempo fa che diceva che MYOB esegue la propria soluzione cloud su Azure e ogni tenant ottiene il proprio DB (e presumibilmente anche i server Web); hanno solo alcuni ottimi strumenti di automazione per gestire le centinaia di istanze DB che devono richiedere. D'altra parte, l'organizzazione per la quale lavoro attualmente gestisce centinaia di clienti da un unico database, c'è solo un bel po 'di lavoro svolto nel software per imporre l'isolamento dei dati dei clienti. Abbiamo anche considerato un ibrido, in cui i nostri clienti più grandi avrebbero ottenuto il proprio DB, mentre altri condividevano l'originale.

— David Keaveny l'

Secondo Microsoft, il termine ha 3 significati potenziali (un database per tutti gli inquilini o un databaser per inquilino).

Per usare il tuo esempio, ogni cliente sarebbe il proprio inquilino.

Un database per inquilino (cliente)
- Ogni inquilino è isolato dagli altri (nessun accesso accidentale ai dati degli altri inquilini)
- L'isolamento semplifica inoltre la gestione del ripristino dei dati e l'adattamento delle esigenze di archiviazione in base alle esigenze degli inquilini.
Un database condiviso, schema separato.
- Ogni inquilino ha il proprio schema e i loro dati sono nelle proprie tabelle.
- Il ripristino può richiedere più tempo, poiché tutti si trovano nello stesso database, non è possibile ripristinare il database su un backup precedente (ripristinerebbe i dati di ogni tenant). Un'opzione è ripristinare in un nuovo database e quindi unire / copiare solo i dati dei 1 tenant.
Un database condiviso, schema condiviso.
- I dati di ogni inquilino sono nelle stesse tabelle. Se, ad esempio, segui gli ordini, tutti gli ordini degli inquilini si troverebbero in "dbo.Orders".
- I dati degli inquilini sono separati da una colonna in ogni tabella (potrebbe essere TenantId), che mostra il proprietario della riga.

Ci sono pro e contro per ciascuno, ben spiegato in questo articolo: https://msdn.microsoft.com/en-us/library/aa479086.aspx

Bonus: puoi pensarlo come un alloggio (grossolanamente semplificato).

Ogni inquilino ha la sua casa. Possono fare quello che vogliono e, se si brucia, non ha alcun effetto su nessun altro.
Ogni inquilino si trova nello stesso edificio, ma ha il proprio appartamento.
Tutti vivono nello stesso appartamento e tutte le cose sono contrassegnate con una nota adesiva per mostrare chi lo possiede.

— lmms90
fonte

La ringrazio per la risposta. Potresti per favore elaborare un po 'la tua risposta. Ciò creerebbe una risposta migliore.

— Thomas Junk,

il tuo esempio di bonus è fantastico @ imms90

— Aravin,

Microsoft ha abbandonato la pagina collegata da MSDN. La macchina del ritorno ha ancora una copia.

— Mike Sherrill 'Cat Recall',

Articolo simile da MS (forse lo stesso che si è spostato): docs.microsoft.com/en-us/azure/sql-database/…

— Pierre Henry,