Quanto può essere grande un database MySQL prima che le prestazioni inizino a peggiorare

Question

A che punto un database MySQL inizia a perdere prestazioni?

• Le dimensioni fisiche del database sono importanti?
• Il numero di record è importante?
• Il degrado delle prestazioni è lineare o esponenziale?

Ho quello che credo sia un database di grandi dimensioni, con circa 15 milioni di record che occupano quasi 2 GB.Sulla base di questi numeri, ho qualche incentivo a ripulire i dati o posso tranquillamente consentire che continuino a crescere ancora per qualche anno?

Answer 1

La dimensione fisica del database non ha importanza.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 sul master.Tuttavia, se non sei ancora pronto per questo, puoi sempre modificare gli indici per le query che stai eseguendo per accelerare i tempi di risposta.Inoltre ci sono molte modifiche che puoi apportare allo stack di rete e al kernel in Linux che ti aiuteranno.

Il mio ha raggiunto i 10 GB, con solo un numero moderato di connessioni e ha gestito bene le richieste.

Mi concentrerei prima sui tuoi indici, poi farei controllare il tuo sistema operativo da un amministratore del server e, se tutto ciò non aiuta, potrebbe essere il momento di implementare una configurazione master/slave.

Answer 2

In generale si tratta di una questione molto sottile e per niente 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 tue tabelle rientrano nella memoria e le tue query sono altamente ottimizzate, puoi servire una quantità ragionevole di richieste con una macchina media.

Il numero di record è importante, a seconda dell'aspetto delle tabelle.È una differenza avere molti campi varchar o solo un paio di int o long.

Anche la dimensione fisica del database è importante:pensa ai backup, per esempio.A seconda del tuo motore, i tuoi file db fisici crescono, ma non si riducono, ad esempio con innodb.Quindi eliminare molte righe non aiuta a ridurre i file fisici.

C'è molto in questi problemi e, come in molti casi, il diavolo è nei dettagli.

Answer 3

La dimensione del database importa.Se hai più di una tabella con più di 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 raggiungi un milione di record, avrai problemi di prestazioni se gli indici non sono impostati correttamente (ad esempio nessun indice per i campi nelle "istruzioni WHERE" o "condizioni ON" nei join).Se raggiungi 10 milioni di record, inizierai ad avere problemi di prestazioni anche se hai tutti gli indici corretti.Gli aggiornamenti hardware - aggiungendo più memoria e più potenza del processore, in particolare memoria - spesso aiutano a ridurre i problemi più gravi aumentando nuovamente le prestazioni, almeno in una certa misura.Per esempio 37 segnali sono passati da 32 GB di RAM a 128 GB di RAM per il server del database Basecamp.

Answer 4

Mi concentrerei prima sui tuoi indici, poi chiederei a un amministratore del server di controllare il tuo sistema operativo e, se tutto ciò non aiuta, potrebbe essere il momento per una configurazione master/slave.

È vero.Un'altra cosa che di solito funziona è semplicemente ridurre la quantità di dati con cui si lavora ripetutamente.Se hai "vecchi dati" e "nuovi dati" e il 99% delle tue query funziona con nuovi dati, sposta semplicemente tutti i vecchi dati in un'altra tabella e non guardarli ;)

-> Dai un'occhiata partizionamento.

Answer 5

2 GB e circa 15 milioni di record sono un database molto piccolo: ne ho eseguiti di molto più grandi su un pentium III(!) e tutto funziona ancora abbastanza velocemente..Se il tuo è lento si tratta di un problema di progettazione del database/applicazione, non di MySQL.

Answer 6

È inutile parlare di "prestazioni del database", "prestazioni delle 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 scansionate e quali indici verranno utilizzati con la sintassi EXPLAIN.

2 GB non contano realmente come un database "grande": sono più di dimensioni medie.

Answer 7

Fai attenzione anche 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 incremento delle prestazioni.

Answer 8

Una volta sono stato chiamato a guardare un mysql che "aveva smesso di funzionare".Ho scoperto che i file DB risiedevano su un filer Network Appliance montato con NFS2 e con una dimensione massima del file di 2 GB.E infatti, il tavolo che aveva smesso di accettare transazioni aveva esattamente 2 GB su disco.Ma per quanto riguarda la curva delle prestazioni, mi è stato detto che ha funzionato come un campione fino a quando non ha funzionato del tutto!Questa esperienza mi serve sempre come un bel promemoria del fatto che ci sono sempre dimensioni sopra e sotto quella che naturalmente sospetti.

Answer 9

Un punto da considerare è anche lo scopo del sistema e i dati nel quotidiano.

Ad esempio, per un sistema con monitoraggio GPS delle auto non è rilevante interrogare i dati relativi alle posizioni dell'auto nei mesi precedenti.

Pertanto i dati possono essere passati ad altre tabelle storiche per un'eventuale consultazione e ridurre i tempi di esecuzione delle query quotidiane.

Answer 10

Attualmente sto gestendo un database MySQL sull'infrastruttura cloud di Amazon che è cresciuto fino a 160 GB.Le prestazioni delle query vanno bene.Ciò che è diventato un incubo sono i backup, i ripristini, l'aggiunta di slave o qualsiasi altra cosa che si occupi dell'intero set di dati o persino del DDL su tabelle di grandi dimensioni.Ottenere un'importazione pulita di un file di dump è diventato problematico.Per rendere il processo sufficientemente stabile da poter essere automatizzato, è stato necessario fare varie scelte per dare priorità alla stabilità rispetto alle prestazioni.Se mai dovessimo riprenderci da un disastro utilizzando un backup SQL, rimarremmo inattivi per giorni.

Anche il ridimensionamento orizzontale di SQL è piuttosto doloroso e nella maggior parte dei casi porta a utilizzarlo in modi che probabilmente non avevi previsto quando hai scelto di inserire i tuoi dati in SQL in primo luogo.Shard, read slave, multi-master e così via, sono tutte soluzioni davvero schifose che aggiungono complessità a tutto ciò che fai con il DB, e nessuno di loro risolve il problema;lo mitiga solo in qualche modo.Suggerirei vivamente di spostare alcuni dei tuoi dati fuori da MySQL (o in realtà da qualsiasi SQL) quando inizi ad avvicinarti a un set di dati di dimensioni in cui questo tipo di cose diventa un problema.

Answer 11

Le prestazioni possono peggiorare nel giro di poche migliaia di righe se il database non è progettato correttamente.

Se disponi di indici adeguati, utilizzi motori adeguati (non utilizzare MyISAM dove sono previsti più DML), utilizza il partizionamento, alloca memoria corretta a seconda dell'uso e, naturalmente, disponi di una buona configurazione del server, MySQL può gestire dati anche in terabyte!

Esistono sempre modi per migliorare le prestazioni del database.

Answer 12

Dipende dalla query e dalla convalida.

Ad esempio, ho lavorato con una tabella di 100.000 farmaci che ha una colonna nome generico composta da più di 15 caratteri per ciascun farmaco in quella tabella. Ho inserito una query per confrontare il nome generico dei farmaci tra due tabelle. La query richiede più minuti per l'esecuzione. Lo stesso, se confronti i farmaci utilizzando l'indice dei farmaci, utilizzando una colonna id (come detto sopra), ci vogliono solo pochi secondi.

Answer 13

La dimensione del database è importante in termini di byte e numero di righe della tabella.Noterai un'enorme differenza di prestazioni tra un database leggero e uno pieno di blob.Una volta la mia applicazione si è bloccata perché ho inserito immagini binarie all'interno dei campi invece di conservare le immagini nei file sul disco e inserire solo i nomi dei file nel database.D'altra parte, l'iterazione di un gran numero di righe non è gratuita.

Answer 14

No, non ha molta importanza.La velocità di MySQL è di circa 7 milioni di righe al secondo.Quindi puoi ridimensionarlo un po'