più schemi contro enormi tavoli

Question

Si consideri un sistema di Mobile Device Manager che contiene le informazioni per ogni utente, come una tabella che memorizza le applicazioni che ha installati sul telefono, i dettagli di controllo, informazioni di notifica, ecc E 'saggio per creare uno schema separato per ogni utente con le tabelle corrispondenti? Il numero di tabelle è grande per un singolo utente pari a circa 30 tavoli ciascuno. Sarebbe meglio avere uno schema separato in cui tutte queste informazioni viene inserito in queste tabelle (a sua volta la creazione di tabelle enormi?) O di avere uno schema per ogni utente?

Grazie in anticipo

Answer 1

Voglio vedere qual è il metodo più efficiente in termini di interrogazione nel database.

In un database multi-tenant, interrogazione è solo una parte del problema. Altre parti del problema sono i costi, l'isolamento e la protezione dei dati, la manutenzione, e il disaster recovery. Questi sono significativi; si può non considerare solo l'efficienza delle query in un database multi-tenant.

Soluzioni multi-tenant variano da un database per ogni tenant (nulla in comune) di una riga per ogni tenant (tutto in comune).

"nulla in comune", "database separato", o di un database per ogni inquilino

• La maggior parte del cliente per costosi. (Un gran numero di clienti implicano un gran numero di server.)
• più alto grado di isolamento dei dati.
• Il ripristino di emergenza per un singolo inquilino è semplice e lineare.
• La manutenzione è teoricamente di più, perché le modifiche devono essere effettuate in tutti i database. Ma DBMS potrebbe facilmente sostenere l'esecuzione di stored procedure in ogni database. (SQL Server dispone di un sistema non documentato stored procedure, sp_msforeachdb, per esempio. È probabilmente può scrivere il proprio.) "Nulla in comune" è il più facilmente personalizzabile, anche, ma che solleva anche più problemi di manutenzione.
• minor numero di righe per tavolo. Interrogazione velocità è vicina ottimale.

"condiviso tutto", o "schema condiviso", o "un database per ogni pianeta"

• I meno cari per abbonato.
• più basso grado di isolamento dei dati. Ogni tabella ha una colonna che identifica che Inquilino una riga appartiene. Dal momento che le righe inquilino sono mescolati in ogni tavolo, è relativamente semplice per esporre accidentalmente i dati degli altri inquilini.
• Il ripristino di emergenza per un singolo inquilino è relativamente complicata; è necessario ripristinare singole righe in molte tabelle. D'altra parte, un disastro single-tenant è relativamente insolito. La maggior parte dei disastri probabilmente interesserà tutti gli inquilini.
manutenzione
• strutturale è più semplice, dato che tutti gli inquilini condividono le tabelle. Si aumenta il carico di comunicazione, però, perché si deve comunicare e coordinare ogni cambio ad ogni inquilino. Non è facilmente personalizzabile.
• Maggior numero di righe per tavolo. interrogazione rapida è più difficile, ma dipende da come molti inquilini e il numero di righe. Si potrebbe facilmente ribaltarsi in territorio VLDB.

Tra il "nulla condivisa" e "condiviso tutto" è "schema condiviso".

"schema condiviso"

• Gli inquilini condividere un database, ma ogni inquilino ha il proprio schema di nome. Costo cade tra "shared nothing" e "condiviso tutto"; grandi sistemi in genere bisogno di un minor numero di server di "shared nothing", più server di "condiviso tutto".
• Molto meglio di isolamento "condiviso tutto". Non abbastanza tanto l'isolamento come "niente condivisa". (È possibile concedere le autorizzazioni e REVOKE su schemi.)
• Il ripristino di emergenza per un singolo inquilino richiedono il ripristino di uno dei tanti schemi. Questo può essere relativamente facile o abbastanza difficile, a seconda delle vostre DBMS.
• La manutenzione è più facile che "nulla condivisa"; non è facile come "condiviso tutto". E 'relativamente facile scrivere una stored procedure che verrà eseguito in ogni schema in un database. E 'più facile condividere i tavoli comuni tra gli inquilini che con "nulla condivisa".
• inquilini di solito più attivi per server di quanto "shared nothing", il che significa che condividono (degrado) di più risorse. Ma non è così male come "condiviso tutto".

Microsoft ha un buon articolo su multi-tenant architettura con più dettagli. (Il link è ad una sola pagina di un documento di più pagine.)