[MySQL] Prestazioni

[nikynik1980]

Ciao Ragazzi...
qualcuno di voi sa dirmi se posso riscontrare dei problemi su db mysql dovuti ad una grande mole di dati...
si parla di milioni di record! si potrebbe arrivare anche alla centinaia di milioni di record.

La mia domanda è... che limiti devo impostare per poi non avere problemi di lentezza durante le interrogazioni su db con una elevata quantità di dati..
faccio un esempio...

superati i 3 Milioni di record, i successivi record vengono scritti su un db gemello... ecc...
ci sono problemi sulle tabelle... ?

dalle ricerche effettuate ho notato che i limiti sono dovuti al O.S. piuttosto che al Db...

avete consigli da darmi su questo argomento?.

Grazie

[Dascos]

Originariamente inviato da nikynik1980
Ciao Ragazzi...
qualcuno di voi sa dirmi se posso riscontrare dei problemi su db mysql dovuti ad una grande mole di dati...
si parla di milioni di record! si potrebbe arrivare anche alla centinaia di milioni di record.

La mia domanda è... che limiti devo impostare per poi non avere problemi di lentezza durante le interrogazioni su db con una elevata quantità di dati..
faccio un esempio...

superati i 3 Milioni di record, i successivi record vengono scritti su un db gemello... ecc...
ci sono problemi sulle tabelle... ?

dalle ricerche effettuate ho notato che i limiti sono dovuti al O.S. piuttosto che al Db...

avete consigli da darmi su questo argomento?.

Grazie

Il primo consiglio che ti posso dare è: ottimizza il server mysql e non risparmiare sull'hardware. Dischi veloci (magari in radi 10), processore multiplo (almeno 6 core) e tanta ma tanta Ram (minimo 4 Gb)
Secondo: ottimizza gli indici e le query. Evita nel modo più assoluto delle full table scan
Terzo: esegui SEMPRE un explain sulle query per verificare che gli indici siano usati correttamente
Quarto: usa le query cache, molto importanti per queste moli di dati
Quinto: indici SOLO numerici, se possibile, e campi di testo (char, varchar, text ecc) alla fine della tabella

Se proprio vogliamo fare "gli sboroni", si può pensare a un clustering o alla suddivisione delle tabelle su più dischi fisici (tipo un SAN dedicato ben fatto per intenderci), ma dipende molto da quanto è il budget e/o il "parco macchine".

[nikynik1980]

ti ringrazio...

[deleted_29]

Originariamente inviato da Dascos
Il primo consiglio che ti posso dare è: ottimizza il server mysql e non risparmiare sull'hardware. Dischi veloci (magari in radi 10), processore multiplo (almeno 6 core) e tanta ma tanta Ram (minimo 4 Gb)
Secondo: ottimizza gli indici e le query. Evita nel modo più assoluto delle full table scan
Terzo: esegui SEMPRE un explain sulle query per verificare che gli indici siano usati correttamente
Quarto: usa le query cache, molto importanti per queste moli di dati
Quinto: indici SOLO numerici, se possibile, e campi di testo (char, varchar, text ecc) alla fine della tabella

Se proprio vogliamo fare "gli sboroni", si può pensare a un clustering o alla suddivisione delle tabelle su più dischi fisici (tipo un SAN dedicato ben fatto per intenderci), ma dipende molto da quanto è il budget e/o il "parco macchine".

I miei consigli invece sono molto diversi.
Iniziamo col distinguere gli aspetti "bruti" da quelli "intelligenti".
Bruti:mysql non scala orizzontalmente (questo non è del tutto vero per mysql 5.5). Inutili quindi 10000 core, ogni query è eseguita su un singolo core.
Meglio un core veloce che 6 meno veloci

Riguardo ai dischi, dipende dalla tipologia di dischi.
SAN? non è detto, spesso si introduce una latenza che in certi casi è deleteria.
RAM, anche qui dipende dal carico
Cache: dipende dalla possibilità di essere usata (dati e indici per innodb, solo indici per isam)
Clustering etc: non servono a nulla, o meglio richiedono l'uso di un engine specifico che è parecchio diverso da quelli "standard".
Configurazioni master-slave: dipende dal mix di letture-scritture. Le letture si possono fare in parallelo, anche round robin, le scritture no

---
Lato "utilizzo".
Table scan? Vanno benissimo, se la selettività degli indici è bassa
Indici? vanno benissimo, se possono essere usati. Talvolta sono inutili, anzi dannosi
Query cache: come sopra. Talvolta utile, talvolta dannosa
Indici numerici: non è detto siano la scelta migliore
---
Lato "applicazione":
partizionamento logico: buono e giusto, se ha un senso
partizionamento di mysql: buono e giusto, se ha un senso
evitare statistiche al volo: dipende dai casi
data mart: analizzare con cura
(...)

In sintesi hai posto una domanda che è strettamente legata sia alla base di dati, sia alle applicazioni, sia all'utilizzo.
Non esiste una risposta universalmente valida.

Ci sono una serie di suggerimenti "in generale" validi, ma quelli che fanno la differenza (ossia una query che gira in 10 secondi o 10 millisecondi) richiedono "il fosforo" (e l'esperienza).

Con la "forza bruta" vai veramente poco lontano, nel mondo dei db "seri"


Ecco perchè, per inciso, ci sono professionisti che si fanno pagare profumatamente proprio per esaminare situazioni come questa.

[nikynik1980]

certamente hai ragione... i professionisti si occupano proprio di questo... e sicuramente saprebbero fornirmi una soluzione efficace!...

naturalmente se avessi avuto la possibilità di rivolgermi a loro... non avrei fatto quella domanda :-)

...
hai ragione anche sulla tipologia di domanda da me fatta... poco specifica, in questo modo le risposte potrebbero essere svariate, ognuna giusta, ma poco efficaci con il problema in questione.

detto questo vi ringrazio per la collaborazione!...

l'intento era solo quello di avere più Idee...

se ho una idea e la condivido con te, avremo 2 idee... quindi 2 possibilità...

[deleted_29]

Originariamente inviato da nikynik1980
certamente hai ragione... i professionisti si occupano proprio di questo... e sicuramente saprebbero fornirmi una soluzione efficace!...

naturalmente se avessi avuto la possibilità di rivolgermi a loro... non avrei fatto quella domanda :-)

bhè mi occupo proprio di questo da più di 20 anni, come vedi c'è anche chi risponde... gratuitamente

[nikynik1980]

era chiaro che ti occupassi di questo!... e ti ringrazio!