Tietokanta on usein piilossa oleva pullonkaula
Kun verkkosovellus alkaa takkuilla, syyttä sormella osoitetaan yleensä palvelinta tai internetyhteyttä. Todellisuudessa ongelma on useimmiten tietokannassa. Kyse ei ole siitä, ettei palvelin jaksaisi – vaan siitä, että sovellus pyytää tietokannalta liikaa, liian usein tai liian huonosti muotoiltuja kysyjä.
Esimerkki: verkkokauppa, jossa on 5 000 tuotetta. Jokainen sivulataus tekee 40 erillistä SQL-kyselyä, joista osa hakee samaa dataa uudelleen ja uudelleen. Sivun latausaika on 3,8 sekuntia. Optimoinnin jälkeen kyselyjä on 8, latausaika 0,6 sekuntia. Muutos ei vaatinut uutta palvelinta – vain oikeita korjauksia oikeissa kohdissa.
Kolme yleisintä ongelmaa ja niiden tunnistaminen
Suurin osa tietokantaongelmista juontaa juurensa samoista syistä. Tunnista nämä ensin:
- N+1-ongelma: Sovellus hakee ensin listan (esim. 100 tilausta) ja tekee sen jälkeen jokaista tilausta varten erillisen kyselyn asiakastiedoille. Tuloksena 101 kyselyä yhden sijasta. PHP-kehittäjät törmäävät tähän erityisesti ORM-kirjastojen kanssa.
- Puuttuvat indeksit: Tietokanta käy läpi kaikki rivit löytääkseen yhden. Taulu, jossa on 200 000 riviä ja jota haetaan sähköpostiosoitteen perusteella ilman indeksiä, voi olla 50–100 kertaa hitaampi kuin indeksoitu versio.
- Turha data: Kysely hakee kaikki sarakkeet (SELECT *) vaikka tarvitaan vain kaksi. Suurilla tauluilla tämä turhaan kasvattaa siirrettävän datan määrää ja hidastaa vastausta.
Näiden löytämiseen ei tarvita kalliita työkaluja. MySQL:ssä EXPLAIN-komento paljastaa kyselysuunnitelman muutamassa sekunnissa. Se kertoo suoraan, käytetäänkö indeksiä vai ei.
Välimuisti – nopein tapa leikata kuormaa
Kaikkia kyselyitä ei tarvitse optimoida – osa niistä voidaan korvata kokonaan. Välimuisti (cache) tarkoittaa, että laskettu tai haettu tulos tallennetaan tilapäisesti, jolloin seuraava pyyntö ei koske tietokantaan lainkaan.
Käytännön esimerkki: verkkopalvelu, jossa etusivu näyttää uusimmat 10 artikkelia. Tämä tieto ei muutu sekunnin välein. Kun tulos välimuistitetaan 5 minuutiksi Redisillä tai Memcachedilla, tietokantakysely tehdään enintään kerran 5 minuutissa – ei jokaiselle 500 yhtäaikaiselle käyttäjälle erikseen.
Välimuistin voi rakentaa eri tasoille:
- Sovellustaso: Yksittäisten kyselyiden tulokset tallennetaan väliaikaisesti muistiin.
- Sivutaso: Koko HTML-sivu generoidaan vain kerran ja tarjotaan sellaisenaan seuraavalle kävijälle.
- CDN-taso: Staattiset resurssit ja jopa dynaamiset sivut voidaan jakaa maantieteellisesti lähemmäs käyttäjää.
Milloin tietokanta pitää suunnitella uudelleen
Joskus yksittäiset optimoinnit eivät riitä. Jos sovellus on alun perin rakennettu muutamalle sadalle käyttäjälle ja nyt sillä on kymmeniä tuhansia, rakenne saattaa olla perustavanlaatuisesti väärä.
Merkkejä siitä, että rakenne vaatii uudelleensuunnittelua:
- Yhdessä taulussa on kymmeniä miljoonia rivejä ilman osiointia
- Raporttikysely kestää yli 30 sekuntia ja blokoi muut toiminnot
- Sovellus kaatuu ruuhkahuippujen aikana toistuvasti
Ratkaisuna voi olla taulun osiointi, erilliset luku- ja kirjoituspalvelimet (read replica) tai tietyissä tapauksissa siirtyminen osittain dokumenttitietokantaan kuten MongoDBhyn. Nämä päätökset vaativat aina tapauskohtaista arviota – ei yhtä vastausta joka tilanteeseen.
Mitä tämä maksaa käytännössä
Tietokantaoptimointi ei ole kuukausien projekti. Yksinkertaisimmissa tapauksissa – puuttuvat indeksit, N+1-ongelmat, turhat kyselyt – kokenut kehittäjä löytää ja korjaa kriittisimmät kohdat muutamassa päivässä. Vaikutus voi olla välitön: sivuston nopeutuminen näkyy sekä käyttäjäkokemuksessa että hakukonesijoituksissa.
Monimutkaisemmissa rakenteellisissa ongelmissa työ vie pidempään, mutta se on silti halvempaa kuin palvelinkapasiteetin tuplaamisella ajan ostaminen – joka on väliaikainen ratkaisu pysyvään ongelmaan.
Hitaan sovelluksen nopein ratkaisu ei ole uusi palvelin. Se on selvittää, mitä tietokanta tekee – ja teettää se paremmin.
Jos epäilet, että sovelluksesi tietokanta on pullonkaula, ota yhteyttä NorthDevLabiin. Käymme läpi tilanteen ja kerromme konkreettisesti, missä ongelmat ovat ja miten ne korjataan.