Modello SaaS, 1DB per client

Question

Modello SaaS, 1DB per client

#1 da (2 voti)
#2 da (1 voti)

2

Il contesto

stiamo costruendo un sistema basato sul web e una delle decisioni di progettazione ( database correlato ) è stata la possibilità di disporre di 1 DB principale per gestire tutti i dati dei client VS con 1 DB per client. Dopo aver letto molto sull'argomento ( specialmente in questi forum ), sembra che 1 DB per cliente sia nel complesso un approccio migliore, soprattutto a medio-lungo termine e soprattutto nel nostro caso d'uso.

L'architettura di base

Il nostro sistema è principalmente un sistema front-end che estrae i dati da un webservice RESTful ( dove si trovano i dati del client ), per accedere a quel webservice utilizziamo chiavi univoche, ogni chiave appartenente a uno specifico coppia di CLIENT: DATABASE.

Dove le cose si complicano

Quando un nuovo client crea un account, l'idea è di fare in modo che il webservice crei automaticamente un nuovo DB , DB user e chiave API per quell'account. Ho cercato un metodo standard per implementarlo, ma non ho trovato nulla di conclusivo. Ovviamente, i provider SaaS automatizzano questa roba, ma dove non riesco a capire è come fanno questo sicuro .

L'unica soluzione corrente che ho è di creare una sorta di utente MASTER MySQL, che ha un potere totale assoluto su MySQL, che useremo per creare queste coppie di utenti DB, DB. Ma sembra una configurazione così pericolosa che CANT sia l'unica soluzione. Qualsiasi compromissione a questo utente sarebbe fatale . Qui è dove ho bisogno del tuo aiuto ...

Un'altra domanda secondaria, è come limitare la dimensione del DB con MySQL / innoDB. L'unica cosa che ho trovato è che MySQL può solo limitare TABLE SIZE. E, in contesti più sofisticati, che i DB sono memorizzati in directory separate che hanno una quota disco specifica ( questo sembra essere usato da alcuni provider di hosting Web ... ma non posso confermare ). Qualcuno sa di qualsiasi altro modo per controllare la dimensione del DB?

database mysql software-as-a-service

posta Sebastien Daniel 29.09.2014 - 23:15

fonte

2 risposte

Leggi altre domande sui tag database mysql software-as-a-service

Come posso migliorare la complessità di spazio O (N ^ 2) per una ricerca di sequenza di tipo? JBPM è lo strumento giusto per questo? [chiuso]

score 2 · Answer 1

Questo è il classico dilemma single-tenant vs multi-tenant. Per servire più client, dovresti:

Avere un singolo database che include i dati per tutti i tuoi clienti (cioè renderli tutti titolari del tuo singolo database), o
Avere più database, con ogni client partizionato e il singolo titolare che interagisce con il proprio database.

La maggior parte dei negozi SaaS (e di altri servizi XYZ-as-a-service) che conosco e quasi tutte le proprietà su Internet (Google, Facebook, Twitter, ecc.) preferiscono strongmente il modello multi-tenant. Il multi-tenant è generalmente più efficiente, forse per prestazioni, ma ancora di più per ridurre al minimo il sovraccarico amministrativo. C'è solo un database da configurare e preoccupare, con i dati per diversi client separati da valori di client_id . Ma non c'è una soluzione magica. Se "metti tutte le uova in un cesto", allora devi lavorare molto duramente per proteggere quel cesto. Inoltre, i database all-in-one possono crescere rapidamente se si ha successo e avere molti clienti, che richiedono investimenti in distribuzione, replica, indicizzazione e altre ottimizzazioni di scalabilità e qualità del servizio. Gli sviluppatori di SaaS e di servizi su scala Internet investono molto tempo ed energia nelle loro infrastrutture.

Alcuni negozi as-a-service utilizzano configurazioni single-tenant, con client che hanno ciascuno la propria istanza di database (e spesso, macchine virtuali separate o ambienti virtuali). Una ragione è l'ovvia virtù di "maggior isolamento", che viene spesso percepita come dotata di maggiori protezioni per la sicurezza e la privacy. Questo non è solo un attributo tecnico; è anche una questione di preferenza del cliente e facilità di vendita.

Singolo e multi-tenant sono grandi etichette, ma ci sono molti approcci ibridi e di medio livello tra i due poli. Il singolo gestore di database che esegue più "istanze di database" che sembra descrivere, ad esempio, è l'architettura utilizzata da molti host di WordPress. È una specie di a scenario "multi-tenant lite" o "housemate". Per andare avanti e configurazioni più piccole, ha molte virtù.

score 1 · Answer 2

Hai preso in considerazione la pre-creazione di un numero di database prima dell'uso e quando un nuovo cliente crea un account, registra il mapping dal nome dell'account del cliente al DB pre-creato? In questo modo puoi limitare gli attacchi di tipo Denial of Service che creano automaticamente troppi database per il DBMS da gestire (perché l'elenco dei database pre-creati si esaurirà) e eviterai la necessità di creare dei privilegi per i day-to- day interazione utente del giorno.

Se hai incluso nel mapping il server database allo stesso tempo, ad esempio, hai usato un "nome cliente" - > mappatura 'server: pre-created-db-name', puoi gestire lo sharding anche semplicemente spostando il DB da server a server e aggiornando la mappa master che può essere memorizzata come lib / file centrale da qualche parte, o anche in un master DB.

Se hai compilato il set di DB pre-creato ogni giorno (ad esempio) avresti una velocità automatica sul numero in qualsiasi momento.