Un database vs molti database

So che la domanda è stata posta molte volte ma vorrei una risposta per il mio caso.Un database vs molti database

Sto lavorando a un'applicazione web che consentirà ai miei clienti di gestire i loro clienti, incassi, fatture, prenotazioni, un sito Web e molte altre cose. Sto usando MySQL e un database con circa 30 tabelle.

Vorrei che la mia soluzione fosse in grado di gestire circa 100.000 clienti o più. Le esigenze dei miei clienti saranno molto diverse. Da 100 inserti all'anno per uno, a 1000 inserti al giorno per un altro.

Per ora sto utilizzando un database (ma sono ancora in fase di sviluppo) in cui ogni tabella ha un campo account. Ho creato un livello del modello per accedere ai dati che aggiungono automaticamente l'account a ogni query (WHERE guid = 1 diventa WHERE account = X AND guid = 1). Questo funziona molto bene ed è davvero facile da mantenere, ma sono preoccupato per il fatto di mescolare i dati dei miei clienti. Si noti che sto utilizzando un ID incrementale invece di un GUID.

La mia domanda è, dovrei continuare a fare cose come questa o dovrei creare un database per client?

fonte

2011-11-28 Nicolas BADIA

Ti * * avere 100.000 clienti in questo momento? In caso contrario, si è in via di pre-ottimizzazione cercando di averlo come requisito. –

E la risposta alla tua domanda è enorme "dipende". Senza ulteriori dettagli sulle specifiche, non c'è nulla che possa essere detto. –

Quali altri dettagli vuoi? Come ho detto, sono ancora in sviluppo quindi ho solo pochi tester. Ma stavo pensando che questo tipo di cosa dovrebbe essere pensata prima di aprire la mia richiesta al pubblico. Ho sbagliato ? –

Stai guardando un database multi-tenant. Le soluzioni multi-tenant vanno da un database per client (niente condiviso) a una riga per client (tutto condiviso).

"Shared nothing" è il più costoso per client. Un numero elevato di client implica un numero elevato di server. Il disaster recovery del client è semplice e diretto. "Shared nothing" riduce la possibilità di esposizione accidentale dei dati dei client quasi a zero.

"Condiviso tutto" è il meno costoso per cliente. Ogni tabella ha una colonna che identifica il client a cui appartiene una riga. Il disaster recovery del client è molto complicato; devi ripristinare singole righe in ogni tabella. "Condiviso tutto" è l'architettura che più probabilmente espone accidentalmente i dati dei clienti.

Microsoft ha un buon articolo su multi-tenant architecture. La loro terminologia è

database separato (non comune)
schema separato
schema condiviso (condiviso tutto)

fonte

2011-11-28 08:20:43

ben scritto, ho anche provato a spiegare questo, ma la tua risposta è superba. –

Grazie per la risposta e l'articolo. Mi sembra che uno schema separato sia l'opzione migliore per me, ma, da quello che so, mysql non lo consente.Così ora ho 3 opzioni, rimango così, passare a PostgreSQL (che mi sembra una buona opzione), o usare un database separato (sembra una cattiva opzione dato che non mi aspetto di fare uno sviluppo specifico per un client) . Qualche consiglio? –

Personalmente, preferirei lavorare con PostgreSQL che con MySQL. Ma più host web offrono MySQL di PostgreSQL. Un database MySQL non è molto diverso da uno schema PostgreSQL. Entrambi forniscono uno spazio dei nomi e MySQL può eseguire query su database come le query PostgreSQL su schemi. PostgreSQL non supporta le query dirette su due database. –

risposta

Problemi correlati