Newsgroup: it.comp.os.linux.sys
Titolo: MySQL: aumentare la velocità  di scrittura. Come??

La prima cosa che si può essere portati a pensare è quella di usare la 
replica multi-master. E' vero che non ci sono slave e che, mettendo un 
auto_increment_offset diverso per ogni master, si può tranquillamente 
scrivere su ogni nodo in modo simultaneo. Peccato solo che mi è caduto 
l'occhio su questa banale quanto precisa osservazione:
"Both servers have to execute all write statements, whether the write 
statements come directly from clients or come via replication."
Quindi non va bene... anzi, con l'overhead del relay-log, secondo me le 
prestazioni peggiorano!
La replica master-slave e "circular replication" non servono allo scopo.
A questo punto restano, il partitionin orizzontale, il partitioning 
verticale e il merge.
Il merge chiaramente, se si scrive su sotto-tabelle diverse, e si legge 
dalla union, funziona. Però l'applicazione deve essere aware ... o deve 
essere resa tale.
Il partitioning by list e by range velocizza solo le query, perché fa 
operare le select in ambiti più ristretti.
RESTANO QUINDI: il partitioning by KEY e partitioning by HASH, dove key 
e hash sono random, e pertanto la tabella di destinazione diventa 
random. Questo potrebbe anche andar bene.
ho saltato volutamente tutta la parte relativa ai parametri di 
configurazione: bin-log size, buffer_pool-size ... blabla..)
Altre idee, soluzioni?
Qualcuno di voi ha esperienze in questo campo da poter condividere?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 replicazione.
IMHO anche il partitioning c'entra 'na fava.
	Y.

 Chi ha parlato di partitioning
L'OP?


L'OP può sempre sbagliare, però parlava di "partitioning by KEY" e leggo 
che la KEY, nel partitioning by KEY viene calcolata in modo random. E 
che quindi i dati vanno a finire, a random, su partizioni diverse, che 
potranno a loro volta essere distribuite su diversi dischi.
Questa era l'idea.


 il resto non fosse corretto, viste le premesse :P
Correggere? o_O
Veramente ho scritto io steso che la replica non serve a nulla.
Della suddivisione logica ne ho parlato anche io come di una possibile 
soluzione (vedi: merge tables).
E ho parlato di partitioning by KEY e non di partitioning by LIST.
Forse è il caso che ti rileggi il mio messaggio.


Secondo me poni male la domanda.
Intendi in inserimento o in upgrade di un record?
Non sono un grande esperto di MySql (solitamento uso Oracle o DB2), ma 
le INSERT sono on the fly nella stragrande maggioranza dei RDBMS, 
semplicemente fanno append del record nel file/filesystem dedicato alla 
tabella.
Le update dipendono solitamente dagli indici.
Nel primo caso la velocità massima è quella espressa dal fs in uso, che 
dipende dalle caratteristiche dell'hw in uso e dal livello di caching 
dell'OS odel cluster. Puoi clusterizzare quanto vuoi, al massimo 
peggiori la situazione.
Nel secondo caso dipende dall'architettura delle tue tabelle.

 Nel secondo caso dipende dall'architettura delle tue tabelle.
Gli indici, se presenti, sono aggiornati SEMPRE nel caso delle insert, se 
necessario per gli update.
Il caching dell'OS ha di solito poco a che vedere, visto che la maggior 
parte dei DB esegue un fsync (per garantire la presenza dei dati) -
- alla fine di ogni query
- di ogni transazione
- (meno sicuro) ogni tot secondi
- quando lo reputa opportuno nel caso di raw devices (vedi oracle)
Normalmente clusterizzare (multiserver) rallenta tutto di parecchio se si 
è in multi master (perchè le query sincrone attendono l'OK da tutti i 
nodi). 
Rallentano meno se si è in master-slave, ma rallentano comunque.
Comunque hai ragione: clusterizzare rallenta sempre.
Per velocizzare la scrittura si agisce sempre in 3 modi:
- a livello di indici, rimuovendoli quando non necessario e 
ricostruendoli dopo
- utilizzando le transazioni, che sui DB seri prevedono le scritture solo 
a transazione avvenuta (a meno che non sia enorme, nel qual caso si usa 
il disco come spool temporaneo) e configurando il DB per ricalcolare gli 
indici SOLO alla fine di ogni transazione
- Cambiando lo storage sottostante (il FS ha poca importanza) o 
partizionando le tabelle su device differenti.
Dell'ultimo caso non ha alcun senso parlarne [la domanda iniziale 
dell'OP] perchè le ottimizzazioni da fare dipendono fortemente da come si 
utilizzano le tabelle (insert frequenti, update frequenti,  
partizionamento per riga o per altri parametri sempre in base alla 
struttura dei dati ed al loro utilizzo) ed è il vero lavoro del DBA che 
dovrebbe conoscere i dettagli di utilizzazione del suo oggetto.
In conclusione prima si ottimizza *SEMPRE* il database a livello logico e 
a livello dell'applicativo che lo usa (e questa è la fase che può dare 
incrementi percentuali anche con diversi zeri e che di solito nessuno fa 
e pochi sanno fare) [1].
Solo in una seconda fase si fa tuning sullo storage che più di tanto non 
può però migliorare la situazione, a meno che lo storage sostituito non 
sia tecnologicamente molto obsoleto.
[1] Esperienza della settimana scorsa: inserimento di 20M di righe in una 
tabella con diversi indici, diversi lookups e diversi vincoli 
referenziali.
Senza ottimizzazioni T>4GG
Con ottimizzazioni   T<3H

 Sarebbe inutile un syn a fronte di sola lettura, ti pare?
Visto che si parlava di scrittura, non includevo le select, ovviamente.
Mi scuso se l'ho lasciato sottinteso.


Per stavolta.....:-)

 partizionando le tabelle su device differenti.
4. utilizzando, anzichè tanti singoli statement INSERT INTO...VALUES...,
gli statement proprietari forniti dal DBMS per ottimizzare gli
inserimenti massivi, es. COPY in PostgreSQL oppure FORALL in Oracle.
	Y.

 Con ottimizzazioni   T<3H
spero di poter ottenere lo stesso risultato :(


 Nel secondo caso dipende dall'architettura delle tue tabelle.
eh... si fa preso a dire "le mie tabelle" :-)
E' una applicazione sviluppata da terzi. I soliti terzi che ti fanno una 
cosa, te la vendono e spariscono ancora prima che cia sia il go-live del 
prodotto.
Che ci sia un problema nell'architettura delle tabelle, ci metto la mano 
sul fuoco.


 Sì è successo anche a me. Da 4 giorni a 2 ore.
Ecco.
Perchè non venite tutti è due da me una giornata a darmi una manina? :)
Il problema che ho davanti è proprio questo.



Basta pagare.


Sono INSERT o UPDATE (o DELETE)?
Se fossero INSERT, controlla come è stato fatto il TABLESPACE.
Toglimi questa curiosità..INSERT o UPDATE? Incomincio a pensare che 
MySQL non sia poi così performante.

 device, e invece è un comunissimo ext3.
Le partizioni usano tutte FS specifici? O sono su file? Nella seconda 
ipotesi il tuo sistema è lento per natura.
Sia chiaro che per un sistema partizionato occorre avere HW giustamente 
dimensionato e primitive di emulazione attivate.
Tieni conto poi che i normali SATA non sono proprio adatti all'utilizzo 
contemporanea da pià partizioni. Il collo di bottiglia può essere questo.


 MySQL non sia poi così performante.
La mia personalissima palla di cristallo mi dice che non sono 
propriamente bulk insert (pure se il risultato è quello).
Sono procedure di importazione che alla fine inseriscono parecchia roba, 
ma sono intervallate da diverse select fatte a cazzo e implementate col 
codice scritto da un neolaureato che in teoria sa tutto, ma un pratica 
non sa un cazzo. 
Già visto decine di volte.
Mysql per le insert "bulk" è piuttosto veloce.
Come tutti i DB, però, è veloce in proporzione all'intelligenza ed 
all'esperienza di chi ha scritto il programma che lo utilizza.

 questo.
Queste sono cose facilmente verificabili che un DBA dovrebbe saper 
diagnosticare al volo, facendo 500K insert in una tabella usa e getta, da 
uno o più script contemporaneamente.
Il lato HW è l'ultimo che si prende in considerazione.

 non sa un cazzo.
Animale molto frequente nella fauna attuale


Basta testare la velocità di scittura su din un file di testo.
Mi riferivo al fatto che è sempre più frequente incontrare aziende che 
si sono costruite un bel web server midrange disegnate da uno stagista 
convinte di avere il meglio della tecnologia. Poi si scopre che il 
cluster è stato costruito su architetture non adatte a carichi di lavoro 
concorrenti, semplicemente chi si è adoperato conosceva solo quello che 
vende il negozio on line preferito.


eehh ... pagare. Pensavo lo avreste fatto per la gloria ^_^


 non sa un cazzo.
that's possible.


 contemporanea da pià partizioni. Il collo di bottiglia può essere questo.
non è SATA, non è SAS. Attached storage dedicat a MySQL.
Le prestazioni comunque sono state portate a livelli di decenza.


 Il lato HW è l'ultimo che si prende in considerazione.
Si, ma c'erano problemi enormi, che sono saltati subito all'occhio. 
Tipo, la copia di un file, sul mio netbook era parecchio più veloce...
Pertanto si è resa necessaria la migrazione dell'hardware senza se e 
senza ma.


 vende il negozio on line preferito.
Le cose stanno così:
- l'applicazione è stata scritta da terzi e rifilata alla azienda. Non 
appena l'applicazione è stata rifilata e le fatture sono state 
incassate, i "terzi" si sono defilati.
- l'hardware era stato progettato da non so chi. Purtroppo sono host 
vmware, che normalmente performano abbastanza male, e lo storage che era 
stato usato in test, funzionava meglio di quello usato in produzione.


 dettagli, info sull'architettura e non mi sono stati forniti.
Bè.....guarda dentro la shell no?


Il 27/08/2010 14.49, Max_Adamo ha scritto:
 > - l'hardware era stato progettato da non so chi. Purtroppo sono host
 > vmware, che normalmente performano abbastanza male, e lo storage che era
 > stato usato in test, funzionava meglio di quello usato in produzione.
 >
Allora:
Ottimizzazione Logica. Prima cosa che devi fare.
1- cerca di capire come è fatta stà procedura. Quali tabelle usa. COme 
le popola (insert, update, o  raw data utility)
2- se sono update, cerca di capire se si possono migliorare indici
3- se sono insert, cerca di capire se una indici (ma sostanzialemente 
non credo)
4- se è raw data utility, cerca di capire se la shell 
ripara/ricondiziona l'indice dopo l'inserimento. E lavora sempr sull'indice.
5- l'ottimizzazione di un processo db, a volte, non nè semplice nè assoluto
Da quello che tu mi dici, incomincio seriamente a pensare che qualcuno 
vi abbia rifilato una sola...ripero, non basta usare vmware per fare un 
server multipartizione serio, occorre andare oltre il SATA. So che 
sembra professinaaele parlare di clustering e similia, so che ne hanno 
parlato tanto su PC professionale, blogo et similia. So che molti baldi 
ggiavvani ne parlano in autobus. Ma leggere articoli non significa 
davvero costruire server.
Ricordate che una fornitura ha una garanzia di un anno. Se non è 
confacente ai requisiti scritti il fornitore deve adoperarsi per 
sistemare la situazione.
Per orientarsi. Quanti record ha il db? Quanti record movimenta al giorno?
Se intuisco il giusto state usando l'hw di un PC Desktop per gestire un 
DB server. Il che va bene se è un sito domestico.


sono architetture multi-nodo.
mi servono info più precise su tutta la architettura, da dove arrivano 
questi dati e come. Non si svolge tutto su quell'host.
so che c'è un memcached di qua, dei webserver di la.... mi è stato detto 
genericamente "ci sono dei polling che vengono accumulati e indi caricat 
sul db".
- è il webserver che fa questo lavoro?
- non è che facendo scritture multiple si crea una sorta di loop con 
memcached?


 davvero costruire server.
per il momento ri rispondo solo su questo.
- Non c'è SATA. Si sono storage, di buon livello.
- Purtroppo il trend attuale (che secondo me è pessimo) suggerisce di 
usare vmware, che IMHO non performa benissimo. Ma l'azienda usa vmware 
"massivamente". Quindi questo non fa parte delle cose che ci hanno 
rifilato. IMHO con Xen a KVM, spendevano meno, e performavano meglio.
- non mancano cluster e ne abbiamo di tutti i colori: da serviceguard, a 
veritas, a redhat cluster. Normalmente si tratta di configurazioni 
failover, con uno storage che viene switchato sul nodo attivo. Sui 
Solaris si utilizza la tecnica di switchare direttamente tutta la zona.
Non so se si è capito, ma questa non è l'azienda pico pallino, con i 
blade della Dell da 700 euro e i dischi SATA sottomarca.



Su di un altro NW c'era un tizio che parlava di linguaggi moederni. Mi 
sa che hai sotto un server moderno...
Cmq memcached non significa un beneamato cazzo.
Scusami se te lo dico, te lo dico con MOLTO E REALE AFFETTO PERCHE' MI 
RICORDI ME 20 ANNI FA, ma tu non sai fare le domande giuste.
Se qualcuno mi chiamava un memcached anni fa  mi impressionavo, adesso 
gli piglio la testa e gliela sbatto sulla parete.
Chi ti sta parlando non ha la minima idea di quello che sta usando. 
Multinodo (altra parola che non dice un cazzo) o no, il carico dati 
avviene in qualche modo
E' automatico?
- o via shell, ogni nodo fa girare una shell? Guarda nella crontab della 
user di gestione del db, o di root
- anche via webserver, di per se uno può lanciare una script periodica 
se è particolarmente fesso
E' a richiesta?
- anche via web page, di per sè. Posso nascondere una script di carico 
massivo anche  dentro una pagina utente, se sono particolarmente bastardo.
Cmq, guardati in giro. Richiedi documentazione. E ricorda che chi 
installa un sistema poi ne risponde. Preparatevi a richiamare il 
fornitore minacciandogli causa civile.


Scommetto (mi dò 3 a 1) che è una nota TLC-ISP. E spero di sbagliare, 
altrimeti avrei una TLC che usa il MySQL al posto di oracle (a meno che 
non sia un db poco importante)
Il WMWARE non è un problema.
Spero che l'interfaccia tra server e gli storage non sia la rete. Vero?
Ti rimane lo studio sulla logica del db. Che è il più importante, come 
ben ricordi.

 dettagli, info sull'architettura e non mi sono stati forniti.
Beh, direi che hai la risposta: "Le performance non possono essere 
migliorate in quanto non e` stata ricevuta alcuna informazione relativa 
all'architettura dell'applicativo"
Enrico

 fornitore minacciandogli causa civile.
Questo ha già più senso.... :)
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di 
discussione"


infatti ... trattandosi di una attività messa in sospeso da diversi 
mesi, sarebbe stato più opportuno rigettarla.


 ben ricordi.
in ultima analisi: YES.
