Diéta a fotóasztalhoz Silvan Mühlemann; s blog
Felügyeleti eszközeink megerősítik a helyzetet: Nagios SMS-lel lő a mobilomra, mint egy géppuska. A Ganglia szerverterhelését leíró szürke görbe jóval a piros vonal felett van. A Moreti, a válaszidő mérésére szolgáló eszközünk néhány másodpercről számol be, hogy egy oldallapot hozzon létre.
Egy jól ismert helyzet, amellyel újra és újra találkozhatunk, mint létezésünk utolsó hat évében. Kétféle módon lehet kezelni ezt a helyzetet: több hardver vagy szoftver optimalizálás.
A hardver hozzáadása gyors és egyszerű megoldás.
A beszúrásokat fel kell gyorsítani
Ebben az esetben más a helyzet: az érintettek azok a fotósok, akik fotókat akarnak felvenni a weboldalra. És kevesebb a látogató, aki csak fotókat kér. A „Fotók hozzáadása” lassan működik. Ezek tehát INSERT utasítások, és nem SELECT lekérdezések. Új fotók kerülnek hozzá. Tehát az adatbázis új sorai
csatolt:
Mivel replikációval dolgozunk, ezeket a sorokat át kell másolni az összes rabszolgára. Rabszolgánként egy INSERT. Ha további kiszolgálókat veszünk fel a fürtbe, ez nem oldja meg a problémát, mivel ezeket a sorokat is hozzá kell adni ezekhez az új kiszolgálókhoz. Több kiszolgáló nem csökkenti az INSERT-ek számát a fürtön. Ebben az esetben a hardver nem segít.
Folyamatosan nézzük: a BETÖLTÉSEK problémákat okoznak. A BETÖLTÉSEK túl lassúak. Mi teszi lassúvá az INSERT-eket? Mi drága egy INSERT-mel? Nem az adatokat, hanem az indexeket írja. Az indexek összetett adatszerkezetek, B-fák, bináris fák, amelyeket minden sor beillesztésekor ellenőrizni kell a súlyuk miatt. Az indexek drágák.
A fotótáblázatunk esetében az indexek még több bájtot alkotnak, mint az adatok (annak ellenére, hogy adatstruktúránk amatőr és tele van redundanciával)
Felesleges oszlopok és indexek!
Tehát a képek táblázatának indexeit kerestük. Istenem, milyen mutatókat állapítottunk meg fiatalos vakmerőségünkben? Gyakorlatilag minden oszlopnak van indexe, bár soha nem használják lekérdezésben (teszt az EXPLAIN SELECT-tel). Még mindig vannak olyan oszlopok, amelyekről soha nem kérdeznek le. gonosz!
Fésülje át 60 000 sornyi kódot
Tehát: Stefan és én elkezdjük a képtábla-diétát: A teljes tilllate kód feletti greppeléssel ellenőrizem az összes hívást a képtáblához. Mely indexeket törölhetjük? Mely oszlopokra már nincs szükség?
Az eredmény: Három oszlopunk és öt indexünk van, amelyeket nem használunk. Egy különösen merész teljes szövegű index vertikális particionálással külön táblázatba számolható. Ez ok az elégedettségre, mivel annyi fejlődési lehetőséget találtunk? Vagy haragudnunk kell a rendszer puffadásunkra?
Nem számít: szombat reggel 01:00 órakor Stefan végrehajtja az ALTER TABLE utasításokat. Két órás lekérdezés után a villámdiéta teljes. Az eredmény:
Az adatállomány 22% -os csökkentése. Az indexfájl 70% -os csökkentése. Ez gyorsabb INSERT-ekhez, gyorsabb biztonsági mentésekhez és gyorsabb TÁBLÁZAT JAVÍTÁShoz vezet (ami gyakran probléma a MyISAM táblákkal).
Ma este megmutatja, hogy a fotósoknak könnyebb-e hozzáadniuk a fényképeket. Kíváncsi vagyok.