Tietokannan kyselyoptimointi moniydinprosessorilla

Transkriptio

1 hyväksymispäivä arvosana arvostelija Tietokannan kyselyoptimointi moniydinprosessorilla Mikko Kuusinen Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Tietojenkäsittelytieteen laitos Mikko Kuusinen Työn nimi Arbetets titel Title Tietokannan kyselyoptimointi moniydinprosessorilla Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages 15 sivua Seminaarityö Tiivistelmä Referat Abstract Työn tavoitteena on selvittää kuinka moniydinprosessoreilla saadaan hyviä tuloksia tietokantakyselyjä suoritettaessa. Tuloksina kolmea erilaista ratkaisua vertailtaessa saadaan, että nopeushyöty on suuri monissa hidastavissa tekijöissä, kuten välimuistin hukkaiskuissa (cache miss ) ja prosessorin pysähtymisissä (processor stall), mutta lopulliset hyödyt kyselyjen suorituksissa ovat pienemmät. Työssä myös selvitetään hieman sitä, mihin aika kuluu tietokantahakua prosessorilla laskettaessa. ACM Computing Classification System (CSS): D.4.1[Process Management] H.2 [Database Management] Avainsanat Nyckelord Keywords Tietokanta, moniydin, säie Säilytyspaikka Förvaringställe Where deposite Muuta

3 ii Sisältö 1 Johdanto 1 2 Prosessoria hidastavat tekijät Mihin aika kuluu Nopeutta useasta ytimestä Säikeet Apuydin ASYNC -operaattori Tulosten läpikäynti Yhteenveto 13 Lähteet 14

4 1 1 Johdanto Tietokantojen koon kasvaessa niiden vaatimat resurssit kasvavat samalla. Jotta tiedon määrä olisi hallittavissa ja tiedonhaku tästä määrästä olisi edelleen nopeaa, joudutaan laitteistoa ja ohjelmistoja päivittämään. Siinä missä ohjelmistojen algoritmeja ja toimintaperiaatteita voidaan kehittää yhä paremmaksi, niin voidaan kehittää myös laitteistoa. Siitä lähtien, kun laitteisto on sallinut useamman prosessorin toimia järjestelmässä, on sitä yritetty hyödyntää kaikin mahdollisin tavoin. Tänä päivänä usean prosessorin toiminta samalla alustalla on suurelta osin vaihtunut useamman ytimen sisältäviin prosessoreihin. Ratkaisut eroavat toisistaan muun muassa siten, että moniydinprosessoreilla on yhteinen välimuisti verrattuna usean yksiytimisen prosessorin toimintaan, joilla kaikilla on oma välimuistinsa. Nykyään moniydinprosessoreja löytyy lähes jokaisesta kodista ja työpaikalta, joten on itsestään selvää, että niitä täytyy myös pystyä hyödyntämään kunnolla. Tietokantojen yhteydessä moniydinprosessorien tuomaa hyötyä on selvitetty jo vähintään kymmenen vuoden ajan. Ensimmäinen mielestäni työni aiheeseen hyvin kuuluva julkaisu on Ailamakin ja kumppaneiden [ADH99] tutkimus siitä, mihin aika modernilla prosessorilla kuluu, kun prosessorilla ajetaan tietokannanhallintajärjestelmää. Tulokset ovat varmasti vielä vertailtavissa nykypäivän uusimpiin moniydinprosessoreihin, joten julkaisu on kymmenen vuoden iästään vielä hyvin paikkansa pitävä. Moniydinprosessoreita alettiin siis valjastaa tietokantojen käyttöön jo useita vuosia sitten. Nykyään moniydin prosessoreiden lisäksi on olemassa prosessoreita, jotka kykenevät ajamaan useaa säiettä yhtä aikaa. Myös tätä ominaisuutta on tutkittu tietokannanhallintajärjestelmien nopeuttamiseksi. Zhoun ja kumppanien [ZCR05] julkaisu tutkii kuinka Pentium 4 prosessorin samanaikainen säikeiden ajo voisi parantaa tietokantajärjestelmän nopeutta. Todennäköisesti tietokantojen suorituskykyä parantavia moniydinprosessoreita käsittelen kahden eri julkaisun muodossa. Kumpikin julkaisuista on viime vuodelta, joten niiden käsittelemät aiheet ja menetelmät ovat lähes uusinta, mitä alalla on julkaistu. Ensimmäisenä esittelen Papadopulosin ja kumppaneiden Apuydin (HelperCore DB ) ratkaisun [PST08]. Apuytimen ideana on, että ydin jolla ei ole muuta tekemistä voi pyytää välimuistiin muiden ytimien lähitulevaisuudessa tarvitsemaa tietoa. Toisena esittelen Ackerin ja kumppaneiden ratkaisun [ARB08], jolle he eivät ole antaneet mitään tiettyä

5 2 nimeä. Kutsun ratkaisua kuitenkin tästä lähtien nimellä ASYNC -operaattori (ASYNC operator), koska tekijät mallintavat rinnakkaisuutta uudella ASYNC operaattorilla kyselysuunnitelmassa. Ottaen huomioon julkaisujen erilaiset lähestymistavat tietokannan suorituskyvyn parantamiseksi, on mielenkiintoista nähdä mitkä lopulliset tulokset kummasakin tapauksessa ovat. Työssä käyn ensin läpi luvussa 2, mikä vie aikaa nykyisissä prosessoreissa tietokantojen hakuja laskettaessa. Luvussa 3 käyn läpi kolme tapaa, joilla moniydinprosessoreiden on tarkoitus parantaa suorituskykyä ja näiden tapojen testauksien tulokset. 2 Prosessoria hidastavat tekijät Riippuen sitä minkälaista ohjelmaa prosessorilla ajetaan sitä kuormitetaan eri lailla. Oli kyseessä sitten peli tai tietokannanhallintajärjestelmä, niin aina löytyy pullonkaula jostain järjestelmän arkkitehtuurista. Käyn tässä luvussa läpi syitä miksi tietokantakyselyt vaativat niin paljon järjestelmältä ja kuinka aika jakautuu prosessorilla tietokantahakua laskettaessa. 2.1 Mihin aika kuluu Prosessorit ovat kehittyneet viime vuosina suuresti ja kymmenen vuotta sitten ei tavallisella käyttäjällä ollut mahdollista saada sellaista laskentatehoa, mikä löytyy nykyään melkein jokaisesta tavallisesta pöytäkoneesta. Kuitenkin laitteistosta on aina yritetty ottaa irti kaikki mahdollinen hyöty. Näin oli myös kymmenen vuotta sitten kun Ailamaki ja kumppanit [ADH99] alkoivat tutkia mihinkä aika kuluu prosessorilla, kun tietokannanhallintajärjestelmä saa suoritettavakseen kyselyn. Heidän alustanaan toimi Pentium 2 prosessori ja käyttöjärjestelmänä Windows NT. Aikaisempien tutkimusten perusteella kirjoittajat olettavat, että suurin syy mikä aiheuttaa hidastumista on laskennan pysähtyminen jostain syystä. Prosessorilla on kuitenkin seuraavanlaisia operaatioita, joita se voi suorittaa sillä välin kun se odottaa, että laskenta voi jatkua: Ei-eristävä välimuisti, eli muita muistipyyntöjä voidaan suorittaa samalla kun yhtä muistipyyntöä odotetaan. Sekalaisen järjestyksen salliva suoritus, eli jos käsky x:n suoritus pysähtyy voidaan siirtyä suorittamaan käskyä y, jos y:n tulos ei riipu x:stä.

6 Haarautuvuuden ennustus, eli algoritmi yrittää arvata mikä olisi seuraava predikaatti ja laskee sen mukaan tuloksen [ADH99]. 3 Ailamaki ja kumppanit esittävät seuraavan kaavan kyselyyn kuluvalle ajalle T Q T Q =T C T M T B T R T OVL. Kaavassa T C on laskutoimitukseen kuluva hyödyllinen laskenta-aika, T M on aika, joka kuluu pysähdyksiin muistipyynnön takia, T B on aika, joka kuluu väärin menneisiin haarautuvuuden ennustuksiin, T R on aika, joka kuluu resurssien puutteesta johtuviin pysähdyksiin, ja T OVL on aika, joka vähennetään päällekkäin tapahtuneiden pysähdysten takia. Näistä muistipyyntöihin kuluva aika jaetaan julkaisussa vielä useaan pienempään osaan, mitkä voidaan jakaa muun muassa tason 1 ja 2 välimuistin harhaiskuihin (T L1D ja T L2D ). Myös resurssien puute voi johtua monesta syystä. Ailamaki ja kumppanit jakavat resurssien puutteen kolmeen osaan: funktionaalista yksikköä ei ole vapaana, käskyjen välillä on riippuvuuksia ja alusta riippuvaiset ominaisuudet [ADH99]. Kuluvan ajan testaukseen Ailamaki ja kumppanit [ADH99] käyttivät tietokantaa, jonka relaatiossa on 1,2 miljoonaa sadan tavun tietuetta. Testiajot suoritettiin peräkkäisellä välin valinnalla, indeksoidulla välin valinnalla ja peräkkäisellä liitoksella. Testit suoritettiin 400Mhz Pentium 2 prosessorilla, jolla oli tason 1 välimuistia 16KB tiedolle ja käskyille kummallekin ja tason 2 välimuistia 512KB. Vertailukohtana voin sanoa, että nykyaikaisesta Core Duo prosessorista löytyy kummallekin prosessorille 32KB tason 1 välimuistia sekä tiedolle että käskyille, 2MB tason 2 välimuistia ja kellotaajuus on yli 2Ghz. Testit suoritettiin neljälle eri tietokannanhallintajärjestelmälle, joidenka nimet

7 4 esitettiin julkaisussa vain A, B, C ja D kirjaimilla. Kuvassa 1. on testien tulokset jaettuna neljään komponenttiin T C, T M, T B ja T R. Laskenta-aika T C on jokaisessa alle puolet kyselyn suoritusajasta, eli prosessori käyttää yli puolet ajasta pysähtyneessä tilassa. Ailamaki ja kumppanit [ADH99] olivat kymmenen vuotta sitten sitä mieltä, että tilanne ei tule tulevaisuudessakaan tästä parantumaan, sillä vaikka prosessorien nopeus kasvaa ei muistin nopeus kasva samalla tahdilla. He olivatkin oikeassa, sillä uudemmissa artikkeleissa nimen omaan muistista haku mainitaan edelleen pahimpana pullonkaulana tietokantojen suorituskyvyssä [PST08, ZCR05]. Kuvasta myös huomataan, että ajan jakautuminen riippuu enemmän suoritettavasta kyselystä, kuin tietokannanhallintajärjestelmästä. Julkaisussa todetaan lisäksi, että eri tietokannanhallintajärjestelmien välillä on erilaisia optimointeja alusta kohtaisesti, mutta tietyn asian optimointi yleensä vahvistaa jonkin muun alueen pullonkaulaa. Täten optimoinnissa pitäisi aina keskittyä jokaiseen kolmeen hidastavaan tekijään. Kaikkiaan julkaisu vaikutti asialliselta ja siihen viitataan yhä paljon iästä huolimatta. Olisi erittäin mielenkiintoista mikäli testit saataisiin toteutettua uudelleen nykypäivän prosessorilla. Itse kuvittelisin, että muistiviive on nykyään vielä suuremaassa osassa, koska prosessorien nopeudet ovat kasvaneet hurjasti verrattuna muistin ja kiintolevyn nopeuksiin [ADH99]. 3 Nopeutta useasta ytimestä Koska yhden prosessorin suorituskykyä voidaan nostaa nykyisellään huomattavasti hitaammin kuin vielä vuotta sitten, on siis vain luonnollista, että prosessorien määrää on lisätty. Suorituskyvyn nostaminen ei kuitenkaan ole helppoa ohjelmistoissa, sillä usean ytimen käyttö vaatii ohjelmistollisia muutoksia ja aina useampaa ydintä ei yksinkertaisesti voi tehtävässä hyödyntää. Esittelen luvussa kolme eri tapaa, joilla tietokannanhallintajärjestelmien nopeutta yritetään parantaa. 3.1 Säikeet Otin Zhoun ja kumppaneiden julkaisun [ZCR05] tietokannanhallintajärjestelmien nopeuttamisesta yhtäaikaisella monisäikeisyydellä mukaan, koska mielestäni on mielenkiintoista nähdä kuinka pelkästään usean säikeen suorittaminen yhtä aikaa nopeuttaa, verrattuna kokonaan toisen prosessorin lisäämiseen. Monisäikeisyys eroaa toisen prosessorin lisäämisestä siten, että eri säikeet jakavat monia resursseja, mukaan

8 5 lukien prosessorin muistikaistan ja välimuistit. Tämän takia usean säikeen ajaminen yhtä aikaa on olennaisesti hitaampi kuin fyysisen prosessorin lisääminen. Zhou ja kumppanit tutkivat kolmea eri tapaa käyttää monisäikeisyyttä hyväksi. Ensimmäinen ja yksinkertaisin näistä on ajatella monisäikeisyyteen kykenevää prosessoria, siten kuin säikeitä ajaisi kokonaan oma fyysinen prosessori. Tämä ratkaisu vaatii tekijöiden mukaan vähiten vaivaa koodin muuttamisessa tietokannanhallintajärjestelmässä, jota yleensä voidaan ajaa moniydinprosessoreilla. Ratkaisu ei kuitenkaan ota huomioon resurssien jakamista loogisten prosessorien välillä. Toinen vaihtoehto on toteuttaa jokainen tietokantaoperaatio monisäikeisyyden vaatimalla tavalla. Tekijät kutsuvat tätä nimellä Kaksoissäikeistys (Bi-threaded). Ratkaisun haaste on päättää, kuinka jakaa työmäärä ja kuinka yhdistää tulokset eri säikeiltä. Kolmas ja samalla tekijöiden ehdottama uusi tapa on käyttää yhtä säiettä apuna tiedon aggressiiviseen ennalta hakuun. Jos tiedon ennalta haku tapahtuu tekijöiden mukaan optimaalisesti, niin pääsäie löytää tarvitsemansa tiedon välimuistista useammin. Lähes samaa ideaa, mutta kokonaan omalla ytimellä, käyttävät Papadopoulos ja kumppanit Apuydin ratkaisullaan aliluvussa 3.2 [PST08, ZCR05]. Zhoun ja kumppanien [ZCR05] ehdottamassa uudessa ratkaisussa he määrittävät Etukäteistyöskentelykokoelma (Work-ahead-set) tietorakenteen, mikä on jaettu pää- ja apusäikeen välillä, kuten kuvasta 2. ilmenee. Pääsäie syöttää tietorakenteeseen muistiviittauksia tiedosta, jota se tulee tarvitsemaan lähitulevaisuudessa, ja apusäie noutaa muistiviittausten mukaan tietoa välimuistiin. Apusäie siis vain lukee tietorakenteesta, joten tiedon oikeellisuus pääsäikeelle on taattu. Tekijät ovat sitä mieltä, että lisääntyvä koodin monimutkaisuus on kohtuullinen ja vaivan arvoinen, kun paremmat tulokset näkyvät mittauksissa. Etukäteistyöskentelykokoelma koostuu pareista (p,s), jossa p on muistiosoite ja s on tila, mikä ilmoittaa pääsäikeen laskennan tilan muistiosoitteessa. Koska tekijät halusivat tietorakenteesta mahdollisimman tehokkaan ja yksinkertaisen on se tietyn mittainen kehätaulukko. Järjestelmän suorituskykyyn vaikuttaa neljä eri asetusta. Tietorakenteen alkioihin voi olla useita tai vain yksi osoitin, tietorakenteen kokoa voi vaihtaa, apusäie voi liikkua tietorakenteessa joko eteenpäin tai taaksepäin ja apusäie voi jäädä tai olla jäämättä kiertosilmukkaan (spin-loop), kun se huomaa saman muistiosoitteen annetussa alkiossa. Mielestäni on kahtiajakoinen asia, että ratkaisussa on monta muuttujaa, joita voidaan vaihtaa. Muuttujille voidaan löytää hyvin toimivat oikeat arvot, mutta niiden löytyminen saattaa kestää. Mikäli arvoja ei säädetä voi hyöty jäädä pienek-

9 6 si tai pahimmassa tapauksessa tietokannan suorituskyky saattaa huonontua [ZCR05]. 3.2 Apuydin Apuydin lähestymistapa, kuten Papadopoulos ja kumppanit [PST08] kutsuvat omaa ratkaisuaan, perustuu siihen, että kaikilla ytimillä ei suoriteta samaa koodia. Ratkaisussa osa ytimistä suorittaa koodia, jonka suoritus epäsuorasti hyödyttää ohjelmaa. Toteutus keskittyy ratkaisemaan yhden pahimmista ongelmista tietokantaohjelmissa, eli muistiviiveen, suorittamalla tehokasta tiedon esinoutoa. Esinoudon suorittaa apuydin ja tiedon käyttää jokin muu ydin. Ainoa vaatimus laitteistotasolla on, että kumpikin ydin jakaa jonkin tason muistihierarkiasta. Apuydin vaatii tekijöiden mukaan minimaalisia muutoksia alkuperäiseen tietokannanhallintajärjestelmän koodiin ja heidän mukaansa se toimii kaikilla moniydinratkaisuilla. He kirjoittavat, että tehokas tapaa käyttää rinnakkaisuutta tietokannoissa on antaa kyselyt eri prosessorien suoritettavaksi. Tätä käytetäänkin muun muassa PostgreSQL 1 ja MySQL 2 järjestelmissä ja kutsutaan kyselyväliseksi (inter-query) samanaikaisuudeksi. Nämä järjestelmät eivät kuitenkaan tue kyselysisäistä (intra-query) samanaikaisuutta eli kyselyn jakoa useiksi samanaikaisiksi tehtäviksi. Kyselyvälisestä samanaikaisuudesta voi olla hyötyä tiettyyn pisteeseen asti kuten Papadopoulos ja kumppanit esittävät. He tekivät simuloidun kokeen jossa kahdeksalla ytimellä ajettiin testi siitä, kuinka monta ydintä on kannattavaa olla käytössä

10 7 Kokeen tuloksena oli, että kuuden samanaikaisen ytimen käytön jälkeen muistihauista johtuva viive oli niin suuri, että osa prosessoreista joutui vain odottamaan, eikä voinut suorittaa laskentaa. Tässä siis kaksi yli jäävää ydintä olisivat hyvin voineet olla kirjoittajien mukaan Apuytimiä [PST08]. Ollakseen tehokas Papadopoulos ja kumppanit esittivät Apuytimelle seuraavat kriteerit: 1) sen täytyy olla yksinkertainen liittää nykyisin tietokannanhallintajärjestelmiin, 2) sen täytyy hakea tieto muistista ennen kuin tietoa tarvitaan, mutta vasta niin myöhään, ettei tieto katoa ennen käyttöä ja 3) vaikka Apuytimen ja tietokantasäikeiden välille tarvitaan synkronointi, niin siitä täytyy seurata vain vähän kustannuksia. Tekijöiden mukaan kodat 1) ja 3) täyttyvät, koska Apuydin noutaa muistista muistin puskurin kokoisia osia ja työsäikeen tarvitsee kommunikoida Apuytimen kanssa vain seuraavaksi tarvittavasta lohkosta. Kohta 2) täyttyy tapauskohtaisesti, sillä etukäteen haettavien lohkojen määrä riippuu tilanteesta. Tekijät kirjoittavat, että ihannetilanteessa noudettavien lohkojen määrä riippuisi suoritettavasta kyselystä. Itse en aivan ymmärrä miksi nimen omaan näillä ratkaisuilla liittäminen nykyisiin järjestelmiin on vaivatonta. Tekijät myös myöntävät kohdasta 2), että he itsekään eivät tiedä mikä arvo lohkojen noudolle on sopiva ja lupaavat palata asiaan. Tämä tuo mielestäni suurta epävarmuutta ratkaisun lopullisesta suorituskyvystä [PST08]. Kuvassa 3. on pseudokoodi työsäikeelle ja Apuytimelle. Apuytimen puolella on yksinkertainen silmukka, joka tarkistaa ilmoitusta joltain työsäikeeltä. Esimerkiksi jos jokin työsäie pyytää uutta lohkoa, jota ei ole esinoudettu, niin apuydin alkaa noutaa tietolohkoja. Sen tehtävä on noutaa d kappaletta lohkoja alkaen pyydetystä lohkosta. Kuvan 3.

11 8 ratkaisussa on käytetty aktiivista odotusta (busy-wait) synkronoinnissa, koska tekijöiden mukaan se vähentää työsäikeen ylimääräistä työtä ja Apuytimellä on kuitenkin oma prosessori käytössä, joten aika ei ole muusta laskennasta pois. Ratkaisu ei ole kaikkein paras esimerkiksi energian säästön kannalta, minkä tekijät itsekin myöntävät. On mielestäni lisäksi kyseenalaista halutaanko prosessorin vain pyörittävän tyhjäkäynnillä silmukkaa, jos hyödyllistäkin työtä olisi mahdollista tehdä [PST08]. 3.3 ASYNC -operaattori Ackerin ja kumppaneiden [ARB08] lähestymistapa tiivistää epäsynkronisen relaatiokyselyn suorituksen läpinäkyväksi relaatio-operaattoriksi. Kaikki toteutus on piilotettuna tämän operaattorin sisälle ja sen käyttö asettaa tekijöiden mukaan minimaalisesti vaatimuksia toisille relaatio-operaattoreille. Operaattori tukee aikaisemmista ratkaisuista poiketen luonnostaan kyselysisäistä samanaikaisuutta ja ratkaisee järjestyksen säilyttämisen ongelman. Tekijät tiivistävät samanaikaisuuden toteutuksen kaksivaiheiseen kyselyn suunnittelun optimointiin. Ensimmäisessä vaiheessa optimointia suunnitellaan kuinka kysely pitäisi suorittaa samanaikaisena. Toinen vaihe dynaamisesti jalostaa kyselysuunnitelman suoritusvaiheessa uudelleen tasapainottamalla suorittavat säikeet tasapainoon, joka takaa parhaan mahdollisen samanaikaisuuden rajatuille resursseille. Tekijät jakavat resurssit, jotka ratkaisu ottaa huomioon, muuan muassa seuraaviksi: väylä tai prosessori riippuvuus, monikon koko, monikkojen määrä sivua kohti ja tehtävään arviolta kuluva aika. Hitaita tehtäviä nopeutetaan määräämällä niille useampia säikeitä ja nopeat tehtävät voivat samalla odottaa sisäänmenopuskureissa [ARB08]. Tekijät mallintavat samanaikaisuuden uutena ASYNC operaattorina kyselynsuunnittelussa. Tämä operaattori on abstraktio säikeiden rajoista operaattoripuussa. Toisin sanoen tieto, joka kulkee ASYNC solmun läpi kulkeutuu säikeeltä toiselle. Solmu voi olla minkä tahansa kahden operaattorin välissä peräkkäisessä kyselynsuunnittelussa. Monikoiden vaihto säikeiden välillä tapahtuu puskurin välityksellä, joka on kapseloitu ja ohjattu jokaisella ASYNC operaattorilla. Puskuriin pääsy on synkronoitu ja se muistuttaa klassista tuottajat-kuluttajat ongelmaa. Kyselyvälinen samanaikaisuus mallinnetaan yksinkertaisesti lisäämällä ASYNC solmuja operaattoripuuhun. Kuvassa 4. tämä on kohta (c). Kyselysisäinen samanaikaisuus mallinnetaan tunnistamalla operaattoripuun sisällä kanavan osia, jotka ovat sopivia samanaikaiseen suoritukseen.

12 9 Kuinka tunnistaminen oikein tapahtuu jää julkaisussa selvittämättä. Kuvassa 4. on esimerkki kyselysisäisestä toteutuksesta (d). Tässä alempi ASYNC solmu toimii tiedon jakajana eli jakaa sisään tulevan tiedon kanavien sisäänmenopuskureihin ja ylempi solmu yhdistää tulokset kanavien ulostulopuskureista [ARB08]. Julkaisussa on todella paljon asiaa sen takia, että kaikki käydään hyvin perusteellisesti läpi. Itse sain sellaisen kuvan, että ASYNC operaattoria voidaan ja pitääkin säätää kokoajan ajon aikana riippuen lähes kaikesta mahdollisesta, kuten operaattorin asetuksista ja suoritettavasta kyselystä. Ratkaisu tuntuu operaattorin sisällä lopulta hyvin monimutkaiselta ja tekijät toteavatkin muutamassa kohtaa, että he olettavat, että tietyt asiat ovat tai menevät aina optimaalisesti. 3.4 Tulosten läpikäynti Zhoun ja kumppanien [ZCR05] julkaisun tuloksissa otettiin huomioon vain tason 2 välimuistin harhaosumat ja prosessorin kanavan tyhjennys, mikä saattaa johtua esimerkiksi väärässä järjestyksessä muistista lukemisen takia. Nämä kaksi valittiin siksi, koska ne olivat heidän testiensä mukaan selkeästi suurimmat hidastavat tekijät. Kuvassa 5. ja 6. on vasemmalla ensin yhden ja kahden säikeen testien tulokset. Kolmantena ja neljäntenä tulevat säikeet joihin on lisätty etukäteistyöskentelykokoelman vaatima lavastettu operaattori (staged operator). Viidentenä ja kuudentena ovat Kaksoissäikeistykset, jotka osittavat sisään tulevan tiedon ja laskevat sen lomittain. Lopulta viimeisenä kuvassa 5. on Etukäteistyöskentelykokoelman tulos ja kuvassa 6. sekä pääsäikeen että apusäikeen

13 10 tulokset [ZCR05]. Mielestäni kuvasta 5. voi nähdä, että suoritusteho kasvaa huomattavasti kun järjestelmään lisätään yksi säie lisää. Mitään valtavaa hyötyä ei kuitenkaan Zhoun ja kumppanien [ZCR05] Etukäteistyöskentelykokoelmasta ole tähän verrattuna. Tekijät laskivat, että kahteen säikeeseen verrattuna heidän ratkaisunsa kävi CSB+ puun tapauksessa parhaimmillaan 10% ja liitoksessa 4,3% enemmän monikkoja läpi sekunnissa. Kuvan 6. tuloksista nähdään kuitenkin, että tekijöiden perusidea Etukäteistyöskentelykokoelmassa toimii todella hyvin. Pääsäikeen välimuistin hukkaiskut ovat selkeästi vähemmät kuin minkään muun. Mielestäni tekijöiden ratkaisu toimii siis nimen oman niin kuin he ajattelivatkin: pääsäie laskee ja apusäie suorittaa muistista haun. Harmi sinänsä, että tästä ratkaisusta ei ole olennaisesti parempaa hyötyä verrattuna kahteen säikeen perustoteutukseen. Luulen myös, että on helpompaa toteuttaa tietokannanhal-

14 lintajärjestelmä tukemaan kahta säiettä perinteisesti, kuin käyttää toteutuksessa Etukäteistyöskentelykokoelmaa [ZCR05]. 11 Papadopoulos ja kumppanit [PST08] ovat samalla linjalla Zhoun ja kumppanien [ZCR05] kanssa siinä, että tuloksissa otetaan huomioon vain kaksi eniten vaikuttavaa tekijää. He pitävät eniten suorituskykyyn vaikuttavina tekijöinä tason 2 välimuistin harhaosumia ja prosessorin pysähtyneisyyttä. Kuvassa 7. on esillä kohdassa (a) kuinka paljon Apuytimen käyttö vähentää prosessorin pysähdyksiä tietyillä kyselyillä. 22 kyselystä pysähdykset vähenivät yli 40% kahdeksassa tapauksessa ja 19 tapauksessa vähennys oli yli 20%. Kohdassa (b) on tason 2 harhaiskujen väheneminen käytettäessä Apuydintä. Kuvasta näkee, että 21 tapauksessa harhaiskut vähenivät yli 60%. Tekijöiden mielestä on tärkeä mainita, että heidän testeissä käyttämänsä Core Duo prosessori sisältää laitteistotason ennalta noudon. Tästä huolimatta heidän mukaansa Apuydin auttaa tämän ominaisuuden päälle poistaen vielä puolet harhaiskujen määrästä. Teoreettisella tasolla Apuydin mielestäni on erittäin vaikuttava ja lukujen mukaan nopeutus kyselyjä suoritettaessa pitäisi olla huomattava [PST08]. Kuvassa 8. on Papadopouloksen ja kumppanien [PST08] tulokset Apuytimelle suoritettaessa 22 kyselyä, samat kuin kuvassa 7., eri kokoisille tietokannoille ja laskettaessa kuinka paljon suoritusaika lyhenee. Kyselystä riippuen huomataan, että parhaimmillaan hyöty on noin 20% verrattuna pelkkään kahden prosessoin käyttöön, mutta yleensä nopeushyöty jää viiden ja vajaan 15 prosentin väliin. Tuloksista voi lukea myös sen, että hyöty ei skaalaudu lineaarisesti tietokannan koon kasvaessa. 50MB kokoiseen tietokantaan asti hyöty näyttää kasvavan, mutta 100MB tietokannalla hyöty on yleensä joko

15 hieman parempi tai huonompi kuin 50MB tietokannalla. Mielestäni Apuytimen käytöstä on selkeästi hyötyä tietokantojen suorituskykyyn, vaikkei nopeutus aina olekaan suuri. 12 Julkaisussa ei myöskään tullut ilmi mitään miksi ratkaisun liittäminen tietokannanhallintajärjestelmään olisi hankalaa ja testit suoritettiinkin Apuydin liitettynä PostgreSQL tietokantaan. Vertailtaessa Apuydintä Etukäteistyöskentelykokoelmaan voin sanoa, että idea on kummassakin oikea, mutta Etukäteistyöskentelykokoelman toteutus säikeille ei ole yhtä hyödyllinen. Sen hyödyllisyys kärsii, koska kahden säikeen samanaikainen ajaminen ei vain korvaa kokonaan toista prosessoria. On harmi, ettei Apuytimen testituloksissa ollut mukana yhden prosessorin ratkaisua, sillä tuloksia olisi ollut mielenkiintoista vertailla [PST08, ZCR05]. ASYNC -operaattorin testaukseen Acker ja kumppanit [ARB08] käyttivät 387 kyselyn kyselysarjaa. Kuvassa 9. ovat näille kyselyille suoritettujen testiajojen tulokset. Lyhyiden kyselyjen sarjassa (1-219) kyselyt kestävät alta 10ms, joten mahdollinen hyöty samanaikaisuudesta on tekijöiden mukaan olematon. Enin aika tässä sarjassa kuluu asiakkaan ja palvelijan välisessä kommunikaatiossa, eikä suorittimen nopeuksista ole siten hyötyä. Keskipitkät kyselyt ( ) kestävät ms ja niissä osassa ASYNC -operaattorista on hyötyä ja osassa taas ei. Tekijöiden mukaa ASYNC -operaattorista aiheutuvat kustannukset ovat näille kyselyille kolmen prosentin luokkaa, mikä toisaalta

16 13 tarkoittaa sitä, ettei hyötykään ole kovin suuri. Pitkissä kyselyissä ( ), jotka kestävät yli 600ms hyöty taas on selkeästi havaittavissa. Tekijöiden mukaan jopa niin hyvin, että suoritus on lähellä arvioitua optimi hyötyä. Kaiken kaikkiaan samanaikaisuus vähentää kokonaisuudessa kuluvaa aikaa alle 70%. Siinä missä pelkällä kahden suorittimen käytöllä tekijät saivat kyselyjen suoritusajaksi 226,5 sekuntia, niin ASYNC -operaattorilla aikaa kului 156 sekuntia [ARB08]. Mielestäni ASYNC -operaattorin tulokset ovat varsinkin pitempään kestävillä kyselyillä huomattavat. Toisaalta taas operaattorista aiheutuva lisäys laskentaan saattaa aiheuttaa suoritusajan pitenemisen lyhyemmille kyselyille. Ikävästi kuvat tuloksista ovat pienenpuoleisia ja niihin on laitettu mielestäni liikaa asiaa ja liian vähän selittäviä tekijöitä, joten tulosten tulkinta vaikeutuu. Esimerkiksi kaikkien muiden tässä käsittelemieni artikkelien taulukot ja testitulokset ovat huomattavasti helpommin tulkittavissa. Testitulosten valossa, niin kuin niitä parhaiten voi tulkita, pidän kuitenkin ASYNC -operaattorin käyttöä hyödyllisenä vaihtoehtona. Varsinkin jos sen liittäminen järjestelmään on yhtä vaivatonta, kuin tekijät itse antavat ymmärtää. 4 Yhteenveto Kävin työssä ensin läpi mihin aika prosessorilla kuluu tietokantakyselyä suoritettaessa. Ailamakin ja kumppaneiden [ADH99] julkaisusta kävi varsin selkeästi selville, kuinka muistista haut ja resurssien puute ovat suurin hidaste kyselyn tuloksen valmistumiselle. Mielestäni oli jopa hälyttävää, että prosessorin laskenta-aikaa käytettiin alle puolet kyselyn suoritusajasta. Julkaisun perusteella voi siis päätellä, että tarvetta paremmalle

17 14 tiedon ennalta hauelle löytyy todella paljon. Nimen omaan tiedon ennalta haun ideaan perustuvakin Zhoun ja kumppaneiden [ZCR05] sekä Papadopouloksen ja kumppaneiden [PST08] ratkaisut. Kummassakin pyritään parantamaan suorituskykyä samalla idealla: yksi ydin tai säie noutaa tietoa, mitä muut tulevat tarvitsemaan. Säikeiden tapauksessa hyöty jää lopulta pieneksi, mutta ytimien tapauksessa hyöty on kohtalaisen suurta. Acker ja kumppanit [ARB08] ovat tässä eri linjalla ja heidän ratkaisuna on jakaa yhden kyselyn suoritus tasaisesti usealle säikeelle. Ratkaisu vaatii laskenta-aikaa prosessorilta koko ajan, joten lyhyet ja keskipitkät kyselyt kärsivät tästä. Pidempään kestäville kyselyille hyöty taas on suuri. Minusta kiinnostavina yksityiskohtina voin mainita myös, että Zhoun ja kumppaneiden [ZCR05] testien tuloksista voi päätellä, että pelkästään samanaikaisesti suoritettavien säikeiden lisäys parantaa huomattavasti kyselyjen suoritusta. Lisäksi Papadopouloksen ja kumppaneiden [PST08] testistä voi päätellä, että pelkästään ytimien lisääminen johtaa lopulta muistikaistan tukkeutumiseen ja täten prosessorin ytimien pysähtymisiin. Ratkaisua jossa moniydinprosessoreita siis käytetään älykkäästi, eli jokainen ydin ei aina laske vain yhtä kyselyä, tarvitaan kipeästi. Julkaisujen perusteella ratkaisuja on onneksi keksitty, nyt kun vain ne pääsisivät käyttöön asti. Lähteet ADH99 ARB08 PST08 ZCR05 A. Ailamaki, D. J. DeWitt, M. D. Hill ja D. A. Wood. DBMSs On A Modern Processor: Where Does Time Go? In Proceedings of the Very Large Data Bases (VLDB'99), Morgan Kaufmann, Edinburgh, Scotland, UK, 1999, sivut R. Acker, C. Roth ja R. Bayer. Parallel Query Processing in Databases on Multicore Architectures. Algorithms and Architectures for Parallel Processing, 5022:2 13. Springer Berlin / Heidelberg, K. Papadopoulos, K. Stavrou ja P. Trancoso. HelperCore DB : Exploiting Multicore Technology to Improve Database Performance. In Proceedings of the Parallel and Distributed Processing (IPDPS'08), IEEE International Symposium, Miami, Florida, USA, 2008, sivut J. Zhou, J. Cieslewicz, K. A. Ross ja M. Shah. Improving Database Per-

18 15 formance on Simultaneous Multithreading Processors. In Proceedings of the Very Large Data Bases (VLDB'05), ACM, Trondheim, Norway, 2005, sivut