A che punto un database MySQL inizia a perdere prestazioni?
Ho quello che credo sia un grande database, con circa 15 milioni di record che occupano quasi 2 GB. Sulla base di questi numeri, c'è qualche incentivo per me a ripulire i dati o sono sicuro di consentirgli di continuare il ridimensionamento per qualche altro anno?
Risposte:
Le dimensioni del database fisico non contano. Il numero di record non ha importanza.
Nella mia esperienza, il problema più grande in cui ti imbatterai non è la dimensione, ma il numero di query che puoi gestire contemporaneamente. Molto probabilmente dovrai passare a una configurazione master / slave in modo che le query di lettura possano essere eseguite sugli slave e le query di scrittura vengano eseguite sul master. Tuttavia, se non si è ancora pronti per questo, è sempre possibile modificare gli indici per le query in esecuzione per accelerare i tempi di risposta. Inoltre ci sono molte modifiche che puoi fare allo stack di rete e al kernel in Linux che ti aiuteranno.
Ho avuto il mio ottenere fino a 10 GB, con solo un numero moderato di connessioni e ha gestito bene le richieste.
Mi concentrerei prima sui tuoi indici, poi guarderò l'amministratore del tuo sistema operativo e se tutto ciò non aiuta potrebbe essere il momento di implementare una configurazione master / slave.
In generale questo è un problema molto sottile e non banale. Ti incoraggio a leggere mysqlperformanceblog.com e MySQL ad alte prestazioni . Penso davvero che non ci sia una risposta generale per questo.
Sto lavorando a un progetto che ha un database MySQL con quasi 1 TB di dati. Il fattore di scalabilità più importante è la RAM. Se gli indici delle tabelle si adattano alla memoria e le query sono altamente ottimizzate, è possibile soddisfare una quantità ragionevole di richieste con un computer medio.
Il numero di record è importante, a seconda dell'aspetto delle tabelle. È una differenza avere molti campi varchar o solo un paio di ints o long.
Anche la dimensione fisica del database è importante: pensate ai backup, per esempio. A seconda del tuo motore, i tuoi file db fisici aumentano, ma non si riducono, ad esempio con innodb. Quindi l'eliminazione di molte righe non aiuta a ridurre i file fisici.
C'è molto in questi problemi e come in molti casi il diavolo è nei dettagli.
Le dimensioni del database sono importanti . Se si dispone di più di una tabella con oltre un milione di record, le prestazioni iniziano effettivamente a peggiorare. Il numero di record ovviamente influisce sulle prestazioni: MySQL può essere lento con tabelle di grandi dimensioni . Se si raggiunge un milione di record, si avranno problemi di prestazioni se gli indici non sono impostati correttamente (ad esempio, nessun indice per i campi in "Istruzioni WHERE" o "Condizioni ON" nei join). Se raggiungi 10 milioni di record, inizierai a riscontrare problemi di prestazioni anche se hai tutti gli indici giusti. Gli aggiornamenti hardware - aggiungendo più memoria e più potenza del processore, in particolare memoria - spesso aiutano a ridurre i problemi più gravi aumentando di nuovo le prestazioni, almeno in una certa misura. Per esempio37 segnali sono passati da 32 GB RAM a 128 GB di RAM per il server di database Basecamp.
Mi concentrerei prima sui tuoi indici, che un amministratore del server guardi il tuo sistema operativo, e se tutto ciò non aiuta potrebbe essere il momento di una configurazione master / slave.
È vero. Un'altra cosa che di solito funziona è semplicemente ridurre la quantità di dati con cui si è lavorato più volte. Se hai "vecchi dati" e "nuovi dati" e il 99% delle tue query funziona con nuovi dati, sposta tutti i vecchi dati in un'altra tabella e non guardarli;)
-> Dai un'occhiata al partizionamento .
È inutile parlare di "prestazioni del database", "prestazioni della query" è un termine migliore qui. E la risposta è: dipende dalla query, dai dati su cui opera, dagli indici, dall'hardware, ecc. Puoi avere un'idea di quante righe verranno analizzate e di quali indici verranno utilizzati con la sintassi EXPLAIN.
2 GB non contano davvero come un database "di grandi dimensioni", ma di dimensioni medie.
Attualmente sto gestendo un database MySQL sull'infrastruttura cloud di Amazon che è cresciuto fino a 160 GB. Le prestazioni della query vanno bene. Ciò che è diventato un incubo sono i backup, i ripristini, l'aggiunta di slave o qualsiasi altra cosa che tratti l'intero set di dati o persino DDL su tabelle di grandi dimensioni. Ottenere un'importazione pulita di un file di dump è diventato problematico. Al fine di rendere il processo abbastanza stabile da automatizzare, sono state fatte varie scelte per dare priorità alla stabilità rispetto alle prestazioni. Se dovessimo mai recuperare da un disastro utilizzando un backup SQL, saremmo inattivi per giorni.
Anche il ridimensionamento orizzontale di SQL è piuttosto doloroso e nella maggior parte dei casi porta a usarlo in modi che probabilmente non intendevi quando hai scelto di mettere i tuoi dati in SQL in primo luogo. Shards, read slave, multi-master, ecc., Sono tutte soluzioni davvero di merda che aggiungono complessità a tutto ciò che fai con il DB e nessuno di loro risolve il problema; lo mitiga solo in qualche modo. Consiglio vivamente di cercare di spostare alcuni dei tuoi dati da MySQL (o in realtà qualsiasi SQL) quando inizi ad avvicinarti a un set di dati di dimensioni in cui questi tipi di cose diventano un problema.
Fai anche attenzione ai join complessi. La complessità delle transazioni può essere un fattore importante oltre al volume delle transazioni.
Il refactoring di query pesanti a volte offre un notevole aumento delle prestazioni.
Una volta fui chiamato a guardare un mysql che aveva "smesso di funzionare". Ho scoperto che i file DB risiedevano in un filer Network Appliance montato con NFS2 e con una dimensione massima del file di 2 GB. E abbastanza sicuro, la tabella che aveva smesso di accettare le transazioni era esattamente 2 GB su disco. Ma per quanto riguarda la curva delle prestazioni mi è stato detto che funzionava come un campione fino a quando non ha funzionato affatto! Questa esperienza mi serve sempre per ricordarmi che ci sono sempre dimensioni sopra e sotto quella che sospetti naturalmente.
Un punto da considerare è anche lo scopo del sistema e dei dati nel quotidiano.
Ad esempio, per un sistema con monitoraggio GPS delle auto non sono rilevanti i dati di query dalle posizioni dell'auto nei mesi precedenti.
Pertanto, i dati possono essere passati ad altre tabelle storiche per una possibile consultazione e ridurre i tempi di esecuzione delle query quotidiane.
Le prestazioni possono peggiorare nel giro di poche migliaia di righe se il database non è progettato correttamente.
Se si dispone di indici adeguati, utilizzare motori adeguati (non utilizzare MyISAM dove sono previsti più DML), utilizzare il partizionamento, allocare memoria corretta a seconda dell'uso e, naturalmente, avere una buona configurazione del server, MySQL può gestire i dati anche in terabyte!
Esistono sempre modi per migliorare le prestazioni del database.
Dipende dalla tua richiesta e convalida.
Ad esempio, ho lavorato con una tabella di 100.000 farmaci che ha un nome generico di colonna in cui ha più di 15 caratteri per ogni farmaco in quella tabella. Ho inserito una query per confrontare il nome generico dei farmaci tra due tabelle. altri minuti per l'esecuzione. Lo stesso, se si confrontano i farmaci utilizzando l'indice dei farmaci, utilizzando una colonna ID (come detto sopra), ci vogliono solo pochi secondi.
Le dimensioni del database sono importanti in termini di byte e numero di righe della tabella. Noterai un'enorme differenza di prestazioni tra un database leggero e uno pieno. Una volta che la mia applicazione si è bloccata perché ho messo le immagini binarie all'interno dei campi invece di tenere le immagini nei file sul disco e mettere solo i nomi dei file nel database. L'iterazione di un gran numero di righe d'altra parte non è gratuita.
No, non importa davvero. La velocità di MySQL è di circa 7 milioni di righe al secondo. Quindi puoi ridimensionarlo un po '
Le prestazioni della query dipendono principalmente dal numero di record di cui deve eseguire la scansione, gli indici svolgono un ruolo importante al suo interno e la dimensione dei dati dell'indice è proporzionale al numero di righe e al numero di indici.
Le query con condizioni di campo indicizzate insieme al valore completo verrebbero restituite in 1 ms in generale, ma con start_with, IN, Between, ovviamente le condizioni potrebbero richiedere più tempo con la scansione di più record.
Inoltre, affronterai molti problemi di manutenzione con DDL, come ALTER, DROP sarà lento e difficile con più traffico in tempo reale anche per l'aggiunta di un indice o nuove colonne.
Generalmente è consigliabile raggruppare il database in tutti i cluster necessari (500 GB sarebbe un punto di riferimento generale, come detto da altri dipende da molti fattori e può variare in base ai casi d'uso) in questo modo fornisce un migliore isolamento e dà indipendenza a specifiche dimensioni cluster (più adatti in caso di B2B)