A che punto diventa impossibile un database per client?

Per uno dei nostri sistemi, disponiamo di dati sensibili dei clienti e archiviamo i dati di ciascun cliente in un database separato. Abbiamo circa 10-15 clienti per quel sistema.

Tuttavia, stiamo sviluppando un nuovo sistema che avrà 50-100 client, forse di più. Sto pensando che in questo caso potrebbe essere impossibile avere un database per client (per archiviare record sensibili e cronologia di audit). Tuttavia non so se questo è perfettamente normale o no, o se esiste un altro modo per mantenere la sicurezza.

Qualche idea su questo?

La gestione di 100 o 500 database non è poi così diversa dalla gestione di 5 o 10: devi solo abbracciare l'automazione e disporre di un piano di scalabilità (e non hai intenzione di utilizzare funzionalità ad alto costo per database come il mirroring in tutti i clienti).

Nel mio lavoro precedente abbiamo usato questa architettura e non avrei mai pensato di unire due client in un unico database, anche se alcune delle sfide possono essere "difficili".

I grandi vantaggi sono i modelli di recupero indipendenti ( apuò essere semplice, bpuò essere completo, ecc.), La capacità di ripristinare in un determinato momento (o rimuovere completamente) un client senza interrompere gli altri, la capacità di spostare senza problemi un client pesantemente pieno di risorse nella propria memoria o in un server completamente diverso con pochissima trasparenza (si aggiorna un file di configurazione o una tabella che indica all'app dove trovare quel client).

Rivolgo molte delle obiezioni, e / o come affrontare i problemi, in questi post:

• Gestione del numero crescente di titolari nell'architettura di database multi-tenant

• Database multi-tenant utilizzando SQL Server 2008?

• Automazione di backup di un numero elevato di database

Che tutti Detto questo, non credo che nessuno di noi può dire voi il punto in cui la gestione diventa impraticabile per voi - è sufficiente sapere che qualunque cosa specifica sfida che si incontra, si può chiedere di questi problemi singolarmente.

Ti consiglio di leggere Multi-Tenant Data Architecture , un white paper che discute le opzioni che hai e pro e contro. Riassumendo, offre tre opzioni:

• DB separati
• schemi separati
• schema condiviso

Ora sei in una fase di DB separata, che offre la migliore separazione (isolamento tra i tenant), ma è la più difficile da gestire. Man mano che cresci in centinaia di inquilini ti renderai conto che la logistica dell'amministrazione di centinaia di DB è tutt'altro che banale. Pensa al backup-ripristino (posizione dei file di backup, lavori, pianificazioni ecc.). Pensa come monitorerai e gestirai l'allocazione dei file, lo spazio su disco utilizzato e la crescita del database tra centinaia di DB. Pensi quale sarà il tuo scenario di disponibilità elevata / ripristino di emergenza in un prossimo futuro con 1000 tenant? 1000 DB con mirroring, 1000 sessioni di log shipping? Pensa cosa succederebbe se tra 6 mesi il tuo team di sviluppo venisse da te e dicessi "So come dare questa fantastica funzionalità al nostro prodotto, utilizzeremo la replica transazionale!", Cosa dirai? "certo, lasciami impostare 500 editori,"! Non è impossibile da gestire centinaia di DB, ma se avete intenzione di, è meglio ripulire le vostre PowerShell abilità e smettere di usare gli strumenti di gestione dell'interfaccia utente in questo momento .

Inoltre, devi considerare che più (centinaia) DB hanno un impatto misurabile su prestazioni e costi:

• lo spazio su disco fisico è meno efficiente utilizzato (tutti i database deve avere una certa stanza di ricambio, avrete quella stanza ricambio moltiplicato per il numero di DB)
• Non è possibile creare un disco di registro dedicato per le attività di scrittura intensiva, è necessario spostare tutti quei LDF su uno (o più) archivi SSD
• le scritture dei registri saranno meno efficienti nei commit frequenti poiché si estendono su molti singoli record di blocchi di registro vs. aggregati in uno (otterrai blocchi di registro sottoutilizzati). Vedi Cos'è un LSN: Log Sequence Number per capire di cosa sto parlando.

I DB separati presentano alcuni vantaggi a causa dell'isolamento, il principale vantaggio è il backup / ripristino indipendente.

Lo scenario come il tuo è un candidato perfetto per i database SQL Azure . Nessuna amministrazione dello spazio su disco, nessuna necessità di fornire HA / DR, crescere fino a centinaia / migliaia di DB ecc.

Nel mio lavoro precedente, non ospitavamo solo un database per client - nella maggior parte dei casi, era più di questo! Alla mia partenza, c'erano oltre 4.500 database in esecuzione in un cluster MariaDB, quasi 7.000 in un altro cluster (ironicamente più piccolo) e 4 "frammenti" (server Web e database completamente separati e indipendenti, anche in un centro dati completamente separato) ogni hosting 200-500 database in un singolo server MySQL. E quella compagnia sta ancora crescendo a un buon ritmo.

Il lungo e il corto è che il successo di quell'azienda dimostra che una tale architettura è effettivamente fattibile. (Avvertenza: contrariamente ai guadagni apparenti in isolamento utilizzando database separati, a tutti i dati si accedeva attraverso un trio di applicazioni strettamente accoppiate che utilizzavano tutti lo stesso utente / pass del database! aveva un utente / pass separato - ma solo leggermente.)

Dalle mie esperienze di lavoro a stretto contatto con gli amministratori di sistema (tecnicamente ero un programmatore della compagnia, ma in realtà ero il miglior DBA che avevano e l' unica persona che avevano che sapeva come installare un firewall!), In relazione alle prestazioni preoccupazioni ridotte ad accessi simultanei, complessità / tempo delle query, prestazioni dell'indice, ecc. - tutti i soliti sospetti, in altre parole, e il numero di database sul server non hanno svolto alcuna parte riconoscibile, una conclusione affermata dallo specialista altamente pagato consulenti che abbiamo consultato regolarmente.

La linea di fondo è che dovresti concentrare le tue preoccupazioni sulla tua applicazione, sulla tua infrastruttura e non sul numero di database che ti capita di avere. Tutti questi altri fattori saranno più che sufficienti per tenervi occupati a risolvere problemi di prestazioni e colli di bottiglia.