MySQL: molte tabelle o molti database?

Question

Per un progetto abbiamo un mucchio di dati che hanno sempre la stessa struttura e non sono collegati tra loro. Ci sono due approcci per salvare i dati:

• Creazione di un nuovo database per ogni piscina (circa 15-25 tavoli)
• Creazione di tutte le tabelle di un database e si differenziano le piscine dai nomi di tabella.

Quale è più facile e veloce da gestire per MySQL?

EDIT: Non sono interessato ai problemi di progettazione di database, sono interessato solo a quale delle due possibilità è più veloce.

MODIFICA 2: Cercherò di renderlo più chiaro. Come detto, avremo dati, in cui alcune date raramente appartengono insieme in diversi pool. Mettere tutti i dati di un tipo in un unico tavolo e collegandola con una piscina id non è una buona idea:

• E 'difficile fare il backup/eliminare un pool specifico (e ci aspettiamo che siamo agli sgoccioli chiavi primarie dopo un po '(anche se usate big int))

Quindi l'idea è di creare un database per ogni pool o creare molte tabelle in un database. Il 50% delle query sul database sarà semplice inserts. Il 49% sarà un semplice selects su una chiave primaria.

La domanda è: cosa è più veloce da gestire per MySQL? Molte tabelle o molti database?

Answer 1

Non ci dovrebbero essere differenze significative di prestazioni tra più tabelle in un singolo database rispetto a più tabelle in database separati.

In MySQL, i database (SQL standard utilizza il termine "schema" per questo) servono principalmente come spazio dei nomi per le tabelle. Un database ha solo pochi attributi, ad es. il set di caratteri e le regole di confronto predefiniti. E quell'uso di GRANT rende conveniente controllare i privilegi di accesso per database, ma questo non ha nulla a che fare con le prestazioni.

È possibile accedere a tabelle in qualsiasi database da una singola connessione (a condizione che siano gestite dalla stessa istanza di MySQL Server). Devi solo qualificare il nome della tabella:

SELECT * FROM database17.accounts_table; 

Questa è una differenza puramente sintattica. Non dovrebbe avere alcun effetto sulle prestazioni.

Per quanto riguarda l'archiviazione, non è possibile organizzare le tabelle in un file per database come specifichiamo @Chris. Con il motore di archiviazione MyISAM, hai sempre un file per tabella. Con il motore di archiviazione InnoDB, si dispone di un singolo set di file di archiviazione che amalgamano tutte le tabelle, oppure si dispone di un file per tabella (questo è configurato per l'intero server MySQL, non per database). In entrambi i casi, non vi è alcun vantaggio in termini di prestazioni o svantaggio nella creazione delle tabelle in un singolo database rispetto a molti database.

Non ci sono molti parametri di configurazione MySQL che funzionano per database. La maggior parte dei parametri che influiscono sulle prestazioni del server sono di ambito server.

Per quanto riguarda i backup, è possibile specificare un sottoinsieme di tabelle come argomenti per il comando mysqldump. Potrebbe essere più comodo eseguire il backup di serie logiche di tabelle per database, senza dover denominare tutte le tabelle sulla riga di comando. Ma non dovrebbe fare alcuna differenza per le prestazioni, ma solo per la praticità quando si inserisce il comando di backup.

Answer 2

Perché non creare un singolo tavolo per tenere traccia dei tuoi pool (con PoolID e PoolName come colonne, e qualsiasi altra cosa tu voglia tracciare) e poi sulle tue 15-25 tabelle dovresti aggiungere una colonna su tutti loro che sarebbero una chiave estranea al tuo tavolo da biliardo in modo da sapere a quale pool appartiene quel particolare record.

Se non si desidera mescolare i dati in questo modo, suggerirei di creare più database. La creazione di più tabelle tutte per la stessa funzionalità rende il mio ragno sensazionale.

Answer 3

Se non si desidera un gruppo di tabelle con nome poolID pool come suggerito daTXI, utilizzare database separati anziché tabelle multiple che fanno tutti la stessa cosa.

In questo modo, si limita la variazione tra l'accesso di diversi pool all'istruzione "use database" iniziale, non sarà necessario ricodificare i SELECT ogni volta o disporre di SQL dinamico.

Gli altri vantaggi di questo approccio sono:

• Facile backup/ripristino
• facile start/stop di un'istanza di database.

Gli svantaggi sono:

• un po 'di lavoro più di amministrazione, ma non molto.

Non so quale sia l'applicazione, ma davvero molto attentamente prima di creare tutte le tabelle in un unico database. In questo modo giace la pazzia.

Modifica: Se la prestazione è l'unica cosa che ti riguarda, devi misurarla. Prendi una serie rappresentativa di query e misura le loro prestazioni.

Modifica 2: la differenza di prestazioni per una singola query tra le molte tabelle/molti modelli di database sarà trascurabile. Se hai un database, puoi sintonizzarti su di esso. Se hai molti database, puoi sintonizzarti su tutti.

Il mio (il nostro? - non può parlare per nessun altro) punto è che, per i database ottimizzati, non ci sarà praticamente alcuna differenza di prestazioni tra le tre opzioni (poolid in table, multiple tables, multiple database), così puoi scegliere l'opzione più facile per te, a breve ea lungo termine.

Per me, l'opzione migliore è ancora un database con poolId, come suggerito da TheXTX, quindi più database, a seconda delle esigenze (principalmente di amministrazione). Se hai bisogno di sapere esattamente quale sia la differenza di rendimento tra due opzioni, non possiamo darti quella risposta. È necessario configurarlo e testarlo.

Con più database, diventa facile installare hardware per migliorare le prestazioni.

Answer 4

Non sono troppo sicuro di comprendere completamente il tuo scenario. Vuoi avere tutti i pool che usano le stesse tabelle, ma differiscono solo per una chiave distintiva? O vuoi pool separati di tabelle all'interno del database, con un suffisso su ogni tabella per distinguere i pool?

In entrambi i casi, è necessario disporre di più database per due motivi principali. Il primo è se devi cambiare lo schema su un pool, non influenzerà gli altri.

Il secondo, se il carico sale (o per qualsiasi altro motivo), è possibile spostare i pool su macchine fisiche separate con nuovi server di database.

Inoltre, l'accesso di sicurezza a un server di database può essere bloccato in modo più preciso.

Tutte queste cose possono ancora essere eseguite senza richiedere database separati, ma la separazione renderà tutto più semplice e ridurrà la complessità di dover monitorare mentalmente su quali tabelle si desidera operare.

Answer 5

Non conosco mysql molto bene, ma penso che dovrò dare la risposta standard alle prestazioni - "Dipende".

Alcuni pensieri (che si occupano solo con prestazioni/manutenzione, non la progettazione di database):

• La creazione di un nuovo database si intende un file separato (o file) nel file system. Questi file potrebbero quindi essere messi su diversi filesystem se le prestazioni di una devono essere separate dalle altre, ecc.
• Un nuovo database probabilmente gestirà la memorizzazione nella cache in modo diverso; per esempio. Tutte le tabelle in un DB significheranno una cache condivisa per il DB, mentre dividere le tabelle in database separati significa che ogni database può avere una cache separata [ovviamente tutti i database condivideranno la stessa memoria fisica per la cache, ma potrebbe esserci un limite per database, ecc.].
• In relazione ai file separati, questo significa che se uno dei set di dati diventa più importante degli altri, può essere facilmente portato su un nuovo server.
• La separazione dei database ha un ulteriore vantaggio di consentire di distribuire gli aggiornamenti uno alla volta più facilmente rispetto al singolo database.

Tuttavia, per contrasto, disporre di più database significa che il server probabilmente utilizzerà più memoria (poiché ha più cache). Sono sicuro che ci sono più "contro" per l'approccio multi-database, ma ora sto facendo un vuoto.

Quindi suppongo che consiglierei l'approccio multi-database. Ovviamente questo è solo con la comprensione che potrebbe esserci un modo migliore di "database-design" per gestire qualsiasi cosa tu stia effettivamente facendo.

Answer 6

Date le restrizioni che avete inserito, preferirei far girare più tabelle nel database esistente, piuttosto che dovermi connettere a più database. Gestire le stringhe di connessione TEND è più difficile, oltre a gestire le diverse ottimizzazioni del database che si possono avere.

Answer 7

FTR, in circostanze normali adotterei l'approccio descritto da TheX.

In risposta alla tua domanda specifica, tuttavia, ho trovato che dipende dall'utilizzo. (Uscire, lo so, ma ascoltami.)

Un singolo database è probabilmente più semplice. Dovrai preoccuparti solo di una connessione e dovresti comunque specificare le tabelle. Tuttavia, a determinate condizioni, più database potrebbero essere più veloci.

Se fossi in te, proverei entrambi. Non c'è modo che saremo in grado di darti una risposta utile.

Answer 8

Differire i pool in base al nome di tabella o inserirli in database separati è quasi la stessa cosa. Tuttavia, se ci sono molte tabelle in un database, MySQL deve caricare le informazioni della tabella e fare un controllo di sicurezza su tutte quelle tabelle quando si accede/si collega.

Come già menzionato, database separati consentiranno di spostare le cose e creare ottimizzazioni specifiche per un determinato pool (ad esempio tabelle compresse). È un sovraccarico amministrativo aggiuntivo, ma c'è molta più flessibilità.

Inoltre, è sempre possibile "raggruppare" le tabelle che si trovano in database separati utilizzando le tabelle federate o di unione per semplificare le query, se necessario.

Per quanto riguarda l'esaurimento delle chiavi primarie, è possibile utilizzare sempre una chiave primaria composta se si utilizzano le tabelle MyISAM. Ad esempio, se hai un campo chiamato groupCode (qualsiasi tipo) e un altro chiamato sequenceId (incremento automatico) e crei la tua chiave primaria come groupCode + sequenceId. Il sequenceId verrà incrementato in base al successivo ID univoco all'interno del gruppo di codici del gruppo. Per esempio: AAA 1 AAA 2 BBB 1 AAA 3 CCC1 AAA 4 BBB 2 ...

Anche se con grandi tavoli bisogna stare attenti a caching e assicurarsi che il file system stai usando gestisce file di grandi dimensioni.

Answer 9

Nella situazione che descrivi, l'esperienza mi ha portato a credere che troverai i database separati più veloci quando hai un numero elevato di pool.

C'è un principio generale davvero importante da osservare qui, però: Non pensare a quanto velocemente sarà, profilalo.