Peteris Zaicevas yra bendrovės įkūrėjas ir generalinis direktoriusPercona.
Vienas iš būdų, kaip mes matuojame programas, yra našumas. Viena iš programos našumo metrikų yra vartotojo patirtis, kuri paprastai reiškia „ar vartotojui reikėjo laukti ilgiau nei pagrįstą laiką, kad gautų tai, ko norėjo“.
Ši metrika skirtingais atvejais gali reikšti skirtingus dalykus. Apsipirkimo mobiliesiems programoje atsakymo laikas negali būti ilgesnis nei pora sekundžių. Darbuotojo ŽI puslapyje atsakymams gali prireikti kelių sekundžių daugiau.
Turime daug tyrimų, kaip našumas veikia vartotojo elgseną:
- Mažiau tikėtina, kad 79 proc. Klientų grįš į lėtą svetainę
- 47 procentai vartotojų tikisi, kad tinklalapis bus įkeltas per 2 sekundes ar mažiau
- 40 procentų vartotojų palieka svetainę, jei jos įkėlimas trunka ilgiau nei tris sekundes
- Vieną sekundę atidėjus puslapio įkėlimo laiką konversija gali sumažėti 7 proc., O puslapių peržiūrų - 11 proc
Nepriklausomai nuo standarto, būtina išlaikyti gerą programų našumą. Priešingu atveju vartotojai skundžiasi (arba dar blogiau, eikite į kitą programą). Vienas iš veiksnių, turinčių įtakos programos našumui, yra duomenų bazės našumas. Sąveika tarp programų, svetainių ir duomenų bazių yra labai svarbi nustatant programų našumo lygį.
Pagrindinis šios sąveikos komponentas yra tai, kaip programos pateikia duomenų bazės užklausas ir kaip duomenų bazė reaguoja į užklausas. Bet kokiu atveju „MySQL“ yra viena populiariausių duomenų bazių valdymo sistemų. Daugiau įmonių persijungia „MySQL“ (ir kitas atvirojo kodo duomenų bazes) kaip į duomenų bazės sprendimą savo gamybos aplinkoje.
Yra daugybė „MySQL“ konfigūravimo metodų, kurie gali padėti užtikrinti, kad jūsų duomenų bazė greitai atsakytų į užklausas ir sumažintų minimalų programos našumą.
Toliau pateikiami keli esminiai patarimai, padėsiantys optimizuoti „MySQL“ duomenų bazės našumą.
„MySQL“ optimizavimo raktas Nr. 1: sužinokite, kaip naudoti PAAIŠKINKITE
Du svarbiausi sprendimai, kuriuos darote naudodami bet kokią duomenų bazę, yra projektavimas, kaip ryšiai tarp programų objektų susiejami su lentelėmis (duomenų bazės schema), ir planavimas, kaip programos gauna reikalingus duomenis jiems reikalingu formatu (užklausos).
Sudėtingos programos gali turėti sudėtingas schemas ir užklausas. Jei norite gauti našumą ir mastą, kurio reikalauja jūsų programos, galite ne tik pasikliauti intuicija, kad suprastumėte, kaip bus vykdomos užklausos.
Užuot spėlioję ir tikėdamiesi, turėtumėte išmokti naudotis PAAIŠKINKITE komandą. Ši komanda parodo, kaip bus vykdoma užklausa, ir suteikia supratimą apie tai, kokio našumo galite tikėtis, ir tai, kaip užklausa bus keičiama keičiantis duomenų dydžiui.
Yra daugybė įrankių, tokių kaip „MySQL Workbench“, kurie gali vizualizuoti PAAIŠKINKITE jums, bet vis tiek turite suprasti pagrindus, kad tai suprastumėte.
Yra du skirtingi formatai, kuriais PAAIŠKINKITE komanda pateikia išvestį: senamadišką lentelės formatą ir modernesnį, struktūrizuotą JSON dokumentą, kuriame pateikiama žymiai daugiau informacijos (parodyta žemiau):
mysql> paaiškinti formatą = json pasirinkite sgtest1, kur ID yra nuo 1000 iki 2000 \ G, vidurkį (k)**************************** 1 eilutė ******************** *******
PAAIŠKINTI: {
„Query_block“: {
„Select_id“: 1,
„Cost_info“: {
„Query_cost“: „762,40“
„Stalas“: {
„Table_name“: „sbtest1“,
„Access_type“: „diapazonas“,
„Įmanoma_klavišai“: [
„PIRMINIS“
],
„Raktas“: „PAGRINDINIS“,
„Used_key_parts“: [
„Id“
],
„Key_length“: „4“,
„Rows_examined_per_scan“: 1874 m.
„Rows_produced_per_join“: 1874 m.
„Filtruotas“: „100,00“,
„Cost_info“: {
„Read_cost“: „387.60“,
„Eval_cost“: „374,80“,
„Prefix_cost“: „762,40“,
„Data_read_per_join“: „351 000“
},
„Used_columns“: [
„Id“,
„K“
],
„Attach_condition“: „(„ sbtest “.„ Sbtest1 “.„ Id “tarp 1000 ir 2000)“
}
}
}
Vienas komponentas, į kurį turėtumėte atkreipti dėmesį, yra „užklausos kaina“. Užklausos kaina nurodo, kokia brangi „MySQL“ vertina šią konkrečią užklausą pagal bendrą užklausos vykdymo kainą, ir pagrįsta daugeliu skirtingų veiksnių.
Paprastų užklausų užklausos kaina paprastai yra mažesnė nei 1 000. Užklausos, kurių kaina yra nuo 1 000 iki 100 000, laikomos vidutinės kainos užklausomis ir paprastai yra greitos, jei vykdote tik šimtus tokių užklausų per sekundę (ne keliasdešimt tūkstančių).
Užklausos, kurių kaina didesnė nei 100 000, yra brangios užklausos. Dažnai šios užklausos vis tiek bus vykdomos greitai, kai sistemoje esate vienas vartotojas, tačiau turėtumėte gerai pagalvoti, kaip dažnai tokias užklausas naudojate interaktyviose programose (ypač kai auga vartotojų skaičius).
Žinoma, tai yra „Ballpark“ pasirodymų skaičiai, tačiau jie parodo bendrą principą. Jūsų sistema gali geriau ar blogiau tvarkyti užklausų darbo krūvius, atsižvelgiant į jos architektūrą ir konfigūraciją.
Pagrindinis veiksnys, lemiantis užklausos kainą, yra tai, ar užklausa tinkamai naudoja indeksus. PAAIŠKINKITE komanda gali pasakyti, ar užklausoje nenaudojami indeksai (dažniausiai dėl to, kaip indeksai kuriami duomenų bazėje, arba kaip sukurta pati užklausa). Štai kodėl taip svarbu išmokti naudotis PAAIŠKINKITE.
„MySQL“ optimizavimo raktas Nr. 2: sukurkite tinkamus indeksus
Indeksas pagerina užklausos našumą sumažindamas duomenų kiekį duomenų bazėje, kurią turi nuskaityti užklausos. „MySQL“ indeksai naudojami norint pagreitinti prieigą prie duomenų bazės ir padėti įgyvendinti duomenų bazės apribojimus (pvz., UNIKALUS ir SVETIMAS RAKTAS).
Duomenų bazių indeksai yra panašūs į knygų indeksus. Jie laikomi savo vietoje ir juose yra informacijos, esančios jau pagrindinėje duomenų bazėje. Tai yra pamatinis metodas arba žemėlapis, kuriame yra duomenys. Indeksai nekeičia jokių duomenų bazėje esančių duomenų. Jie tiesiog nurodo duomenų vietą.
Nėra indeksų, kurie visada tinka bet kokiam darbo krūviui. Visada turėtumėte pažvelgti į rodykles sistemos vykdomų užklausų kontekste.
Gerai indeksuotos duomenų bazės veikia ne tik greičiau, bet net ir viena trūkstama rodyklė gali sulėtinti duomenų bazės tikrinimą. Naudokite PAAIŠKINKITE (kaip rekomenduota anksčiau) rasti trūkstamus indeksus ir juos pridėti. Tačiau būkite atsargūs: nepridėkite indeksų, kurių jums nereikia! Nereikalingi indeksai lėtina duomenų bazių veikimą (peržiūrėkite mano pristatymą apie „MySQL“ geriausios indeksavimo praktikas).
„MySQL“ optimizavimo raktas Nr. 3: Numatytųjų nėra!
Kaip ir bet kurioje programinėje įrangoje, „MySQL“ turi daug konfigūruojamų nustatymų, kuriuos galima naudoti modifikuojant elgesį (o galiausiai ir našumą). Kaip ir bet kurią programinę įrangą, daugelį šių konfigūruojamų nustatymų administratoriai ignoruoja ir galiausiai naudoja numatytuoju režimu.
Kad gautumėte geriausią „MySQL“ našumą, svarbu suprasti konfigūruojamus „MySQL“ nustatymus ir, dar svarbiau, nustatyti juos geriausiai veikti jūsų duomenų bazės aplinkoje.
Pagal numatytuosius nustatymus „MySQL“ yra pritaikytas nedidelio masto kūrimo diegimui, o ne gamybos mastui. Paprastai norite sukonfigūruoti „MySQL“, kad jis naudotų visus turimus atminties išteklius ir leistų jūsų programai reikalingų jungčių skaičių.
Čia yra trys „MySQL“ derinimo parametrai, kuriuos visada turėtumėte atidžiai išnagrinėti:
innodb_buffer_pool_size: Buferio telkinyje laikomi duomenys ir indeksai. Tai yra pagrindinė priežastis, kodėl jūsų duomenų bazės serveryje naudojama sistema su dideliu RAM kiekiu. Jei naudojate tik „InnoDB“ saugyklos variklį, maždaug 80 procentų atminties paprastai skiriate buferio telkiniui. Jei vykdote labai sudėtingas užklausas arba turite labai daug lygiagrečių duomenų bazių jungčių arba turite labai daug lentelių, gali reikėti šią vertę sumažinti žemyn, kad paskirtumėte daugiau atminties kitiems tikslams.
Nustatydami „InnoDB“ buferio telkinio dydį, turite įsitikinti, kad jo nenustatėte per daug, nes tai sukels keitimą. Tai visiškai užmuša jūsų duomenų bazės našumą. Paprastas būdas patikrinti yra „Percona Monitoring and Management“ sistemos apžvalgos grafiko pažvelgti į „Sukeisti veiklą“:
PerconaKaip rodo ši diagrama, kai kurie apsikeitimai yra puikūs taip dažnai. Jei vis dėlto matote ilgalaikę 1 MB ar daugiau sekundės keitimo veiklą, turėsite sumažinti buferio telkinio dydį (ar kitą atminties naudojimą).
Jei negaunate vertės innodb_buffer_pool_size teisingai iš pirmo karto, nesijaudinkite. Pradėdami nuo „MySQL 5.7“, dinamiškai galite pakeisti „InnoDB“ buferio telkinio dydį, nepaleidę duomenų bazės serverio iš naujo.
innodb_log_file_size: Tai yra vieno „InnoDB“ žurnalo failo dydis. Pagal numatytuosius nustatymus „InnoDB“ naudoja dvi reikšmes, kad galėtumėte padvigubinti šį skaičių, kad gautumėte apvalaus perdarymo žurnalo, kurį „InnoDB“ naudoja, kad jūsų operacijos būtų patvarios, dydį. Tai taip pat optimizuoja duomenų bazės pakeitimų taikymą. Nustatymas innodb_log_file_size yra kompromisų klausimas. Kuo didesnę pertvarkymo vietą skirsite, tuo geresnį našumą pasieksite užimdami daug rašymo, bet tuo ilgiau sugedus bus atkurta, jei jūsų sistema neteks energijos ar atsiras kitų problemų.
Kaip sužinoti, ar „MySQL“ našumą riboja dabartinis „InnoDB“ žurnalo failo dydis? Galite pasakyti pažiūrėję, kiek iš tikrųjų sunaudojama naudingo perdaryti žurnalo vietos. Lengviausias būdas yra pažvelgti į „Percona Monitoring and Management InnoDB Metrics“ informacijos suvestinę. Žemiau pateiktame grafike „InnoDB“ žurnalo failo dydis nėra pakankamai didelis, nes naudojama erdvė priartėja prie to, kiek galima naudoti pertvarkymo žurnalo vietos (nurodoma raudona linija). Jūsų žurnalo failo dydis turėtų būti bent 20 procentų didesnis nei vietos, naudojamos jūsų sistemai optimaliai veikti, kiekis.
Perconamax_connections: Didelio masto programoms dažnai reikia daug daugiau nei numatytasis jungčių skaičius. Skirtingai nuo kitų kintamųjų, jei neteisingai nustatysite tai, neturėsite našumo problemų (per se). Vietoj to, jei jūsų programų poreikiams nepakanka jungčių, jūsų programa tiesiog negalės prisijungti prie duomenų bazės (o tai jūsų vartotojams atrodo prastova). Šį kintamąjį gauti yra svarbu.
Gali būti sunku žinoti, kiek jungčių reikia sudėtingoms programoms su daugybe komponentų, veikiančių keliuose serveriuose. Laimei, „MySQL“ leidžia labai lengvai pamatyti, kiek jungčių naudojama maksimaliai veikiant. Paprastai norite užtikrinti, kad tarp maksimalaus jūsų programos naudojamų jungčių skaičiaus ir maksimalaus galimo jungčių skaičiaus būtų bent 30 procentų skirtumas. Lengvas būdas peržiūrėti šiuos skaičius yra „MySQL Connections“ diagramos naudojimas „MySQL apžvalgos“ informacijos suvestinėje „Percona Monitoring and Management“. Žemiau pateiktame grafike parodyta tinkama sistema, kur yra daugybė papildomų jungčių.
PerconaReikia nepamiršti, kad jei jūsų duomenų bazė veikia lėtai, programos dažnai sukuria per daug ryšių. Tokiais atvejais turėtumėte dirbti su duomenų bazės našumo problema, o ne paprasčiausiai leisti daugiau ryšių. Daugiau ryšių gali pabloginti pagrindinę našumo problemą.
(Pastaba: kai nustatote max_connections kintamasis yra žymiai didesnis už numatytąją vertę, dažnai turite apsvarstyti galimybę padidinti kitus parametrus, pvz., lentelės talpyklos dydį ir „MySQL“ leidžiamų atidaryti failų skaičių. Tačiau tai peržengia šio straipsnio taikymo sritį.)
„MySQL“ optimizavimo raktas Nr. 4: saugokite duomenų bazę atmintyje
Pastaraisiais metais matėme perėjimą prie kietojo kūno diskų (SSD). Nors SSD diskai yra daug greitesni nei sukantys standieji diskai, jie vis tiek neprilygsta duomenų turėjimui RAM. Šis skirtumas atsiranda ne tik dėl pačios saugyklos našumo, bet ir dėl papildomo darbo, kurį turi atlikti duomenų bazė, kai ji gauna duomenis iš disko ar SSD atminties.
Neseniai patobulinus aparatinę įrangą, duomenų bazę vis labiau įmanoma išsaugoti atmintyje - nesvarbu, ar naudojatės debesyje, ar tvarkote savo aparatinę įrangą.
Dar geresnė žinia yra ta, kad norint gauti daugumą atminties našumo pranašumų, nereikia visos atminties talpinti atmintyje. Jums tiesiog reikia įdėti darbo atmintį į atmintį - duomenis, prie kurių prieinama dažniausiai.
Galbūt matėte keletą straipsnių, kuriuose pateikiami konkretūs numeriai apie tai, kokią duomenų bazės dalį turėtumėte laikyti atmintyje, nuo 10 iki 33 procentų. Tiesą sakant, nėra vieno „visiems tinkamo“ skaičiaus. Duomenų kiekis, kad tilptų į atmintį, siekiant geriausio našumo, yra susijęs su darbo krūviu. Užuot ieškoję konkretaus „stebuklingo“ numerio, turėtumėte patikrinti, kiek duomenų bazės įvesties / išvesties veikia esant pastoviai būsenai (paprastai praėjus kelioms valandoms po jos paleidimo). Pažvelkite į skaitymus, nes skaitymus galima visiškai pašalinti, jei jūsų duomenų bazė yra atmintyje. Rašymas visada turi vykti, nesvarbu, kiek turite atminties.
Žemiau galite pamatyti įvestį / išvestį, vykstančią „InnoDB“ įvesties / išvesties grafike „Percona Monitoring and Management“ informacijos suvestinėje „InnoDB Metrics“.
PerconaAukščiau pateiktame grafike matote net 2000 įvesties / išvesties operacijų per sekundę šuolius, o tai rodo, kad (bent jau kai kurioms darbo krūvio dalims) duomenų bazės darbo rinkinys nelabai telpa į atmintį.
„MySQL“ optimizavimo raktas Nr. 5: naudokite SSD saugyklą
Jei jūsų duomenų bazė netelpa atmintyje (ir net jei ji yra), vis tiek reikia greito saugojimo, kad galėtumėte tvarkyti įrašus ir išvengti našumo problemų, kai duomenų bazė sušyla (iškart po paleidimo). Šiais laikais greitas saugojimas reiškia SSD diskus.
