Peter Zaitsev on yhtiön perustaja ja toimitusjohtajaPercona.
Yksi tapa mitata sovelluksia on suorituskyky. Yksi sovelluksen suorituskyvyn mittareista on käyttökokemus, joka yleensä tarkoittaa "pitikö käyttäjän odottaa kohtuullista aikaa kauemmin saadakseen haluamansa".
Tämä tieto voi tarkoittaa eri asioita eri tilanteissa. Mobiiliostosovelluksen vasteaika voi olla enintään muutama sekunti. Työntekijän HR-sivulla vastausten antaminen saattaa kestää muutama sekunti kauemmin.
Meillä on paljon tutkimusta siitä, miten suorituskyky vaikuttaa käyttäjien käyttäytymiseen:
- 79 prosenttia asiakkaista palaa vähemmän todennäköisesti hitaalle verkkosivustolle
- 47 prosenttia kuluttajista odottaa verkkosivun latautuvan 2 sekunnissa tai vähemmän
- 40 prosenttia käyttäjistä hylkää verkkosivuston, jos lataaminen kestää yli kolme sekuntia
- Yhden sekunnin viive sivun latausajassa voi johtaa 7 prosentin menetykseen konversiossa ja 11 prosenttia vähemmän sivun katselukertoja
Standardista riippumatta on tärkeää säilyttää sovellusten hyvä suorituskyky. Muuten käyttäjät valittavat (tai pahempaa, mene toiseen sovellukseen). Yksi sovellusten suorituskykyyn vaikuttavista tekijöistä on tietokannan suorituskyky. Sovellusten, verkkosivustojen ja tietokantojen välinen vuorovaikutus on kriittinen sovellusten suorituskyvyn tason määrittämisessä.
Keskeinen osa tätä vuorovaikutusta on, kuinka sovellukset kysyvät tietokannasta ja miten tietokanta reagoi pyyntöihin. Joka tapauksessa MySQL on yksi suosituimmista tietokantojen hallintajärjestelmistä. Enemmän yrityksiä siirtyy MySQL: ään (ja muihin avoimen lähdekoodin tietokantoihin) tietokantaratkaisuna tuotantoympäristöissään.
MySQL: n konfigurointiin on monia tapoja, jotka voivat auttaa varmistamaan, että tietokanta vastaa kyselyihin nopeasti ja vähentää sovelluksen suorituskyvyn vähimmäistasoa.
Seuraavassa on joitain tärkeitä vinkkejä, joiden avulla voit optimoida MySQL-tietokannan suorituskyvyn.
MySQL-optimointiavain # 1: Opi käyttämään SELITTÄÄ
Kaksi tärkeintä päätöstä, jotka teet minkä tahansa tietokannan kanssa, on suunnitella, kuinka sovellusyksiköiden väliset suhteet kartoitetaan taulukoihin (tietokantakaavio), ja suunnitella, miten sovellukset saavat tarvitsemansa tiedot tarvitsemassaan muodossa (kyselyt).
Monimutkaisissa sovelluksissa voi olla monimutkaisia kaavioita ja kyselyjä. Jos aiot saavuttaa sovelluksesi edellyttämän suorituskyvyn ja mittakaavan, et voi luottaa vain intuitioon ymmärtääksesi, kuinka kyselyt toteutetaan.
Arvaamisen ja toivomisen sijaan sinun pitäisi oppia käyttämään SELITTÄÄ komento. Tämä komento näyttää, miten kysely suoritetaan, ja antaa sinulle käsityksen siitä, mitä suorituskykyä voit odottaa ja miten kysely laajenee muuttuvan datan koon mukaan.
On olemassa useita työkaluja, kuten MySQL Workbench, jotka voivat visualisoida SELITTÄÄ tuotos sinulle, mutta sinun on silti ymmärrettävä perusasiat sen ymmärtämiseksi.
On kahta erilaista muotoa, joissa SELITTÄÄ -komento antaa tuloksen: vanhanaikainen taulukon muoto ja nykyaikaisempi, jäsennelty JSON-asiakirja, joka tarjoaa huomattavasti enemmän yksityiskohtia (esitetty alla):
mysql> selitä format = json valitse keskiarvo (k) sbtest1: stä, jossa id on välillä 1000 ja 2000 \ G**************************** 1. rivi ********************* *******
SELITÄ: {
"Query_block": {
“Select_id”: 1,
"Cost_info": {
“Query_cost”: “762.40”
"pöytä": {
“Taulukon_nimi”: “sbtest1”,
"Access_type": "alue",
"Mahdollista_näppäimet": [
"ENSISIJAINEN"
],
"Avain": "ENSISIJAINEN",
"Used_key_parts": [
"Id"
],
"Avaimen_pituus": "4",
“Rows_examined_per_scan”: 1874,
“Rows_produced_per_join”: 1874,
"Suodatettu": "100,00",
"Cost_info": {
“Read_cost”: “387.60”,
"Eval_cost": "374,80",
“Prefix_cost”: “762.40”,
“Data_read_per_join”: “351 kt”
},
"Käytetty_sarakkeet": [
"Id",
"K"
],
"Attach_condition": "(" sbtest "." Sbtest1 "." Id "välillä 1000 ja 2000)"
}
}
}
Yksi komponentti, jota kannattaa tarkastella, on "kyselyn hinta". Kyselykustannukset tarkoittavat sitä, kuinka kalliiksi MySQL ottaa tämän kyselyn huomioon kyselyn suorittamisen kokonaiskustannuksissa, ja se perustuu moniin eri tekijöihin.
Yksinkertaisten kyselyjen kyselykustannukset ovat yleensä alle 1 000. Kyselyjä, joiden hinta on 1 000–100 000, pidetään keskihintaisina kyselyinä, ja ne ovat yleensä nopeita, jos suoritat vain satoja tällaisia kyselyitä sekunnissa (ei kymmeniä tuhansia).
Kyselyt, joiden hinta on yli 100 000, ovat kalliita kyselyitä. Usein nämä kyselyt toimivat edelleen nopeasti, kun olet yksi käyttäjä järjestelmässä, mutta sinun tulisi miettiä tarkkaan, kuinka usein käytät tällaisia kyselyjä interaktiivisissa sovelluksissa (varsinkin kun käyttäjien määrä kasvaa).
Tietenkin nämä ovat ballpark-suorituskyvyn numeroita, mutta ne osoittavat yleisen periaatteen. Järjestelmäsi saattaa käsitellä kyselyjen kuormituksia paremmin tai huonommin sen arkkitehtuurista ja kokoonpanosta riippuen.
Tärkein tekijä kysynnän kustannusten määrittämisessä on se, käyttääkö kysely hakemistoja oikein. SELITTÄÄ -komento voi kertoa, jos kysely ei käytä hakemistoja (yleensä sen vuoksi, miten hakemistot luodaan tietokantaan, tai siitä, miten itse kysely on suunniteltu). Siksi on niin tärkeää oppia käyttämään SELITTÄÄ.
MySQL-optimointiavain # 2: Luo oikeat hakemistot
Hakemisto parantaa kyselyn suorituskykyä vähentämällä tietokantaa, jota kyselyjen on skannattava. MySQL: n hakemistoja käytetään nopeuttamaan pääsyä tietokantaan ja helpottamaan tietokantarajoitusten (kuten AINUTLAATUINEN ja ULKOMAAN AVAIN).
Tietokantaindeksit muistuttavat paljon kirjaindeksejä. Ne pidetään omassa sijainnissaan, ja ne sisältävät tietoja jo päätietokannassa. Ne ovat vertailumenetelmä tai kartta tietojen sijaintiin. Hakemistot eivät muuta mitään tietokannan tietoja. He vain osoittavat tietojen sijaintiin.
Ei ole indeksejä, jotka sopivat aina mihin tahansa työmäärään. Hakemistoja on aina tarkasteltava järjestelmän käynnissä olevien kyselyjen yhteydessä.
Hyvin indeksoidut tietokannat toimivat paitsi nopeammin, mutta jopa yksi puuttuva hakemisto voi hidastaa tietokannan indeksointia. Käyttää SELITTÄÄ (kuten aiemmin suositeltiin) löytääksesi puuttuvat hakemistot ja lisäämällä ne. Mutta ole varovainen: Älä lisää hakemistoja, joita et tarvitse! Tarpeettomat indeksit hidastavat tietokantoja alaspäin (tutustu esitykseen MySQL-indeksoinnin parhaista käytännöistä).
MySQL-optimointiavain # 3: Ei oletuksia!
Kuten kaikilla ohjelmistoilla, MySQL: llä on monia konfiguroitavia asetuksia, joita voidaan käyttää käyttäytymisen (ja viime kädessä myös suorituskyvyn) muuttamiseen. Ja kuten kaikki ohjelmistot, järjestelmänvalvojat jättävät huomiotta monet näistä konfiguroitavissa olevista asetuksista, ja niitä käytetään oletusasetuksissaan.
Parhaan suorituskyvyn saamiseksi MySQL: stä on tärkeää ymmärtää konfiguroitavat MySQL-asetukset ja - mikä vielä tärkeämpää - asettaa ne toimimaan parhaiten tietokantaympäristösi kannalta.
Oletuksena MySQL on viritetty pienimuotoiseen kehitysasennukseen, ei tuotannon mittakaavaan. Yleensä haluat määrittää MySQL: n käyttämään kaikkia käytettävissä olevia muistiresursseja ja sallimaan sovelluksesi tarvitsemien yhteyksien määrän.
Tässä on kolme MySQL-suorituskyvyn viritysasetusta, joita kannattaa aina tutkia tarkasti:
innodb_buffer_pool_size: Puskurivarasto sisältää tietoja ja hakemistoja välimuistissa. Tämä on tärkein syy käyttää järjestelmää, jossa on paljon RAM-muistia tietokantapalvelimena. Jos käytät vain InnoDB-tallennusmoottoria, varataan yleensä noin 80 prosenttia muistista puskurivarastolle. Jos sinulla on hyvin monimutkaisia kyselyitä tai sinulla on erittäin suuri määrä samanaikaisia tietokantayhteyksiä tai sinulla on erittäin paljon taulukoita, sinun on ehkä otettava tämä arvo alaspäin, jotta voit kohdistaa enemmän muistia muihin tarkoituksiin.
Kun asetat InnoDB-puskurivaraston koon, sinun on varmistettava, ettet aseta sitä liian suureksi tai se aiheuttaa vaihtamisen. Tämä tappaa ehdottomasti tietokannan suorituskyvyn. Helppo tapa tarkistaa on tarkastella toiminnan vaihtamista Percona Monitoring and Management -järjestelmän yleiskatsauskaaviossa:
PerconaKuten tämä kaavio osoittaa, jotkut vaihtaminen ovat hienoja niin usein. Jos kuitenkin näet jatkuvaa vaihtotoimintaa 1 Mt sekunnissa tai enemmän, sinun on pienennettävä puskurivaraston kokoa (tai muuta muistin käyttöä).
Jos et saa arvoa innodb_buffer_pool_size oikein ensimmäisellä kerralla, älä huoli. MySQL 5.7: stä alkaen voit muuttaa InnoDB-puskurivaraston kokoa dynaamisesti käynnistämättä tietokantapalvelinta uudelleen.
innodb_log_file_size: Tämä on yhden InnoDB-lokitiedoston koko. Oletusarvoisesti InnoDB käyttää kahta arvoa, jotta voit kaksinkertaistaa tämän luvun saadaksesi pyöreän uudelleenlokitilan, jonka InnoDB käyttää varmistaakseen, että tapahtumasi ovat kestäviä. Tämä optimoi myös muutosten soveltamisen tietokantaan. Asetus innodb_log_file_size on kysymys kompromisseista. Mitä suurempi varattu uudelleentila on, sitä parempi suorituskyky saavutetaan kirjoitusintensiiviselle työmäärälle, mutta sitä pidempi kaatumisen palautumisaika, jos järjestelmäsi kärsii virtakatkoista tai muista ongelmista.
Mistä tiedät, rajoittaako MySQL-suorituskykyä nykyinen InnoDB-lokitiedostokoko? Voit kertoa katsomalla kuinka paljon käytettävissä olevasta uudelleenlokitilasta todellisuudessa käytetään. Helpoin tapa on tarkastella Perconan seuranta ja hallinta InnoDB Metrics -hallintapaneelia. Alla olevassa kaaviossa InnoDB-lokitiedoston koko ei ole tarpeeksi suuri, koska käytetty tila työntää hyvin lähelle käytettävissä olevan uudelleenlokitilan määrää (merkitty punaisella viivalla). Lokitiedoston koon tulee olla vähintään 20 prosenttia suurempi kuin tilaa käytetään järjestelmän optimaalisen toiminnan ylläpitämiseksi.
Perconamax_connections: Laajamittaiset sovellukset vaativat usein paljon enemmän kuin oletusyhteyksien lukumäärä. Toisin kuin muut muuttujat, jos et määritä tätä oikein, sinulla ei ole suorituskykyongelmia (sinänsä). Sen sijaan, jos yhteyksien määrä ei riitä sovellustarpeisiisi, sovelluksesi ei yksinkertaisesti pysty muodostamaan yhteyttä tietokantaan (mikä näyttää käyttäjän seisokilta). Tämän muuttujan saaminen oikealle on tärkeää.
Voi olla vaikeaa tietää, kuinka monta yhteyttä tarvitset monimutkaisille sovelluksille, joissa on useita komponentteja useilla palvelimilla. Onneksi MySQL: n avulla on erittäin helppo nähdä, kuinka monta yhteyttä käytetään huippukäytössä. Tyypillisesti haluat varmistaa, että sovelluksesi käyttämien yhteyksien enimmäismäärä ja käytettävissä olevien yhteyksien enimmäismäärä ovat vähintään 30 prosenttia. Helppo tapa tarkastella näitä numeroita on käyttää MySQL-yhteyskaaviota MySQL-yleiskatsaus-paneelissa Perconan seurannassa ja hallinnassa. Alla olevassa kaaviossa näkyy terve järjestelmä, jossa käytettävissä on paljon muita liitäntöjä.
PerconaYksi mielessä pidettävä asia on, että jos tietokanta toimii hitaasti, sovellukset luovat usein liikaa yhteyksiä. Tällaisissa tapauksissa sinun on työskenneltävä tietokannan suorituskykyongelman sijasta yksinkertaisesti sallimalla enemmän yhteyksiä. Lisää yhteyksiä voi pahentaa taustalla olevaa suorituskykyongelmaa.
(Huomaa: Kun asetat max_connections Muuttuja on huomattavasti oletusarvoa korkeampi, joten sinun on usein harkittava muiden parametrien, kuten taulukon välimuistin koon ja MySQL: n sallimien avoimien tiedostojen määrän lisäämistä. Tämä menee kuitenkin tämän artikkelin soveltamisalan ulkopuolelle.)
MySQL-optimointiavain # 4: Säilytä tietokanta muistissa
Olemme nähneet siirtymisen SSD-asemille viime vuosina. Vaikka SSD-asemat ovat paljon nopeampia kuin kiintolevyjen pyöriminen, ne eivät silti ole yhteensopivia tietojen saatavuuden kanssa RAM-muistissa. Tämä ero ei johdu vain itse tallennustehosta, vaan myös lisätyöstä, jonka tietokannan on tehtävä, kun se hakee tietoja levy- tai SSD-tallennustilasta.
Viimeisimpien laitteistoparannusten avulla tietokanta on yhä useammin mahdollista saada muistiin - olitpa sitten pilvipalvelussa vai hallinnoi omaa laitteistoa.
Vielä parempi uutinen on, että sinun ei tarvitse sijoittaa koko tietokantaa muistiin saadaksesi suurimman osan muistin suorituskyvyn eduista. Sinun tarvitsee vain sijoittaa työryhmä muistiin - tiedot, joita käytetään useimmin.
Olet ehkä nähnyt joitain artikkeleita, joissa on tiettyjä numeroita siitä, mikä osa tietokannasta sinun tulisi pitää muistissa, vaihtelevat 10-33 prosenttia. Itse asiassa ei ole olemassa yhtä kokoa kaikille -numeroa. Parhaan suorituskykyedun saamiseksi muistiin sopivan datan määrä liittyy työmäärään. Sen sijaan, että etsit tiettyä "maagista" numeroa, sinun on tarkistettava, kuinka paljon I / O-tietokanta on käynnissä tasaisessa tilassa (tyypillisesti muutama tunti sen aloittamisen jälkeen). Katsokaa lukemia, koska lukut voidaan poistaa kokonaan, jos tietokanta on muistissa. Kirjoitusten on aina tapahduttava, riippumatta siitä, kuinka paljon muistia sinulla on käytettävissä.
Alla näet I / O-toiminnot InnoDB I / O -kaaviossa InnonDB Metrics -hallintapaneelissa Perconan seurannasta ja hallinnasta.
PerconaYllä olevassa kaaviossa näet piikkejä jopa 2000 I / O-operaatiota sekunnissa, mikä osoittaa, että (ainakin joillekin osille työmäärää) tietokannan työskentelyjoukko ei sovi hyvin muistiin.
MySQL-optimointiavain # 5: Käytä SSD-tallennustilaa
Jos tietokanta ei mahdu muistiin (ja vaikka mahtuukin), tarvitset silti nopeaa tallennustilaa kirjojen käsittelemiseksi ja suorituskykyongelmien välttämiseksi tietokannan lämmetessä (heti uudelleenkäynnistyksen jälkeen). Nykyään nopea tallennus tarkoittaa SSD-asemia.
