Partizionamento Tabella MySql

[francescocorr]

Salve a tutti, da 2 anni ho messo su un forum studenti per la mia università. Purtroppo il budget a disposizione è sempre basso e non riesco a fare un upgrade del server dove è hostato il forum.
Il forum è sviluppato con vanilla il server ha un processore xeon 1.8 4gb di ram e 2 dischi che non ricordo cosa siano e in che tipo di raid. Se importante chiedo info all'hosting e le passo.

Ho notato che ci sono delle query che mi occupano un sacco di risorse ed ho visto che l'i/o di queste query è molto alto.
Inoltre ci sono delle query che agiscono pesantemente sulla tabella comments. Avevo pensato di ottimizzarla partizionandola orizzontalmente, voi cosa ne pensate? Posso aiutate in questo modo a ridurre i rallentamenti del server?

Grazie
Frank

[franzauker2.0]

Ovviamente no.
Se per partizionamento intendi il partizionamento mysql, questo è in generale tra le ultime cose da fare, ce ne sono davvero tantissime PRIMA di partizionare (cosa che può determinare facilmente un peggioramento delle prestazioni).

Partizionare bene richiede una conoscenza perfetta (e sottolineo perfetta) non solo del db, ma anche di come viene usato, e di quali siano i colli di bottiglia.

Suggerisco quindi di iniziare, come canonicamente si fa, misurando.

[deleted_a]

Se ci dai qualche info aggiuntiva su eventuali misurazioni lato server.

[franzauker2.0]

Originariamente inviato da deleted_a
Se ci dai qualche info aggiuntiva su eventuali misurazioni lato server.

Bhè ci sono approcci a vari livelli di complessità.
Quello più banale è usare... il cronometro. Io ne uso uno a cristalli liquidi per le gare, pagato mi sembra 5 euro.
Poi attivare lo slow log, con un tempo basso.
L'ideale è utilizzare un RDBMS con granularità e statistiche moooolto più avanzate (es. mariadb, o perfino il server percona, ma tra i due ti consiglio il primo), col quale raccogliere i dati è estremamente più semplice.
Poi c'è la possibilità di mettere un proxy per loggare tutte le query, con il suo programmino LUA da predisporre.
E sempre, ovviamente, al primissimo posto c'è il log a livello applicativo, ovvero la misurazione del tempo di esecuzione delle query (principali) con relativa registrazione sia della query che del tempo.

Dopo aver misurato, e SOLO DOPO aver misurato, si iniza ad esaminare qual'è la struttura del database, e quali query (o combinazioni di esse) agiscono negativamente, per risalire al perchè.
Mancanza di indici? Selettività indici troppo bassa? Lock che vengono posti bloccando gli altri utenti? Transazioni che falliscono spesso miseramente causando rollback frequenti? Ricerche full-scan indebite (tipico like %qualcosa%) ? Mix devastante di aggiornamenti "martellanti" (hammering) su singoli campi di singole tabelle?
Server mysql configurato male? Server mysql buggato (capita, e pure frequentemente) ? Server (inteso come sistema operativo) configurato male per l'uso di mysql? Trigger che essendo eseguiti FOR EACH ROW rompono i maroni? Aggiornamento di indici giganti e inutili al COMMIT?

E soprattutto...
logica sbagliata (o comunque) migliorabile dell'applicazione?

Quello che sconsiglio vivissimamente, come errore classico e canonico, è quello di cominciare pensando di ottimizzare di qua e di là, così a "casaccio", non basandosi invece su elementi misurabili e controllabili.
Tante volte capita che, come effetto collaterale, la correzione X faccia il disastro Y

[francescocorr]

Ciao A tutti e scusatemi ma sono stato fuori per un paio di giorni.

franzauker2.0, grazie per i chiarimenti. Questo week end cerco di studiare un pochino le cose che mi hai elencato e vedo se riesco a mettere in pratica.
Logicamente tutto questo va fatto sul server in produzione oppure su una vps appositamente configurata? Ho paura di combinare qualche guaio sul server dove è ospitato il forum.

Grazie

[franzauker2.0]

Originariamente inviato da francescocorr
Ciao A tutti e scusatemi ma sono stato fuori per un paio di giorni.

franzauker2.0, grazie per i chiarimenti. Questo week end cerco di studiare un pochino le cose che mi hai elencato e vedo se riesco a mettere in pratica.
Logicamente tutto questo va fatto sul server in produzione oppure su una vps appositamente configurata? Ho paura di combinare qualche guaio sul server dove è ospitato il forum.

Grazie

Ovviamente... su quello in produzione.
Perchè è il mix dei lavori che determina i problemi.
Se, per assurdo, hai un singolo utente che lavora in solitaria => non avrai indicazioni rilevanti.

Certo che puoi fare "guai" sul server, benvenuto nel magico mondo di "lavora con delicatezza e fai una buona polizza di RC professionale"

[in the web]

Francesco, se hai usato la terminologia corretta, per partizionamento verticale non intendevi il partizionamento di MySQL ma la divisione di una tabella in due o più tabelle, distribuendo le colonne (non le righe).

Anche questa però è una cosa avanzata... dubito seriamente che il tuo forum ne abbia bisogno, a meno che tu non abbia moltissime connessioni contemporanee!

La prima cosa da fare è ottimizzare i tipi di dati. Non sprecare memoria. Non usare BIGINT per le chiavi primarie (se è sufficiente TINYINT, usalo). Usa CHAR con dimensioni non troppo grandi; dove ti servono dimensioni più grandi, usa TEXT e non VARCHAR. Non usare set di caratteri diversi da UTF-8, e usa la collation di default, così eviti conversioni inutili.

Abilita lo Slow query log e trova le tue query più lente. Usa EXPLAIN, e vedi se usano gli indici, molto probabilmente non li usano o usano indici inefficienti. Evita il filesort.

Se il problema non fosse lì (non so a che livello sei, magari queste cose le davi già per scontate), fai uno SHOW PROFILE.

Se smanetti un po' e cancelli o modifichi grandi quantità di dati, poi usa OPTIMIZE TABLE o almeno ANALYZE (il primo deframmenta una tabella ma può richiedere molto tempo, il secondo aggiorna le informazioni sugli indici).

[franzauker2.0]

Originariamente inviato da in the web
Francesco, se hai usato la terminologia corretta, per partizionamento verticale

E' richiesto ORIZZONTALE

[in the web]

Perché avevo letto verticale??? Boh... vabbè, comunque non fare quella faccina, non è successo niente di brutto.