Tiedon hajauttaminen ja hajautettu kyselynkäsittely

Tiedon hajauttaminen ja hajautettu kyselynkäsittely M. Kifer, A. Bernstein & P. M. Lewis: Database Systems. An Application-Oriented Approach. Complete Version. Second Edition. Pearson Addison Wesley, 2006; sivut 687 709, luku 16 (distributed databases). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Sixth Edition. McGraw-Hill, 2010; sivut 784 791, luvun 17 (database-system architectures) kohdat 17.4 (distributed systems) ja 17.5 (network types); sivut 825 830 ja 854 861, luvun 19 (distributed databases) kohdat 19.1 (homogeneous and heterogeneous databases), 19.2 (distributed data storage), 19.7 (distributed query processing) ja 19.8 (heterogeneous distributed databases). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006; sivut 797 803, luvun 20 (database-system architectures) kohdat 20.4 (distributed systems) ja 20.5 (network types); sivut 833 837 ja 859 865, luvun 22 (distributed databases) kohdat 22.1 (homogeneous and heterogeneous databases), 22.2 (distributed data storage), 22.7 (distributed query processing) ja 22.8 (heterogeneous distributed databases). 1

Useaan tietokantaan operoivat sovellukset, s. 3. Hajautettu tietokantajärjestelmä, s. 6. Sovellussuunnittelijan näkemys hajautetusta tietokannasta, s. 9. Tiedon hajauttaminen eri tietokantoihin, s. 16. Vaakasuora osittaminen, s. 19. Pystysuora osittaminen, s. 23. Tiedon toisintaminen, s. 25. Hajautetun kyselyn laskentamenetelmät, s. 31. Liitosten globaali optimointi, s. 34. Puoliliitosoptimointi, s. 38. Liitokset, projektiot ja valinnat, s. 42. Monitietokantajärjestelmän kyselynoptimointi, s. 50. Tietokantasuunnitelman ja kyselyiden virittäminen, s. 53. Oraclen hajautetut tietokannat, s. 56. 2

Useaan tietokantaan operoivat sovellukset Yhä useammat sovellukset tarvitsevat pääsyn useisiin eri pisteissä sijaitseviin tietokantoihin, jotka voivat olla hyvinkin etäällä toisistaan. Sovellukset voidaan karkeasti jakaa kahteen tyyppiin: (1) Yrityksen sisäiset sovellukset. Verkkokauppa on perustanut maanlaajuisen varastoverkoston nopeuttaakseen tuotteittensa jakelua. Jokaisella varastolla on oma paikallinen tietokantansa, ja kauppiaalla on tietokanta pääkonttorissa. Sovellus, joka laskee tavaran varastoissa olevan määrän, ajetaan pääkonttorin pisteessä ja kohdistuu kaikkien varastojen pisteisiin. (2) Useamman yrityksen tietokantoihin kohdistuvat asiakassovellukset. Kun asiakas ostaa tavaroita Internet-kauppiaalta, osa transaktiosta kohdistuu kauppiaan tietokantaan ja osa luottokorttiyrityksen tietokantaan. Tieto kaupasta rekisteröityy muodossa tai toisessa kumpaankin tietokantaan. Kumpaankiin sovellustyyppiin liittyy hajautettua tietoa (distributed data). Ero on tavassa, jolla eri pisteissä oleviin tietoihin päästään käsiksi. 3

Tyypin (1) sovellus on kirjoitettu tietokantakaaviolle, joka sallii sovelluksen pääsyn kaikkiin pisteisiin SQL-lauseilla. Sovellus voi lähettää select-kyselyn kunkin varaston tietokantaan noutaakseen halutun tiedon ja sitten muodostaa yhdisteen kyselyiden palauttamista monikoista. Tyypin (2) sovellus ei voi päästä tietoihin käsiksi samalla tavalla. Kauppias ja luottokorttiyritys ovat eri yrityksiä, ja niiden tietokannat sisältävät liikesalaisuuden alaista tai arkaluontoista tietoa, joihin kumpikaan ei voi myöntää toiselle pääsyä. Kumpikaan ei myöskään voi sallia toisen aiheuttavan (tahallisesti tai tahattomasti) epäeheyttä tietokantaansa. Luottokorttiyritys tarjoaa aliohjelman (transaktiona suoritettavan tallennetun proseduurin) luottotietokannan päivittämiseksi siten, että asiakkaan tiliä veloitetaan kauppasummalla. Kun luottokorttiyritys laatii aliohjelman itse, se voi paremmin valvoa tietojensa turvallisuutta ja eheyttä. 4

Seuraavassa tarkastellaan tehokkaita menetelmiä hajautetun tiedon käsittelemiseksi. Tehokkuuteen vaikuttaa tietoalkioiden sijainti verkossa sekä tietoalkioiden käsittelyyn käytettävä algoritmi. Menetelmät soveltuvat ainoastaan tyypin (1) sovelluksiin. Tyypin (2) sovelluksissa yrityksen tiedon sijainnin määrää yritys itse, ja tietoon pääsee käsiksi vain yrityksen tarjoamilla aliohjelmilla. Voidaan laatia tyypin (2) sovellus, joka käynnistää näitä aliohjelmia ja käsittelee niiden palauttamaa tietoa, mutta se ei voi operoida tietokantoihin suoraan. Sovellusohjelmoijalla on silloin vain vähän mahdollisuuksia suunnitella tehokas tiedonkäsittelystrategia. Keskitymme tyypin (1) sovelluksiin. Nämä operoivat tietoon suoraan ja käyttävät tietokantasuuntautuneita menetelmiä suorituskyvyn ja tiedon saatavuuden parantamiseksi. 5

Hajautettu tietokantajärjestelmä Hajautettu tietokantajärjestelmä (distributed database system) koostuu joukosta tietokoneverkon toisiinsa yhdistämiä pisteitä (site). Kukin piste ylläpitää omaa (paikallista) tietokantajärjestelmäänsä. Järjestelmän pisteet kommunikoivat toistensa kanssa tietokoneverkon (lähi- tai kaukoverkon) välityksellä. Oletamme, että kunkin pisteen tietokantapalvelin on tavanomainen kyselypalvelin (query server) eli transaktiopalvelin (transaction server), joka palvelee (saman tai muiden pisteiden) sovelluksilta tulevia, tietokantaan kohdistuvia palvelupyyntöjä (SQL-lauseita). Järjestelmän pisteessä s käynnistetty transaktio voi olla joko (1) paikallinen transaktio (local transaction), joka operoi vain pisteen s tietoihin, tai (2) etätransaktio (remote transaction), joka operoi vain tietyn toisen pisteen s s tietoihin, tai (3) hajautettu transaktio (distributed transaction), joka operoi kahden tai useamman pisteen tietoihin. 6

Syitä tiedon hajauttamiseen: Tiedon sijoittelulla pyritään minimoimaan tiedonvälityskustannuksia ja/tai vasteaikaa. Yleensä tieto säilytetään siinä pisteessä, joka operoi siihen useimmin. Tiedon hajauttamisella pyritään tasaamaan työkuormaa: yksittäiset pisteet eivät ylikuormitu siinä määrin, että järjestelmän suorituskyky heikentyisi. Tieto halutaan säilyttää sen luontipisteessä, niin että tiedon luoja voi valvoa sitä ja taata sen turvallisuuden (pisteen paikallinen autonomia, local autonomy), Tiedon saatavuutta (availability) halutaan parantaa: jos yksi piste joutuu häiriötilaan, toiset pisteet voivat jatkaa toimintaansa. Tiettyjä tietoalkioita saatetaan toisintaa (replicate) eli kopioida useisiin pisteisiin suoritustehon lisäämiseksi ja vasteajan pienentämiseksi (tietoon päästään nopeammin käsiksi paikallista tai läheistä toisinnetta käyttäen) tai tiedon saatavuuden lisäämiseksi järjestelmän romahdustapauksissa (jos tietoalkion jokin toisinne ei enää ole saatavilla, voidaan operoida toiseen). 7

Tarkastelemme mm. seuraavia kysymyksiä: Kuinka hajautettu tietokanta pitäisi suunnitella? Missä pisteessä yksittäisiä tietoalkioita tai kokonaisia tauluja pitäisi säilyttää? Mitkä tietoalkiot pitäisi toisintaa ja mihin pisteisiin toisinteet pitäisi sijoittaa? Miten käsitellään useaan tietokantaan kohdistuvat kyselyt? Mitä näkökohtia liittyy hajautetun kyselyn optimointiin? Miten kyselynoptimointimenetelmät vaikuttavat tietokantasuunnitelmaan? 8

Sovellussuunnittelijan näkemys hajautetusta tietokannasta Sovellus perustuu tietokannan loogiseen kaavioon (logical schema), joka kuvaa sovelluksen näkemän tietokannan rakenteen. Hajautetun tietokannan tapauksessa voi olla käytössä kolmenlaisia kaavioita: useita paikallisia kaavioita, paikallisten kaavioiden yhdistekaavio, yksi koko tietokannan kattava kaavio. Useisiin paikallisiin kaavioihin (multiple local schemas) perustuva hajautettu tietokanta näyttäytyy sovellusohjelmalle kokoelmalta yksittäisiä tietokantoja, joilla kullakin on oma kaavionsa. Tällaista järjestelmää kutsutaan monitietokannaksi (multidatabase). Jos yksittäisissä pisteissä toimivat tietokannan hallintajärjestelmät ovat samalta toimittajalta, järjestelmä on homogeeninen, muuten heterogeeninen. Sovellusohjelman täytyy eksplisiittisesti luoda yhteys kuhunkin pisteeseen, jonka tietoja käsitellään: exec sql connect to palvelimen verkko-osoite. Kun yhteys on luotu, ohjelma voi käsitellä tietokantaa SQL-lausein, jotka noudattavat kyseisen pisteen kaaviota. Jos tietoalkion säilytyspiste muuttuu, sovellusohjelmaakin pitää muuttaa. 9

SQL-lause, joka viittaa eri pisteiden relaatioihin, ei ole mahdollinen. Jos sovellus esimerkiksi haluaa muodostaa eri pisteissä sijaitsevien relaatioiden liitoksen, sen täytyy lukea eri SQL-lausein kummankin relaation monikot sovelluspisteen puskuriin ja laskea liitos sovellusohjelmassa. Jos attribuuttiarvo (esim. henkilönnimi) on tallennettu eri pisteisiin eri muodossa, sovellusohjelman on ajoaikana huolehdittava tiedon muuntamisesta kulloinkin vaadittavaan muotoon. Sovellusohjelman on niin ikään huolehdittava tiedon toisintamisesta. Jos toisinnettua tietoalkiota kysytään, sovelluksen on päätettävä, mikä toisinne luetaan. Jos toisinnettua tietoalkiota päivitetään, sovelluksen on taattava, että päivitys toteutuu kaikkiin toisinteisiin. Tällaisena näkyy hajautettu tietokanta, kun sitä käsitellään tavanomaisen sulautettuun SQL:ään, JDBC:hen, SQLJ:hin tai ODBC:hen perustuvan tietokantaliittymän välityksellä. Kaikki tietokannan hajautettuun luonteeseen kuuluvat piirteet on käsiteltävä eksplisittisesti sovellusohjelmassa. 10

Paikallisten kaavioiden yhdistekaavioon eli rajoitettuun globaaliin kaavioon (restricted global schema) perustuvan hajautetun tietokannan kaavio on yhdiste yksittäisten pisteiden tietokantojen kaavioista. Tietokannan taulujen joukko on siis yhdiste yksittäisten pisteiden taulujen joukoista. Sovellukset soveltavat tiettyä nimeämiskäytäntöä viitatessaan kukin pisteen tietokannan tauluihin. Taulujen sijainti voidaan näin kätkeä sovellukselta. Tätä ominaisuutta kutsutaan sijainnin tuntumattomuudeksi (location transparency). Kun sovellus operoi tietyn pisteen tauluun, yhteys pisteeseen muodostetaan automaattisesti. Sovellus voi suorittaa SQL-lauseen, jotka viittaa eri pisteissä sijaitseviin tietoihin, esim. laskee kahden eri pisteissä sijaitsevan taulun liitoksen. Järjestelmässä on globaali kyselynoptimoija, joka tuottaa tehokkaita kyselysuunnitelmia usean pisteen tietoihin viittaville SQL-lauseille. Kyselysuunnitelman kustannusta arvioidaan paitsi levyhakujen määrän myös sen mukaan, kuinka paljon tietoa pitää siirtää pisteiden välillä. 11

Sovellussunnittelija voi päättää tiettyjen tietoalkioiden toisintamisesta ja määrätä toisinteiden sijoituspisteet. Globaali kyselynoptimoija kuitenkin tarjoaa toisinnuksen tuntumattomuuden (replication transparency), ts. kätkee toisinnuksen sovellusohjelmilta. Kun ohjelma viittaa toisinnettuun tietoalkioon, kyselynoptimoijan tuottama suoritussuunnitelma osoittaa sopivan toisinteen luettavaksi ja huolehtii tietoalkion päivityksen levittämisestä tietoalkion kaikkiin toisinteisiin. Järjestelmä on yleensä homogeeninen; pääsy toisen valmistajan tietokantaan on rajoitettua. 12

Yhteen koko tietokannan kattavaan kaavioon eli globaaliin kaavioon (global schema) perustuvassa hajautetussa tietokannassa kaikki tiedon hajauttamiseen liittyvät piirteet on kätketty sovellukselta, ja järjestelmä huolehtii niistä automaattisesti. Järjestelmää kutsutaan integroiduksi hajautetuksi tietokantajärjestelmäksi. Järjestelmä voi olla homogeeninen tai heterogeeninen. Integroinnista huolehtii väliohjelmisto (middleware): yksittäiset kaaviot yhdistyvät yhdeksi globaaliksi kaavioksi, joka sisältää kaikkien pisteiden tiedot. Globaali kaavio saattaa sisältää myös tauluja, jotka eivät esiinny missään paikallisessa kaaviossa mutta jotka voidaan laskea SQLlauseilla paikallisten kaavioiden tauluista. Globaali kaavio on siis yleisesti näkymä (view) paikallisiin kaavioihin. 13

Väliohjelmisto luo automaattisesti yhteyden yksittäisiin pisteisiin, kun globaalin kaavion tietoalkioihin viitataan. Näin toteutuu sijainnin tuntumattomuus. Globaali kaavio (ja siis myös sovellusohjelma) säilyy samana, vaikka tietoalkion sijaintipiste muuttuu. Väliohjelmistossa pitää kylläkin muuttaa kuvausta globaalista kaaviosta paikallisiin kaavioihin. Väliohjelmisto takaa myös toisinnuksen tuntumattomuuden. Väliohjelmisto huolehtii myös eri pisteiden välisestä heterogeenisyydestä tarjoamalla muunnosrutiinit, joilla eri tallennusmuodoissa olevat attribuuttiarvot muunnetaan globaalissa kaaviossa käytettävään muotoon. 14

Heterogeenisessa järjestelmässä on usein tarvetta myös semanttiseen integrointiin, johon liittyy ainakin arvojen ja nimien muuntaminen. Tarkastellaan hajautettua tietokantajärjestelmää, jolla on pisteitä Euroopassa, Japanissa ja Yhdysvalloissa. Raha-arvot voidaan esittää kaikissa pisteissä kaksoistarkkuuden luvuilla, joten mitään esitysmuotomuunnosta ei tarvita. Mutta 1000 euroa on eri kuin 1000 jeniä tai 1000 dollaria. Tokiossa tehty kysely myynnin kokonaismäärästä tarvitsee muunnoksen jeneiksi, ja Helsingissä tehty sama kysely tarvitsee muunnoksen euroiksi. Attribuuttinimen muunnos taas liittyy kulttuurieroihin ja yksilöllisiin tapoihin. Eri maissa on eri kielet, ja saman maankin eri pisteissä voidaan käyttää samalle attribuutille eri nimiä. 15

Tiedon hajauttaminen eri tietokantoihin Tiedon hajauttaminen eri pisteisiin ei aina ole sovellussuunnittelijan päätettävissä. Tietyt tietoalkiot täytyy sijoittaa tiettyyn pisteeseen turvallisuussyistä. Toisinaan sovellussuunnittelija voi osallistua sen päättämiseen, mihin tieto sijoitetaan tai miten sitä toisinnetaan. Yksinkertaisin tapa hajauttaa tieto on tallentaa yksittäisiä tauluja eri pisteisiin. Taulu ei kuitenkaan välttämättä ole paras valinta hajautusyksiköksi. Usein transaktio operoi vain osaan taulun riveistä tai johonkin taulun näkymään eikä koko tauluun. Jos eri transaktiot operoivat taulun eri osiin ja ne ajetaan eri pisteissä, suorituskykyä voidaan parantaa tallentamalla taulun osa siihen pisteeseen, jossa vastaava transaktio ajetaan. Kun taulu ositetaan (partition) eli jaetaan osiin tällä tavoin, kutsutaan taulun osia palasiksi (fragment) tai ositteiksi (partition). 16

Taulun osittamisella on myös muita mahdollisia etuja. Suureen tauluun kohdistuvan kyselyn käsittelyaikaa voidaan vähentää hajauttamalla laskentaa niihin pisteisiin, joihin taulun palasia on sijoitettu. Tarkastellaan yliopiston opiskelijarekisteriin kohdistuvaa kyselyä, joka laskee kunkin opiskelijan opintosuoritusten keskiarvon: select s.student-id, s.student-name, sum(t.credits t.grade)/sum(t.credits) from student s, transcript t where s.student-id = t.student-id group by s.student-id, s.student-name. Jos taulut student ja transcript on molemmat sijoitettu hallintoviraston pisteeseen, kysely lasketaan kokonaisuudessaan siellä. Jos transcript-taulu on ositettu opintosuorituksen antaneen laitoksen sijaintikampuksen mukaan, eri kampuksilla voidaan laskea rinnakkain koosteet select student-id, sum(credits grade), sum(credits) from transcript where department-id = d, group by student-id, missä d on kyseiselle kampukselle sijoitetun laitoksen tunniste. 17

Kun hajautettu tietokanta perustuu yhteen globaaliin kaavioon, ositettu relaatio voi näyttäytyä osittamattomana globaalissa kaaviossa. Toteutuu siis osituksen tuntumattomuus (partition transparency). Väliohjelmisto muuntaa kaikki relaatioon kohdistuvat operaatiot operaatioiksi relaation niihin palasiin, joita operaatio koskettaa. Useaan paikalliseen kaavioon perustuvissa monitietokantajärjestelmissä ositus ei sitä vastoin ole tuntumatonta, vaan kunkin sovellusohjelman on oltava tietoinen osituksesta ja operoitava eksplisiittisesti eri palasiin. 18

Vaakasuora osittaminen Taulu voidaan osittaa vaaka- tai pystysuorasti. Vaakasuorassa osittamisessa (horizontal partitioning) eli riveittäisessä osittamisessa relaatio r ositetaan useammaksi saman kaavion relaatioksi r 1,...,r n niin, että r 1... r n = r ja r i r j = /0 kaikilla i j. Verkkokaupassa voisi olla varastotilannetta kuvaava relaatio inventory(stock-number, amount, price, location), missä location ilmaisee asianomaisen varaston sijaintikaupungin. Relaatio voitaisiin osittaa varaston sijainnin mukaan, jolloin Helsinkiin sijoitettu palanen sisältäisi täsmälleen kyselyn select from inventory where location = Helsinki tuottamat monikot. 19

Yleisemmin ositukselle r = r 1... r n on ehdot r i = σ Ci (r) kaikilla i = 1,...,n, C i C j false kaikilla i j ja r = σ C1... C n (r) täyttävät valintaehdot C i. Tässä σ C tarkoittaa valintaoperaatiota ehdolla C. 20

Joskus on tarpeen osittaa relaatio vaakasuorasti, vaikkei relaatio itsessään sisällä riittävästi informaatiota sen päättämiseen, mihin palaseen mikäkin monikko kuuluu. Ts. palaselle r i ei ole olemassa sen määrittävää valintaehtoa C i. Oletetaan, että verkkokaupalla on samassa kaupungissa useampia varastoja ja että varastot identifioidaan niiden numeroilla: inventory(stock-number, amount, price, warehouse-number), warehouse(warehouse-number, capacity, street-address, location). Verkkokaupalla on yksi tietokanta kussakin kaupungissa. Relaatio inventory ositetaan vaakasuorasti kaupungeittain, niin että yhdessä palasessa on kaikkien asianomaisessa kaupungissa sijaitsevien varastojen inventory-monikot. Helsingissä sijaitseva palanen määräytyy nyt lausekkeella select i.stock-number, i.amount, i.price, i.warehouse-number from inventory i, warehouse w where i.warehouse-number = w.warehouse-number and location = Helsinki. 21

Helsingin palanen inventory-relaatiosta relaatio-operaatioilla ilmaistuna: inventory σ location= Helsinki (warehouse), missä tarkoittaa puoliliitosta (semijoin): r s = π X (r s), missä π X tarkoittaa projektiota r:n attribuuteille X ja (luonnollista) liitosta. Opintorekisterin relaation transcript ositus kampuksittain määriteltäisiin vastaavasti: transcript σ campus= Kumpula (department), missä relaatio transcript liittyy yliopiston laitoksia esittävään relaatioon department viiteavaimen department-number välityksellä. Tällaista puoliliitoksen kautta määräytyvää ositusta kutsutaan johdetuksi vaakasuoraksi ositukseksi (derived horizontal partitioning). Vaakasuoraa ositusta käytetään, kun kunkin pisteen useimmat sovellukset operoivat samaan aitoon osajoukkoon relaation monikoita. 22

Pystysuora osittaminen Pystysuorassa osittamisessa (vertical partitioning) eli sarakkeittaisessa osittamisessa relaatio r(x), jolla on avain Y X, ositetaan palasiin r 1 (X 1 ),...,r n (X n ) siten, että X 1... X n = X, Y X i jokaisella i = 1,...,n, r i = π Xi (r) jokaisella i = 1,...,n ja r 1... r n = r. Verkkokaupan kaikkia työntekijöitä esittävä relaatio employee(ssn, name, salary, title, location) voitaisiin osittaa pystysuorasti palasiin employee1(ssn, name, salary) ja employee2(ssn, name, title, location), joista employee1 sijoitetaan kaupan päätoimipaikkaan (jossa palkat lasketaan) ja employee2 sijoitetaan muualle. 23

Vaaka- ja pystysuorien ositusten yhdistelmät ovat myös mahdollisia. Alkuperäisen relaatio pitää kuitenkin aina olla konstruoitavissa palasista relaatio-operaatioilla. Tyypillisessä lähestymistavassa relaatio ositetaan ensin yhdellä tavalla (esim. pystysuorasti) ja sitten näin saadut palaset (tai osa niistä) toisella tavalla (esim. vaakasuorasti). Esimerkiksi relaatio employee ositetaan ensin pystysuoriin palasiin employee1 ja employee2. Sitten palanen employee2 ositetaan edelleen vaakasuorasti attribuutin location mukaan. 24

Tiedon toisintaminen Toisintaminen (replication) on hajautettujen tietokantojen eniten käytettyjä ja hyödyllisimpiä mekanismeja. Tiedon toisintaminen useisiin pisteisiin parantaa tiedon saatavuutta, koska tietoon päästään käsiksi vaikka jokin toisinteen sijoituspiste olisi romahtanut. Toisintaminen voi myös parantaa suorituskykyä: kysely voidaan suorittaa tehokkaammin, koska tieto voidaan lukea paikallisesta tai läheisestä kopiosta. Toisinnetun tietokannan päivitykset taas ovat yleensä hitaampia, koska päivitettävän tietoalkion kaikki toisinteet pitää myös päivittää. Toisintaminen tehostaa nimenomaan sovelluksia, joissa päivityksiä esiintyy huomattavasti vähemmän kuin kyselyitä. 25

Verkkokauppa pitää asiakkaistaan yllä relaatiota customer(customer-number, name, address, location), missä location määrittää tietyn varaston palveleman alueen. Relaatioon kohdistuu kysely päätoimipisteessä ajettavasta sovelluksesta, joka lähettää kuukausittain postia kaikille asiakkaille. Kussakin pisteessä ajettava sovellus kohdistaa relaatioon kyselyn saadakseen tietoa pisteen kattaman alueen toimituksista. Relaatiota päivitetään päätoimipisteen sovelluksella, kun (1) uusi asiakas rekisteröityy tai (2) rekisteröityneen asiakkaan tiedot muuttuvat (mikä tapahtuu harvoin). Tuntuu sopivalta osittaa relaatio vaakasuorasti location-attribuutin mukaan, niin että yksittäinen palanen sijoitetaan sekä vastaavaan varastoon että päätoimipisteeseen. Relaatio siis osittamisen lisäksi toisinnetaan, niin että päätoimipisteessä on koko relaatio. 26

Arvioidaan suunnittelupäätöstä vertaamalla sitä kahteen muuhun vaihtoehtoon, joissa tietoa ei toisinneta. Vertailtavat kolme vaihtoehtoa ovat: 1. Koko relaatio sijoitetaan päätoimipisteeseen. Varastopisteisiin ei sijoiteta mitään. 2. Relaatio ositetaan vaakasuorasti varastopisteisiin. Päätoimipisteeseen ei sijoiteta mitään. 3. Relaatio ositetaan vaakasuorasti varastopisteisiin. Päätoimipisteeseen toisinnetaan koko relaatio. 27

Vertaillaan vaihtoehtoja sen mukaan, kuinka paljon tietoa pitää siirtää pisteiden välillä mainituissa sovelluksissa. Tehdään seuraavat oletukset: Relaatiossa customer on noin 100 000 monikkoa. Päätoimipisteen postitussovellus lähettää kullekin asiakkaalle yhden kirjeen kuukaudessa. Kaikista varastoista tehdään yhteensä noin 500 toimitusta päivässä. Kutakin toimitusta varten pitää lukea relaatiosta customer yksi monikko. Kauppa saa noin 100 uutta asiakasta päivittäin. Rekisteröityneen asiakkaan tietojen muutokset sitä vastoin ovat niin harvinaisia, ettei niitä tarvitse ottaa vertailussa huomioon. 28

Vertaillaan nyt kolmea vaihtoehtoa. 1. Jos koko relaatio sijoitetaan päätoimipisteeseen, tietoa pitää siirtää sieltä asianomaiseen varastopisteeseen aina toimitusta tehtäessä eli noin 500 monikkoa päivässä. 2. Jos relaatio ositetaan varastopisteisiin, tietoa pitää siirtää (a) varastopisteistä päätoimipisteeseen postitussovellusta suoritettaessa eli noin 100 000 monikkoa kuukaudessa tai 3 300 monikkoa päivässä sekä (b) päätoimipisteestä varastopisteisiin uuden asiakkaan rekisteröityessä eli noin 100 monikkoa päivässä. Yhteensä siirretään siis noin 3 400 monikkoa päivässä. 3. Jos relaatio ositetaan varastopisteisiin ja koko relaatio toisinnetaan päätoimipisteeseen, tietoa pitää siirtää päätoimipisteestä asianomaiseen varastopisteeseen uuden asiakkaan rekisteröityessä eli noin 100 monikkoa päivässä. Tämän mitan mukaan toisintaminen näyttäisi siis parhaalta vaihtoehdolta. 29

Vertaillaan sitten vaihtoehtoja transaktioiden vasteajan mukaan. 1. Jos koko relaatio sijoitetaan päätoimipisteeseen, toimituksen käsittely kärsii tiedon etäkäsittelytarpeen vuoksi. Mutta tätä ei ehkä pidetä niin tärkeänä. 2. Jos relaatio ositetaan varastopisteisiin ja jos kuukausittaisen postituksen tekee yksi sovellus, varastopisteistä päätoimipisteeseen lähetettävät 100 000 monikkoa saattavat tukkia tietoliikennejärjestelmän ja hidastaa muita sovelluksia. Tätä voidaan välttää ajamalla postitussovellus myöhään illalla tai viikonloppuisin, kun muita sovelluksia on käynnissä vähän. 3. Jos relaatio ositetaan varastopisteisiin ja koko relaatio toisinnetaan päätoimipisteeseen, uuden asiakkaan rekisteröinti kärsii, koska sekä asianomaisen varastopisteen palanen että päätoimipisteen relaatio pitää päivittää. Tämä on tärkeää, koska asiakas rekisteröityy vuorovaikutteisesti eikä siedä pitkää odotusta. Tässä sovelluksessa rekisteröitymistä voidaan kuitenkin pitää loppuun saatettuna (sitoutuneena) heti, kun päätoimipisteen tietokanta on päivitetty. Varastopisteen tietokantaan päivitys voidaan suorittaa myöhemmin, sillä tietoahan ei tarvita siellä ennen kuin jokin toimitustransaktio suoritetaan. Näinkin vertaillen toisintaminen näyttäisi olevan paras vaihtoehto. 30

Hajautetun kyselyn laskentamenetelmät Monitietokantajärjestelmä koostuu joukosta itsenäisiä tietokannan hallintajärjestelmiä, jotka kukin tarjoavat SQL-liittymän. Sovellus näkee joukon paikallisia tietokantakaavioita. Useaan tietokantaan kohdistuva kysely täytyy sovelluksessa osittaa jonoksi yksittäiseen tietokantaan kohdistuvia SQL-lauseita. Kun yksittäisen tietokannan kyselynoptimoija saa sille osoitetun SQL-lauseen, se optimoidaan ja suoritetaan, ja tulos palautetaan sovellukselle. 31

Globaaliin kaavioon perustuvassa järjestelmässä taas globaali kyselynoptimoija analysoi kyselyn käyttäen globaalin kaavion määrittelyitä ja kääntää sen sopivaksi jonoksi operaatioaskeleita suoritettaviksi yksittäisissä pisteissä. Kunkin pisteen paikallinen kyselynoptimoija voi edelleen optimoida suoritettavaksi saamansa operaatioaskeleen. Seuraavassa oletamme, että kysymyksessä on homogeeninen hajautettu tietokantajärjestelmä. Koska sellaisessa järjestelmässä yksittäiset tietokantajärjestelmät voivat kommunikoida suoraan keskenään, kyselynoptimoinnilla on enemmän mahdollisuuksia, ja hyvän ja huonon suoritussuunnitelman välinen kustannusero voi olla huomattava. Globaali kyselynoptimointi käyttää hajautettua algoritmia, johon liittyy suoraa tiedon vaihtoa eri pisteiden tietokantajärjestelmien välillä. 32

Kummassakin tapauksessa tavoitteena on suorittaa kysely tehokkaasti. Kustannusmittana käytämme erityisesti pisteiden välistä tietoliikennekustannusta; kustannusta mitataan niiden tavujen lukumäärällä, jotka laskennan kuluessa pitää siirtää pisteestä toiseen. Globaalin kyselynoptimoinnin algoritmien tuntemus auttaa suunnittelemaan globaaleja kyselyitä, joiden suoritus tietyllä tavalla hajautettuun tietoon on tehokasta, tehokkaita algoritmeja monitietokantajärjestelmän globaalien kyselyiden laskemiseksi sekä sopivan hajautustavan globaalien kyselyiden kohteena olevalle tiedolle. 33

Liitosten globaali optimointi Globaalilla liitoksella (global join) tarkoitetaan liitosta, jossa liitettävät taulut sijaitsevat eri pisteissä. Globaalit liitokset voivat olla erityisen kalliita, koska mahdollisesti suuri määrä monikoita joudutaan siirtämään pisteestä toiseen toisiinsa liittyvien monikoiden selvittämiseksi. Oletetaan esimerkiksi, että pisteen s 1 sovellus haluaa liittää pisteissä s 2 ja s 3 sijaitsevat relaatiot; liitoksen tulos pitää siis toimittaa pisteeseen s 1. Kaksi suoraviivaista tapaa laskea liitos: 1. Siirrä molempien relaatioiden monikot pisteeseen s 1 ja laske liitos siellä. 2. Siirrä pienemmän relaation (esim. pisteen s 2 relaation) monikot toisen relaation pisteeseen (s 3 :een), laske liitos siellä ja palauta tulos pisteeseen s 1. 34

Tarkastellaan yliopiston opetushallinnon relaatioita: student(id, major), missä major tarkoittaa opiskelijan pääainetta (koodi); relaatiota säilytetään pisteessä s 2. transcript(student-id, course-code), missä course-code osoittaa kuluvan lukukauden kurssin, jolle opiskelija on ilmoittautunut; relaatiota säilytetään pisteessä s 3. Pisteessä s 1 toimiva sovellus haluaa laskea liitoksen select id, major, course-code from student, transcript where id = student-id. 35

Vaihtoehtoisten suoritussuunnitelmien vertailemiseksi teemme seuraavat oletukset: Attribuuttiarvojen pituudet ovat: id ja student-id 9 tavua; major: 3 tavua; course-code: 6 tavua. Relaatiossa student on noin 15 000 monikkoa, kukin pituudeltaan 9 + 3 = 12 tavua. Noin 5000 opiskelijaa on ilmoittautunut ainakin yhdelle kurssille, ja heistä kukin on ilmoittautunut keskimäärin neljälle kurssille. Relaatiossa transcript on siis noin 20 000 monikkoa, kukin pituudeltaan 9 + 6 = 15 tavua. Koska kuluva lukukausi on kesälukukausi, valtaosa opiskelijoista (10 000) ei ole ilmoittautunut millekään kurssille. 36

Relaatioiden student ja transcript liitoksessa on noin 20 000 monikkoa, kukin pituudeltaan 9 + 3 + 6 = 18 tavua. Eri laskentastrategioiden tiedonsiirtokustannukset: 1. Jos molemmat relaatiot siirretään pisteeseen s 1 ja liitos lasketaan siellä, on siirettävä kaikkiaan 15 000 12 + 20 000 15 = 480 000 tavua. 2. Jos student-relaatio siirretään pisteeseen s 3 ja liitos lasketaan siellä, on siirrettävä kaikkiaan 15 000 12 + 20 000 18 = 540 000 tavua. 3. Jos transcript-relaatio siirretään pisteeseen s 2 ja liitos lasketaan siellä, on siirrettävä kaikkiaan 20 000 15 + 20 000 18 = 660 000 tavua. Paras kolmesta vaihtoehdosta on siis 1. 37

Puoliliitosoptimointi Pisteissä s 2 ja s 3 sijaitsevien relaatioiden liitoksen laskemiseksi ja toimittamiseksi pisteeseen s 1 on olemassa tehokkaampikin suoritussuunnitelma, jonka globaalin kyselynoptimoijan on mahdollista tuottaa. Siirretään pisteestä s 2 pisteeseen s 3 ainoastaan ne student-monikot, jotka todella osallistuvat liitokseen, ja lasketaan sitten pisteessä s 3 näiden monikoiden ja transcript-relaation liitos. Liitokseen osallistuvat monikot saadaan selville puoliliitoksella. Menettelyä kutsutaan puoliliitosoptimoinniksi (optimization with semijoins, planning with semijoins). 38

1. Pisteessä s 3 lasketaan väliaikainen relaatio P = select distinct student-id from transcript. Lähetetään P pisteeseen s 2. Siirtokustannus 5 000 9 = 45 000 tavua. 2. Pisteessä s 2 lasketaan puoliliitos Q = select id, major from student, P where id = student-id. Lähetetään Q pisteeseen s 3. Siirtokustannus 5 000 12 = 60 000 tavua. 3. Pisteessä s 3 lasketaan liitos R = select id, major, course-code from Q, transcript where id = student-id. Lähetetään R pisteeseen s 1. Siirtokustannus 20 000 18 = 360 000 tavua. Kaiken kaikkiaan siirretään siis 45 000 + 60 000 + 360 000 = 465 000 tavua, joten tämä suoritussuunnitelma on tietoliikennekustannuksissa mitaten aiemmin esitettyjä tehokkaampi. 39

Itse asiassa päästään vielä parempaan ratkaisuun seuraavasti. Sen sijaan, että askeleessa 2 lähetettäisiin Q pisteeseen s 3, lähetetäänkin sekä Q että transcript pisteeseen s 1 : 2. Pisteessä s 2 lasketaan puoliliitos Q = select id, major from student, P where id = student-id. Lähetetään Q pisteeseen s 1. Siirtokustannus 5 000 12 = 60 000 tavua. 3. Lähetetään transcript pisteeseen s 1. Siirtokustannus 20 000 15 = 300 000 tavua. Lasketaan siellä liitos R = select id, major, course-code from Q, transcript where id = student-id. Tämän suoritussuunnitelman kokonaiskustannus on 45 000 + 60 000 + 300 000 = 405 000 siirrettyä tavua. 40