Dieta pentru masa foto Silvan Mühlemann; blogul s
Instrumentele noastre de supraveghere confirmă situația: Nagios îmi trage telefonul mobil cu un SMS ca o mitralieră. Curba gri care descrie încărcarea serverului în Ganglia este cu mult peste linia roșie. Moreti, instrumentul nostru de măsurare a timpului de răspuns, raportează câteva secunde pentru a furniza o pagină până la final.
O situație bine cunoscută pe care o întâlnim din nou și din nou ca în ultimii șase ani de existență. Există două modalități de a face față acestei situații: mai multă optimizare hardware sau software.
Adăugarea de hardware este o soluție rapidă și ușoară.
INSERT-urile trebuie accelerate
În acest caz, situația este diferită: fotografii care doresc să adauge fotografii pe site sunt cei afectați. Și mai puțin vizitatorii care cer doar fotografii. „Adăugați fotografii” funcționează încet. Prin urmare, acestea sunt instrucțiuni INSERT și nu interogări SELECT. Se adaugă fotografii noi. Deci, rânduri noi ale bazei de date
atașat:
Deoarece lucrăm cu replicarea, aceste rânduri trebuie copiate la toți sclavii. Un INSERT pe sclav. Dacă adăugăm mai multe servere în cluster, acest lucru nu va rezolva problema, deoarece aceste rânduri trebuie adăugate și la aceste noi servere. Mai multe servere nu reduc numărul de INSERT-uri pe cluster. În acest caz, hardware-ul nu va ajuta.
Continuăm să căutăm: INSERTELE cauzează probleme. INSERTELE sunt prea lente. Ce face ca INSERT-urile să fie lente? Ce este scump cu un INSERT? Nu adăugând datele, ci scriind indexurile. Indicii sunt structuri de date complexe, copaci B, copaci binari care trebuie verificate pentru ponderare de fiecare dată când se introduce o linie. Indexurile sunt scumpe.
În cazul tabelului nostru de fotografii, indicii reprezintă chiar mai mulți octeți decât datele (chiar dacă structura noastră de date este amator și plină de redundanță)
Coloane și indexuri inutile!
Așa că am optat pentru indexurile tabelului de imagini. Doamne, ce fel de indici am stabilit în nesăbuința noastră tinerească? Practic, fiecare coloană are un index, deși nu este folosită niciodată într-o interogare (testați cu EXPLAIN SELECT). Există încă coloane acolo care nu sunt niciodată interogate. rău!
Combinați prin 60.000 de linii de cod
Deci: Stefan și cu mine ajungem la dieta tabelului de imagini: Cu grep asupra întregului cod tilllate, verific toate apelurile către tabelul de imagini. Ce indexuri putem șterge? Ce coloane nu mai sunt necesare?
Rezultatul: Avem trei coloane și cinci indici care nu sunt utilizați. Un index complet cu text complet îndrăzneț poate fi alungat într-un tabel separat prin partiționare verticală. Este acesta un motiv pentru a fi mulțumiți, deoarece am găsit atât de mult loc de îmbunătățire? Sau ar trebui să ne supărăm cu privire la puful nostru în sistem?
Nu contează: sâmbătă dimineața la 01:00, Ștefan efectuează declarațiile ALTER TABLE. După două ore de durată a interogării, dieta fulgerului este completă. Rezultatul:
Reducerea fișierului de date cu 22%. Reducerea fișierului index cu 70%. Acest lucru duce la INSERT-uri mai rapide, copii de rezervă mai rapide și TABEL DE REPARAȚII mai rapid (ceea ce este adesea o problemă cu tabelele MyISAM).
În această seară se va arăta dacă va fi mai ușor pentru fotografi să adauge fotografiile. sunt curios.