Multi-tenancy - database singolo vs database multiplo

20

Abbiamo un numero di client, i cui sistemi condividono alcune funzionalità, ma hanno anche un certo grado di diversità. Il numero di clienti è in crescita - sempre una cosa salutare! - e anche la diversità tra le loro imprese è in aumento.

Al momento esiste un singolo sito Web ASP.Net (Web Forms) (in contrapposizione al progetto Web), che ha sottocartelle per ciascun tenant, con le pagine non standard di quel tenant. Esiste un progetto modello separato, che si occupa dell'accesso al database e della logica aziendale.

Il che è preferibile - e, soprattutto, perché - tra avere (a) 1 database per client, con solo le funzionalità associate a quel client; oppure (b) un singolo database condiviso da tutti i client, in cui solo un sottoinsieme di tabelle viene utilizzato da un singolo client.

Le principali preoccupazioni all'interno dell'azienda sono finite:

manutenzione di più risorse: backup, controllo della versione e simili
promuovere il riutilizzo il più possibile

Come assicurereste che vengano affrontate queste preoccupazioni, quale soluzione è preferibile e perché? (Ho anche compilato le risposte a domande simili)

database-design projects-and-solutions multitenancy

— RichardW1001
fonte

C'è qualche possibilità che questo si sposti in un ambiente cloud PaaS come Azure? In tal caso, ti consigliamo di prendere in considerazione anche le migliori pratiche per l'ambiente. L'ultima volta che ho guardato, MS ha raccomandato più database per software multi-tenant in Azure.

— Harper Shelby,

Grazie per avermelo chiesto. Mi sono chiesto cose simili, ma non sono stato in grado di mettere in discussione il formato in modo eloquente come te.

— MathAttack

Dovresti leggere la serie di blog multi-tenancy di Ayende. Fa alcuni punti molto positivi sul database multi vs singolo.

— Sebazzz,

12

Ecco i punti salienti della ricerca di altre fonti (originariamente dalla revisione 2 della domanda ):

Dovrei usare un database per applicazione o condividere un singolo database tra più applicazioni
Supportare la multi-tenancy
Architettura dei dati multi-tenant MSDN
SO Come creare un database multi-tenant con strutture di tabelle condivise?
CloudExpo SaaS - Opzioni di progettazione del database multi-tenant
Blog di MSDN Passaggio al modello di database multi-tenant semplificato con le federazioni SQL Azure
Chiedi a SQL Server Central Uno o più database?
SQL Server Central Mixing tabelle da diversi database / applicazioni in un unico database
Ayende @ Rahien blog Multi Tenancy - Il modello di dati fisici
Architettura del database multi-tenant di Project Code
Joel on Software Progettazione di database multi-tenant
SO Applicazione multipla che utilizza un database?
SO Database singoli o multipli
Code Rant - Multi-tenancy Parte 1, Strategia e Parte 2, Componenti e contesto

— Utente 3 giri 40980
fonte

10

Se si utilizza SQL Server, utilizzare un database ma utilizzare schemi. Usa dbo per cose che sono generali per tutti i client e crea uno schema per ogni client e rendilo lo schema predefinito per gli utenti da quel client. Ora puoi avere un oggetto generale (ad esempio un proc getBudget) nello schema dbo e uno personalizzato per il client nel loro schema con lo stesso nome.

— HLGEM
fonte

+1 Ciò consentirà anche di evitare di dover configurare MSDTC e assumere il relativo overhead (commit a due fasi)

— Brian

E speriamo di evitare la trappola di avere colonne come CustomField1 tramite CustomField30 e / o avere tabelle come Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName, ecc.

— jfrankcarr

Esiste un livello di accesso ai dati esistente che utilizza molte procedure memorizzate - 190 tabelle, 5 procedure generate dal codice per tabella, oltre ad alcune personalizzate - mentre l'obiettivo a medio termine è introdurre Entity Framework, sarebbe necessario replicare l'archiviazione procedure per ogni schema?

— RichardW1001,

@ RichardW1001: dipende. puoi fare SQL dinamico nello sp, al fine di renderlo generico, ma questo ovviamente dipende dal fatto che abbiano almeno una struttura un po 'simile. Un'alternativa possibile per sql dinamico, sarebbe Sinonimi , purtroppo, per come li capisco, sono a livello di sistema e non contenuti in una transazione, quindi non adatti per un utilizzo simultaneo con valori diversi.

— jmoreno,

Se utilizziamo più schemi, usando prima il codice EF sarà possibile migrare tutti gli schemi all'ultima versione dopo che il sistema sarà attivo?

— Yashvit,

4

Poiché i database e le funzionalità dei client sono divergenti, significa che a un certo punto finiranno per essere sistemi diversi, quindi in questo caso consiglierei sistemi separati poiché i costi di mantenimento delle personalizzazioni per ciascun client supereranno i vantaggi di un singolo sistema di database.

I sistemi di database singoli sono i migliori quando le modifiche tra clienti diversi sono solo configurazioni ma non funzionalità aggiuntive per ciascun client.

— Stephen Senkomago Musoke
fonte

Quale sarebbe il tuo suggerimento su come gestire la funzionalità comune con il minimo dolore?

— RichardW1001,

1

Nel tuo sistema di controllo versione, mantieni testa all'applicazione principale e crea una filiale principale per ogni cliente, con filiali secondarie per le nuove funzionalità che devono mantenere. Sviluppa funzionalità specifiche per i clienti nelle filiali, con opzioni per aggiornare il trunk, ecc. Puoi quindi creare facilmente ambienti specifici dei clienti ogni volta che ne hai bisogno

— Stephen Senkomago Musoke

3

Ti mancano alcune preoccupazioni. I problemi arriveranno con la crescita. Se puoi presumere che un giorno diventerai più grande di un server DB - un database complesso ti causerà sicuramente un mal di testa. A meno che non investirai in anticipo in architettura. Ma è anche un passo costoso)

Quindi, non dimenticare, che è sia molte volte più economico e molte volte più facile scalare pochi database diversi, rispetto a quelli enormi)

— stim
fonte

Hai dei dati che confermano la facilità di ridimensionamento? Se è così, sarebbe un caso molto convincente. Potresti approfondire le altre preoccupazioni mancanti? Sto cercando di costruire un argomento il più completo possibile su entrambi i lati.

— RichardW1001,

1

Un'area che non ho visto risolto nelle risposte è rappresentata dai problemi con la protezione corretta di un'applicazione DB multi-tenant. Le app multi-tenant devono essere progettate con molta attenzione per evitare problemi di sicurezza. La maggior parte dei database e delle app fornisce un certo, ma non completo isolamento, di solito ci sono modi per inferire direttamente o indirettamente i dati attraverso gli schemi DB. E un bel po 'di risorse condivise (registri e altri file, tabelle DBA, cursori ...) che possono, come minimo, condurre a facili attacchi Denial of Service su altri inquilini, e di solito molto di più.

— Airone
fonte