it-swarm.it

Un grande database contro diversi più piccoli

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

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 ei contro di entrambi i metodi? Cosa sarebbe dannoso per le prestazioni e la manutenzione del database? L'applicazione è PHP 5, funziona su Apache 2.xe eseguiamo MySQL 5.x.

Mille grazie per il tuo tempo e pensieri!

14
KM.

Ho eseguito 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.

Questo 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 sovraccaricare, aggiungere 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 semplice per aggiungere scala al sistema come e quando è richiesto!

La ragione per cui ho seguito questo approccio piuttosto che il solo approccio al database enorme, è stata la vastità del potenziale database che sarebbe stato creato ... ciascuno dei 1000 database aveva 200 tabelle e molte delle singole tabelle all'interno di ciascuna delle i database comprendevano centinaia di milioni di file 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 stati in grado di avere 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 ... :)

14
Dave Rix

L'applicazione che stai creando è 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 un 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 ottimo white paper di Microsoft sull'architettura dei dati multi-tenant

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

11

L'installazione B è molto più semplice da gestire

Ogni tablen si trova in una cartella diversa. Questo 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 unico 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 dovessi tweekare le strutture delle tabelle usando ALTER TABLE o qualche altro DDL:

  • Sotto Setup A, dovresti eseguire lo script del DDL necessario usando PHP (o script MySQL specializzati) sul nome specifico della tabella e le 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 in /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 di più e aumentano il carico generale del server dal .frm si 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 dei colpi alla parete o alle tubature, 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.

9
RolandoMySQLDBA

Ho anche un SaaS e uso 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.

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

  • È possibile configurare 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 funziona 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 (utilizzare porte diverse per ciascun server nello 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.

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

  • È necessario disporre di un raccoglitore "garbage" di backup-delete, per eseguire un "ultimo backup" ed eliminare il database quando un cliente lascia la propria 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 Subversion 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.

3
b0x