Come creare un database multi-tenant con strutture di tabelle condivise?

Il nostro software attualmente funziona su MySQL. I dati di tutti i tenant sono archiviati nello stesso schema. Dato che stiamo usando Ruby on Rails, possiamo facilmente determinare quali dati appartengono a quale inquilino. Tuttavia, ci sono alcune aziende che temono che i loro dati possano essere compromessi, quindi stiamo valutando altre soluzioni.

Finora ho visto tre opzioni:

• Database multiplo (ogni tenant ne ottiene uno proprio, quasi uguale a 1 server per cliente)
• Multi-Schema (non disponibile in MySQL, ogni tenant ottiene il proprio schema in un database condiviso)
• Schema condiviso (il nostro approccio attuale, forse con record identificativi aggiuntivi su ogni colonna)

Multi-Schema è il mio preferito (considerando i costi). Tuttavia, la creazione di un nuovo account e l'esecuzione delle migrazioni sembrano essere abbastanza dolorose, perché dovrei scorrere tutti gli schemi e cambiare le loro tabelle / colonne / definizioni.

D: Multi-Schema sembra essere progettato per avere tabelle leggermente diverse per ogni tenant - non lo voglio. Esiste un RDBMS che mi consente di utilizzare una soluzione multi-tenant multi-schema, in cui la struttura della tabella è condivisa tra tutti i tenant?

PS Per multi intendo qualcosa come ultra-multi (oltre 10.000 inquilini).

Tuttavia, ci sono alcune aziende che temono che i loro dati possano essere compromessi, quindi stiamo valutando altre soluzioni.

Questo è un peccato, poiché i clienti a volte soffrono di un malinteso secondo cui solo l'isolamento fisico può offrire sufficiente sicurezza.

C'è un interessante articolo MSDN, intitolato Multi-Tenant Data Architecture , che potresti voler controllare. Ecco come gli autori hanno indirizzato il malinteso verso l'approccio condiviso:

Un malinteso comune sostiene che solo l'isolamento fisico può fornire un livello adeguato di sicurezza. In effetti, i dati memorizzati utilizzando un approccio condiviso possono anche fornire una forte sicurezza dei dati, ma richiedono l'uso di modelli di progettazione più sofisticati.

Per quanto riguarda le considerazioni tecniche e commerciali, l'articolo fa una breve analisi su dove un certo approccio potrebbe essere più appropriato di un altro:

Il numero, la natura e le esigenze degli inquilini che ci si aspetta di soddisfare influiscono in modo diverso sulla decisione dell'architettura dei dati. Alcune delle seguenti domande potrebbero orientarti verso un approccio più isolato, mentre altre potrebbero orientarti verso un approccio più condiviso.

• Quanti potenziali inquilini ti aspetti di scegliere come target? Potresti non essere in grado di stimare l'uso futuro con autorità, ma pensare in termini di ordini di grandezza: stai creando un'applicazione per centinaia di inquilini? Migliaia? Decine di migliaia? Di Più? Maggiore è la tua base di inquilino, maggiore sarà la probabilità di prendere in considerazione un approccio più condiviso.

• Quanto spazio di archiviazione ti aspetti dai dati dell'inquilino medio? Se si prevede che alcuni o tutti i tenant memorizzino grandi quantità di dati, l'approccio con database separato è probabilmente il migliore. (In effetti, i requisiti di archiviazione dei dati potrebbero costringerti ad adottare comunque un modello di database separato. In tal caso, sarà molto più semplice progettare l'applicazione in questo modo dall'inizio piuttosto che passare a un approccio a database separato in seguito.)

• Quanti utenti finali simultanei ti aspetti che l'inquilino medio supporti? Maggiore è il numero, più appropriato sarà un approccio più isolato per soddisfare le esigenze degli utenti finali.

• Prevedi di offrire servizi a valore aggiunto per tenant, come il backup e la capacità di ripristino per tenant? Tali servizi sono più facili da offrire attraverso un approccio più isolato.

AGGIORNARE: ulteriore aggiornamento sul numero previsto di inquilini.

Quel numero previsto di inquilini (10k) dovrebbe escludere l'approccio multi-database, per la maggior parte, se non per tutti gli scenari. Non credo che ti piacerà l'idea di mantenere 10.000 istanze di database e di doverne creare centinaia di nuove ogni giorno.

Da quel solo parametro, sembra che l'approccio a schema singolo sia il database condiviso sia il più adatto. Il fatto che memorizzerete solo circa 50 Mb per inquilino e che non vi saranno componenti aggiuntivi per inquilino, rende questo approccio ancora più appropriato.

L'articolo di MSDN sopra citato menziona tre modelli di sicurezza che affrontano le considerazioni sulla sicurezza per l'approccio del database condiviso:

• Connessioni al database attendibili
• Filtro vista locatario
• Crittografia dei dati degli inquilini

Quando sei sicuro delle misure di sicurezza dei dati della tua applicazione, sarai in grado di offrire ai tuoi clienti un accordo sul livello di servizio che fornisca forti garanzie di sicurezza dei dati. Nel tuo SLA, oltre alle garanzie, potresti anche descrivere le misure che vorresti adottare per garantire che i dati non fossero compromessi.

AGGIORNAMENTO 2: Apparentemente i ragazzi di Microsoft hanno spostato / fatto un nuovo articolo su questo argomento, il collegamento originale è sparito e questo è quello nuovo: modelli di tenancy del database SaaS multi-tenant (complimenti a Shai Kerer)

La mia esperienza (anche se SQL Server) è che il multi-database è la strada da percorrere, dove ogni client ha il proprio database. Quindi, anche se non ho esperienza mySQL o Ruby On Rails, spero che il mio contributo possa aggiungere un valore.

I motivi per cui includono:

1. sicurezza dei dati / disaster recovery. I dati di ciascuna azienda vengono archiviati completamente separatamente dagli altri, riducendo il rischio che i dati vengano compromessi (pensando a cose come l'introduzione di un bug del codice che significa che qualcosa guarda erroneamente altri dati del cliente quando non dovrebbe), minimizza la potenziale perdita per un cliente se uno database particolare viene danneggiato, ecc. I vantaggi di sicurezza percepiti per il client sono ancora maggiori (effetto collaterale bonus aggiunto!)
2. scalabilità. In sostanza, partizioneresti i tuoi dati per consentire una maggiore scalabilità - ad esempio, i database possono essere inseriti su dischi diversi, potresti portare online più server di database e spostare i database più facilmente per distribuire il carico.
3. ottimizzazione delle prestazioni. Supponiamo di avere un client molto grande e uno molto piccolo. I modelli di utilizzo, i volumi di dati, ecc. Possono variare notevolmente. È possibile ottimizzare / ottimizzare più facilmente per ogni cliente nel caso fosse necessario.

Spero che questo offra qualche input utile! Ci sono più ragioni, ma la mia mente è svanita. Se si ripresenta, aggiornerò :)

EDIT:
Da quando ho pubblicato questa risposta, ora è chiaro che stiamo parlando di oltre 10.000 inquilini. La mia esperienza è in centinaia di database su larga scala - non credo che 10.000 database separati saranno troppo gestibili per il tuo scenario, quindi ora non sto favorendo l'approccio multi-db per il tuo scenario. Soprattutto perché ora è chiaro che stai parlando di piccoli volumi di dati per ogni inquilino!

Mantenere la mia risposta qui in ogni caso in quanto potrebbe essere utile per altre persone su una barca simile (con un numero minore di inquilini)

Di seguito è riportato un collegamento a un white paper su Salesforce.com su come implementare la multi-tenancy:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

Hanno 1 enorme tabella con 500 colonne di stringa (Valore0, Valore1, ... Valore500). Date e numeri sono memorizzati come stringhe in un formato in modo tale da poter essere convertiti nei loro tipi nativi a livello di database. Esistono tabelle di metadati che definiscono la forma del modello di dati che può essere unica per tenant. Esistono tabelle aggiuntive per indicizzazione, relazioni, valori univoci, ecc.

Perché la seccatura?

Ogni inquilino può personalizzare il proprio schema di dati in fase di runtime senza dover apportare modifiche a livello di database (modifica tabella ecc.). Questo è sicuramente il modo più difficile di fare qualcosa del genere, ma è molto flessibile.

Come accennato, un database per inquilino è un'opzione e presenta alcuni compromessi più ampi. Può funzionare bene su scala più piccola, come una singola cifra o un numero basso di 10 inquilini, ma oltre a ciò diventa più difficile da gestire. Sia solo le migrazioni ma anche solo per mantenere i database attivi e funzionanti.

Il modello per schema non è utile solo per schemi univoci per ciascuno, anche se l'esecuzione delle migrazioni su tutti i tenant diventa difficile e dopo 1000 di schemi Postgres può iniziare ad avere problemi.

Un approccio più scalabile consiste nel distribuire casualmente i tenant, archiviati nello stesso database, ma su diversi frammenti logici (o tabelle ). A seconda della tua lingua ci sono diverse librerie che possono aiutarti in questo. Se si utilizza Rails, è disponibile una libreria prima della locazione acts_as_tenant, che consente alle query dei titolari di recuperare solo quei dati. C'è anche un gioiello apartment, sebbene utilizzi il modello di schema che aiuta con le migrazioni attraverso tutti gli schemi. Se stai usando Django c'è un numero, ma uno dei più popolari sembra attraversare schemi . Tutto ciò aiuta di più a livello di applicazione. Se stai cercando qualcosa di più direttamente a livello di database, Citus si concentra sulla realizzazione di questo tipo di shardingla multi-tenancy lavora più facilmente con Postgres.