Clienti multipli; un'applicazione ospitata. Stai descrivendo un database multi-tenant.
Quando crei un database multi-tenant, devi considerare
- interrogando
- costo
- Isolamento e protezione dei dati
- manutenzione e
- Ripristino di emergenza.
Le soluzioni multi-tenant vanno da un database per tenant (condiviso nulla) a una riga per tenant (condiviso tutto).
"Niente condiviso", "database separato" o un database per tenant
- Più costoso per cliente. (Un gran numero di client implica un gran numero di server.)
- Il massimo grado di isolamento dei dati.
- Il ripristino di emergenza per un singolo tenant è semplice e diretto.
- La manutenzione è teoricamente più difficile, perché le modifiche devono essere eseguite in ogni database. Ma i tuoi dbms potrebbero facilmente supportare l'esecuzione di stored procedure in ogni database. (SQL Server ha una stored procedure di sistema non documentata, sp_msforeachdb, ad esempio. Probabilmente puoi scriverne una tua.) Anche "Shared Nothing" è la più facilmente personalizzabile, ma ciò solleva anche più problemi di manutenzione.
- Numero minimo di righe per tabella. La velocità di interrogazione è quasi ottimale.
"Tutto condiviso" o "schema condiviso" o "un database per pianeta"
- Il meno costoso per inquilino.
- Il grado più basso di isolamento dei dati. Ogni tabella ha una colonna che identifica a quale tenant appartiene una riga. Poiché le righe del tenant sono miste in ogni tabella, è relativamente semplice esporre accidentalmente i dati di un altro tenant.
- Il ripristino di emergenza per un singolo tenant è relativamente complicato; devi ripristinare singole righe in molte tabelle.
- La manutenzione strutturale è più semplice, dato che tutti gli inquilini condividono le tabelle. Aumenta il carico di comunicazione, tuttavia, perché devi comunicare e coordinare ogni modifica con ogni tenant. Non è facilmente personalizzabile.
- Numero massimo di righe per tabella. L'esecuzione di query rapide è più difficile, ma dipende da quanti tenant e quante righe. Potresti facilmente capovolgere il territorio VLDB.
Tra "niente condiviso" e "tutto condiviso" c'è "schema condiviso".
"Schema condiviso"
- I tenant condividono un database, ma ogni tenant ha il proprio schema denominato. Il costo cade tra "niente condiviso" e "tutto condiviso"; i grandi sistemi in genere richiedono meno server di "niente condiviso", più server di "tutto condiviso".
- Un isolamento molto migliore che "tutto condiviso". Non tanto isolamento quanto "niente condiviso". (Puoi CONCEDERE e REVOCARE le autorizzazioni sugli schemi.)
- Il ripristino di emergenza per un singolo tenant richiede il ripristino di uno dei tanti schemi. Questo è relativamente facile o abbastanza difficile, a seconda dei tuoi dbms.
- La manutenzione è più semplice del "niente condiviso"; non così facile come "condividere tutto". È relativamente semplice scrivere una procedura memorizzata che verrà eseguita in ogni schema in un database. È più facile condividere tabelle comuni tra tenant che con "shared nulla".
- Di solito tenant più attivi per server rispetto a "non hanno condiviso nulla", il che significa che condividono (degradano) più risorse. Ma non così male come "tutto condiviso".
Microsoft ha un buon articolo sull'architettura multi-tenant con maggiori dettagli. (Il collegamento è solo a una pagina di un documento di più pagine.)
