Un grande database contro diversi più piccoli

Abbiamo una situazione in cui possiamo (A) distribuire istanze di un'applicazione in un database MySQL utilizzando il prefisso delle tabelle o (B) utilizzare database MySQL diversi per ogni istanza dell'applicazione, ad esempio,

Setup "A":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Il risultato finale è un grande db con molte tabelle.

Setup "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Il risultato finale sono molti database con alcune tabelle.

A parità di condizioni (ad es. Quantità di dati, numero di istanze di app, ecc.), Quali sono i pro e i contro di entrambi i metodi? Cosa sarebbe dannoso per le prestazioni e la manutenzione del database? L'applicazione si basa su PHP 5, funziona su Apache 2.xe eseguiamo MySQL 5.x.

Mille grazie per il tuo tempo e pensieri!

Ho gestito un sistema con la parte migliore di un migliaio di database, distribuiti su più server. Erano tutti una struttura identica e erano sincronizzati con un database modello che era su ciascuna delle macchine.

Ciò mi ha permesso di migrare database da un db all'altro se uno si stava sovraccaricando eccessivamente e, man mano che il mix di client cambiava, potevo creare nuovi database su server diversi per caricare il bilanciamento tra i server. Questo è stato il più grande vantaggio che ho ottenuto dal sistema, in quanto avevo più grosse quantità di stagno che eseguivano simultaneamente più query complicate su server separati.

La cosa grandiosa di questo è che puoi aggiungere server alla configurazione alla tua velocità, poiché ogni server inizia a sovraccaricarsi, aggiungerne un altro nel mix, migrare alcuni dbs attraverso il nuovo server e finire con un carico bilanciato set di server. Un modo davvero semplice e piacevole per aggiungere scala al sistema come e quando è richiesto!

Il motivo per cui ho seguito questo approccio piuttosto che il solo enorme approccio al database, è stata la vastità del potenziale database che sarebbe stato creato ... ognuno dei 1000 database aveva 200 tabelle e molte delle singole tabelle all'interno di ciascuna delle i database comprendevano centinaia di milioni di righe di dati!

Una singola configurazione del database avrebbe richiesto che alcune tabelle (circa 8 di esse) presentassero miliardi di righe di dati e la dimensione totale del db sarebbe stata superiore a 10 TB. Siamo riusciti a disporre di più server con 5 TB di spazio di archiviazione RAID 10, con molti database su ciascuno.

Questo è quello che vorrei fare! Spero che aiuti le tue decisioni ... :)

L'applicazione che stai creando è un'applicazione SaaS? In tal caso, ti suggerirei di prendere in considerazione un terzo approccio - avere un DB, con una struttura comune per tutte le istanze dell'applicazione con una differenza - aggiungere una colonna userid / applicationid in tutte le tabelle. Ciò ridurrà notevolmente i costi di sviluppo / manutenzione delle applicazioni. Questo nella mia esperienza è uno dei migliori approcci per l'archiviazione di dati multi-tenant.

Vedi anche questo fantastico white paper di Microsoft sull'architettura dei dati multi-tenant

Sottolinea inoltre i vantaggi / gli svantaggi degli approcci che hai citato.

L'installazione B è molto più semplice da gestire

Ognuno si tablentrova in una cartella diversa. Ciò può essere molto utile se non si desidera testare i limiti del sistema operativo .

Ad esempio, il mio datore di lavoro ospita MySQL per un sistema CRM di concessionarie di automobili. Il cliente ha 800 concessionari. Ogni database di concessionari ha 160 tabelle. Sono 128.000 tavoli.

• Nell'installazione A, tutte le 128.000 tabelle si troverebbero in un database.
• In Setup B, ogni set di 160 tabelle si trova in una sottocartella in / var / lib / mysql.

Dal punto di vista del sistema operativo e della sua capacità di gestire i-nodi (o tabelle FAT per Windows), che include avere un numero massimo di file per cartella:

• Nell'installazione A, ti preoccuperesti di circa 128.000 file in una cartella. Il tuo sistema operativo può supportare così tanti file in una singola cartella?
• Nell'installazione B, non preoccuparti.

Se hai dovuto tweekare le strutture delle tabelle usando ALTER TABLEo qualche altro DDL:

• Sotto Setup A, dovresti eseguire lo script del DDL necessario utilizzando PHP (o script MySQL specializzati) sul nome specifico della tabella e sulle query corrispondenti prima di accedervi e apportare modifiche
• In Setup B, Connetti al database corretto, quindi accedi sempre alla stessa tabella con nome. Il paradigma di accesso sarebbe sempre pulito:
  • Database specifico
  • Cartella specifica sotto /var/lib/mysql
  • TableName specifico.

Se si desidera inserire database diversi su dischi diversi:

• Nell'installazione A, i collegamenti simbolici per ogni tabella spostata su un disco separato non faranno altro che aggravare il problema "numero di inode in una cartella". L'I / O del disco e l'accesso alla tabella complessiva complicano maggiormente e aumentano il carico generale del server poiché .frmsi accede ripetutamente ai file.
• In Setup B, è sufficiente spostare un'intera cartella del database in un montaggio dati separato. L'I / O del disco può essere distribuito su richiesta.
• CAVEAT: Altamente scoraggiato per InnoDB

Parlando metaforicamente, quale preferiresti avere?

• un gigantesco appartamento con una camera da letto, un bagno e una cucina (SetupA)
• più appartamenti, ognuno con la propria camera da letto, bagno e cucina (SetupB)

Quando si tratta di riparare un radiatore in un appartamento:

• Con l'installazione A, ogni inquilino può essere scomodo e deve essere coinvolto perché devi parlare con gli inquilini interessati di fronte a tutti come se fossero affari di tutti
• Con Setup B, oltre a sentire qualche botto sul muro o nei tubi, gli inquilini possono continuare la loro vita privata
• Questo elenco e le sue metafore possono continuare all'infinito

IHMO Sebbene i budget possano essere una forza trainante per le decisioni di progettazione / infrastruttura, sarei facilmente a favore di database separati per cliente.

Ho anche un prodotto SaaS e utilizzo la stessa configurazione menzionata da Dave Rix.

Ogni cliente ha il proprio database

Vorrei fare qualche altro suggerimento:

• È necessario disporre di un "controller" di database con bilanciamento del carico (master-master) che memorizzi la posizione del database (ip), il nome del database e il nome del cliente. Questo controller è dove l'applicazione sa dove si trova ciascun database dei clienti.

• L'applicazione può essere ovunque tu voglia: puoi avere database per molti datacenter in tutto il mondo.

• La tua applicazione può crescere quanto vuoi. Se si tratta di un Web SaaS, è possibile creare una farm di server Web con bilanciamento del carico che punta a ciascun database, come tempo di accesso del cliente.

• Sei in grado di creare VISTA / Database personalizzati per alcuni clienti, senza influire su altri. È importante se cerchi di offrire la personalizzazione come parte della tua attività.

• È possibile impostare due web farm + database farm: una per "EDGE" e un'altra per le versioni "STABLE". Quindi, dovrai avere un piccolo gruppo di clienti disposti a testare le cose e confermare che tutto funzioni come previsto (in altre parole, garanzia di qualità [QA]), prima di applicare a tutti i tuoi clienti.

• È necessario disporre di un processo di backup automatico per database almeno una volta al giorno.

• Dovresti avere un altro server per eseguire la replica. Uno stesso host può replicare molti database (usare porte diverse per ciascun server sullo stesso host) se non puoi permetterti la stessa quantità di server host "master" e "slave".

  Ad esempio, 5 server master + 1 server slave con 5 database in esecuzione su porte diverse: basta avere RAM sufficiente per farlo.

• È necessario eseguire uno strumento di "migrazione" per spostare un database su un altro server ogni volta che lo si desidera.

• È necessario migrare i clienti VIP su un server di database più sicuro / disponibile per proteggere le entrate. Ricorda, molte volte il 20% dei clienti rappresenta l'80% delle tue entrate. Prenditi cura di clienti speciali.

• Dovresti avere un raccoglitore "garbage" di backup-delete, per fare un "ultimo backup" ed eliminare il database quando un cliente lascia la tua azienda.

• È necessario disporre di un'immagine del database in cui esportare e utilizzare per i nuovi account.

• È necessario disporre di uno strumento di patching del database per applicare nuove patch agli account esistenti.

• Mantieni le versioni di tutte le tue patch SQL, usando uno strumento di versioning come sovversione o git e crea anche la tua numerazione. xxx-4.3.0.sql - a volte le patch vanno male e devi sapere come recuperare / completare l'attività di patch.

Bene, questo è tutto ciò che faccio nella mia azienda con un prodotto che ha circa 5k database con circa 600 tabelle ciascuno.