T Hajautetut tietokannat

Transkriptio

1 Opetusmoniste T Hajautetut tietokannat Syksy 2010 (periodi II) ss Osa 1: Tiedon hajauttaminen ja hajautettu kyselynkäsittely 3 Useaan tietokantaan operoivat sovellukset 6 Hajautettu tietokantajärjestelmä 9 Sovellussuunnittelijan näkemys hajautetusta tietokannasta 16 Tiedon hajauttaminen eri tietokantoihin 19 Vaakasuora osittaminen 23 Pystysuora osittaminen 25 Tiedon toisintaminen 31 Hajautetun kyselyn laskentamenetelmät 34 Liitosten globaali optimointi 38 Puoliliitosoptimointi 42 Liitokset, projektiot ja valinnat 50 Monitietokantajärjestelmän kyselynoptimointi 53 Tietokantasuunnitelman ja kyselyiden virittäminen 56 Oraclen hajautetut tietokannat ss Osa 2: Hajautettujen transaktioiden hallinta 63 Hajautetun tietokannan transaktiot 71 Atominen sitoutuminen 75 Kaksivaiheinen sitoutumiskäytäntö 86 Usean alueen ylittävä atominen sitoutuminen 90 Häiriöiden käsittely kaksivaiheisessa sitoutumiskäytännössä 94 Pisteen elvytys häiriöstä 101 Hajautettujen transaktioiden X/Open-käsittelymalli 104 Hajautettu lukkiuma 107 Globaali sarjallistuvuus 110 Heikommat sitoutumiskäytännöt ss Osa 3: Toisinnetun tietokannan hallinta 123 Tietoalkioiden toisintaminen 128 Toisinteiden johdonmukaisuus 130 Tahdistavasti päivittävä toisintaminen 133 Päätösvaltaan perustuva toisintaminen 140 Tahdistamatta päivittävä toisintaminen 144 Pääkopiotoisintaminen 151 Ryhmätoisintaminen 155 Oraclen toisintamiskäytännöt 161 Julkaisuun ja tilauksiin perustuva toisintaminen 166 Etävarmistusjärjestelmät ss Osa 4: Rinnakkaistietokannat 170 Rinnakkaisjärjestelmät 173 Nopeutuvuus ja mitoittuvuus 178 Rinnakkaistietokanta-arkkitehtuurit 189 Tiedon osittaminen 194 Vinoumien käsittely 200 Kyselyiden välinen ja kyselynsisäinen rinnakkaisuus 204 Operaationsisäinen rinnakkaisuus 208 Rinnakkaisliitos 213 Operaatioiden rinnakkaislaskennan kustannus 215 Operaatioiden välinen rinnakkaisuus 218 Rinnakkaistietokannan kyselynoptimointi 221 Rinnakkaisjärjestelmän suunnittelusta ss Osa 5: Sivupalvelin- ja yhteislevyjärjestelmät 227 Tietopalvelin 232 Sivupalvelinjärjestelmän rakenne 237 Tiedon puskurointi asiakkailla 240 Sivupalvelinjärjestelmän tila 242 Päivitysten levittämiskäytännöt 247 Puskurieheys ja takaisinkutsut 251 Lokin hallinta 258 Asiakkaan häiriöistä elvytys 266 Palvelimen häiriöistä elvytys 274 Lukkojen hallinta 277 Yhteislevyjärjestelmä ss Osa 6: Hajautettujen transaktioiden käsittelyjärjestelmät 283 Yksi- ja kaksikerrosmallit 286 Tallennetut proseduurit 289 Kolmikerrosmalli 296 Istunnot ja konteksti 305 Jonotettu transaktionkäsittely 308 Transaktiomonitori 312 Transaktiomonitorin tarjoamat palvelut 315 Etäproseduurikutsu 320 Transaktionaalinen etäproseduurikutsu 326 Transaktioiden käsittely Internetissä 336 Www-sovelluspalvelimet: J2EE 345 Java-pavun rakenne 350 Papujen pysyvyydenhallinta 356 Papujen transaktionhallinta

2 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 , luku 16 (distributed databases). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Sixth Edition. McGraw-Hill, 2010; sivut , luvun 17 (database-system architectures) kohdat 17.4 (distributed systems) ja 17.5 (network types); sivut ja , 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 , luvun 20 (database-system architectures) kohdat 20.4 (distributed systems) ja 20.5 (network types); sivut ja , 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). 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 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. 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ä. 3 4

3 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. 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. 5 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). 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? 7 8

4 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. 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 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ä. 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

5 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. 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 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ä. 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)

6 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. 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 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. 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

7 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. 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 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. 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

8 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ä. 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 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. Vertaillaan vaihtoehtoja sen mukaan, kuinka paljon tietoa pitää siirtää pisteiden välillä mainituissa sovelluksissa. Tehdään seuraavat oletukset: Relaatiossa customer on noin 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

9 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 monikkoa kuukaudessa tai 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 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. 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 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 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. 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ä

10 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. 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 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. 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 monikkoa, kukin pituudeltaan = 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 monikkoa, kukin pituudeltaan = 15 tavua. Koska kuluva lukukausi on kesälukukausi, valtaosa opiskelijoista (10 000) ei ole ilmoittautunut millekään kurssille

11 Relaatioiden student ja transcript liitoksessa on noin monikkoa, kukin pituudeltaan = 18 tavua. Eri laskentastrategioiden tiedonsiirtokustannukset: 1. Jos molemmat relaatiot siirretään pisteeseen s 1 ja liitos lasketaan siellä, on siirettävä kaikkiaan = tavua. 2. Jos student-relaatio siirretään pisteeseen s 3 ja liitos lasketaan siellä, on siirrettävä kaikkiaan = tavua. 3. Jos transcript-relaatio siirretään pisteeseen s 2 ja liitos lasketaan siellä, on siirrettävä kaikkiaan = tavua. Paras kolmesta vaihtoehdosta on siis 1. 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) Pisteessä s 3 lasketaan väliaikainen relaatio P = select distinct student-id from transcript. Lähetetään P pisteeseen s 2. Siirtokustannus = 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 = 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 = tavua. Kaiken kaikkiaan siirretään siis = tavua, joten tämä suoritussuunnitelma on tietoliikennekustannuksissa mitaten aiemmin esitettyjä tehokkaampi. 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 = tavua. 3. Lähetetään transcript pisteeseen s 1. Siirtokustannus = tavua. Lasketaan siellä liitos R = select id, major, course-code from Q, transcript where id = student-id. Tämän suoritussuunnitelman kokonaiskustannus on = siirrettyä tavua

12 Puoliliitosta käytettiin yllä hyväksi seuraavalla tavalla. Relaatioiden r(x) ja s(y ) liitos r C s laskettiin muodossa r C s = (r C s) C s, missä puoliliitos r C s laskettiin muodossa r C s = π X (r C π Z (s)), missä attribuutit Z Y ovat liitosehtoon C sisältyvät s:n attribuutit. Siis kaiken kaikkiaan r C s = π X (r C π Z (s)) C s. Relaatioiden r(x) ja s(y ) luonnolliselle liitokselle pätee vastaavasti: r s = (r s) s = (r π X Y (s)) s. Liitokset, projektiot ja valinnat Tarkastellaan kyselyä, joka sisältää globaalin liitoksen lisäksi myös projektion: select distinct major, course-code from student, transcript where id = student-id. Suoritetaan projektio samassa pisteessä kuin liitoskin ja siirretään tulosrelaatio R sitten pisteeseen s 1. Arvioidaan viiden suoritussuunnitelmavaihtoehdon tiedonsiirtokustannukset. Sitä varten täytyy arvioida tulosrelaation R tavujen lukumäärä. Arvioidaan R:n monikoiden lukumääräksi 1 000, mikä on 5 % liitoksen monikoiden lukumäärästä. R:n monikko on = 9 tavua, joten R vie kaikkiaan = tavua Jos molemmat relaatiot siirretään pisteeseen s 1 ja lasketaan kysely siellä, on siirrettävä, kuten aiemmin, kaikkiaan tavua. 2. Jos student-relaatio siirretään pisteeseen s 3 ja lasketaan kysely siellä ja sitten siirretään tulos R pisteeseen s 1, joudutaan siirtämään kaikkiaan = tavua. 3. Jos transcript-relaatio siirretään pisteeseen s 2 ja lasketaan kysely siellä ja sitten siirretään tulos R pisteeseen s 1, joudutaan siirtämään kaikkiaan = tavua. 4. Jos suoritetaan puoliliitos pisteessä s 2 kuten aiemmin, on jälleen kaksi mahdollisuutta: (a) Siirretään puoliliitoksen tulos Q pisteeseen s 3, liitetään se transcript-relaation kanssa, projisioidaan tulos attribuuteille major ja coursecode ja siirretään tulos R sitten pisteeseen s 1. Siirtokustannus = tavua. (b) Siirretään sekä Q että transcript pisteeseen s 1 ja saatetaan laskenta loppuun siellä. Siirtokustannus , kuten aiemmin. Puoliliitos osoittautui nytkin edullisimmaksi, mutta nyt (a) oli parempi kuin (b). Tavanomaisessa kyselynoptimoinnissa sovellettavaa periaatetta, jossa kyselyn välituloksista projisioidaan pois jatkon kannalta tarpeettomat attribuutit, voidaan ja kannattaa soveltaa myös hajautetun kyselyn laskennassa. Relaatiossa student on todellisuudessa attribuuttien id ja major lisäksi myös useita muita attribuutteja, kuten name, address, ssn, entrance-date jne. Jos kyselyn tuloksessa tarvitaan student-relaation attribuuteista esim. vain major, voidaan puoliliitosta käyttävän suoritussuunnitelman askeleessa 2 puoliliitoksen tulokseen Q projisioida student-relaatiosta ainoastaan kyselyn tuloksessa ja liitoksessa tarvittavat attribuutit eli major ja id

13 Tarkastellaan sitten kyselyä, joka sisältää globaalin liitoksen lisäksi valinnan: select name from employee where title = manager and salary > Kysely sisältää globaalin liitoksen, kun relaatio employee on ositettu pystysuoriin palasiin employee1(ssn, name, salary) ja employee2(ssn, title, location). Oletamme, että employee1-palanen on sijoitettu pisteeseen s 2 (kaupan päätoimipiste) ja employee2-palanen pisteeseen s 3 (kaupan ainoa varastopiste). Kysely tehdään pisteessä s 1. Ositusmäärittelyn nojalla järjestelmä muuntaa kyselyn ensin relaation palasiin kohdistuvaksi: select e 1.name from employee1 e 1, employee2 e 2 where e 1.ssn = e 2.ssn and e 2.title = manager and e 1.salary > Sovelletaan keskitetyn tietokantajärjestelmän kyselynoptimoinnista tuttua periaatetta, jonka mukaan valinnat suoritetaan mahdollisimman aikaisin, ts. valintaoperaatiot työnnetään mahdollisimman syvälle kyselylausekkeeseen. 1. Pisteessä s 2 lasketaan relaatio R 1 = select from employee1 where salary > Pisteessä s 3 lasketaan relaatio R 2 = select from employee2 where title = manager. 3. Jossain pisteessä lasketaan R 1 :n ja R 2 :n liitos ja projisioidaan tulos attribuutille name: R 3 = select R 1.name from R 1, R 2 where R 1.ssn = R 2.ssn. Jos tämä piste ei ole s 1, lähetetään R 3 pisteeseen s Missä pisteessä askeleen 3 liitos pitäisi suorittaa? Suunnitelma 1: Siirrä R 2 pisteeseen s 2, laske siellä employee1:n ja R 2 :n liitos ja projektio attribuutille name ja siirrä tulos pisteeseen s 1. Suunnitelma 2: Siirrä R 1 pisteeseen s 3, laske siellä R 1 :n ja employee2:n liitos ja projektio attribuutille name ja siirrä tulos pisteeseen s 1. Suunnitelma 3: Siirrä R 1 ja R 2 pisteeseen s 1, laske siellä R 1 :n ja R 2 :n liitos ja projektio attribuutille name. Parhaan suunnitelman määräämiseksi täytyy ottaa huomioon relaatioiden ja välitulosten koot. Tehdään seuraavat oletukset: Attribuuttiarvojen pituudet ovat: ssn (amerikkalainen sosiaaliturvatunnus) 9 tavua; salary 6 tavua; title 7 tavua; location 10 tavua; name 15 tavua. employee1-monikon pituus on siis = 30 tavua ja employee2-monikon pituus = 26 tavua. Palasessa employee1, samoin kuin palasessa employee2, on noin monikkoa. Noin työntekijää ansaitsee yli Välituloksessa R 1 on siis noin monikkoa, kukin 30 tavua, eli yhteensä = tavua. Työntekijöistä on esimiehiä (manager) noin 50. Välituloksessa R 2 on siis noin 50 monikkoa, kukin 26 tavua, eli yhteensä = tavua. Noin 90 % esimiehistä ansaitsee yli Tuloksessa R 3 on siis noin 45 monikkoa, kukin 15 tavua, eli yhteensä = 675 tavua

14 Arvioidaan nyt kunkin suunnitelman kustannus. 1. Jos liitos tehdään pisteessä s 2, on siirettävä tavua pisteestä s 3 pisteeseen s 2 ja sitten 675 tavua pisteestä s 2 pisteeseen s 1, eli kaikkiaan tavua. 2. Jos liitos tehdään pisteessä s 3, on siirrettävä tavua pisteestä s 2 pisteeseen s 3 ja sitten 675 tavua pisteestä s 3 pisteeseen s 1, eli kaikkiaan tavua. 3. Jos liitos tehdään pisteessä s 1, on siirrettävä tavua pisteestä s 2 pisteeseen s 1 ja tavua pisteestä s 3 pisteeseen s 1, eli kaikkiaan tavua. Ylivoimaisesti parasta suunnitelmaa 1 voidaan vielä hiukan parantaa projisioimalla R 2 pisteessä s 3 attribuutille ssn ennen sen lähettämistä pisteeseen s 2. Monitietokantajärjestelmän kyselynoptimointi Monitietokantajärjestelmässä toimivalla sovelluksella ei ole globaalia kaaviota käytettävänään. Kysely, joka koskettaa useassa pisteessä sijaitsevia tietoja, pitää toteuttaa sarjalla SQL-kyselyitä, joista kukin formuloidaan asianomaisen pisteen tietokannan kaavion mukaiseksi ja lasketaan kyseisessä pisteessä. Vaikka globaalia kyselynoptimoijaa ei siis ole käytettävissä, sovelluksen suunnittelija voi soveltaa edellä esitettyjä menetelmiä sopivan SQL-kyselysarjan muodostamiseen. Sovellussuunnittelijan mahdollisuudet ovat tässä suhteessa kuitenkin rajatummat seuraavista syistä: 1. Monitietokantajärjestelmässä tietoa voidaan siirtää suoraan ainoastaan kyselypisteen ja yhden tietokantapisteen välillä, kun taas globaalia kyselynoptimoijaa käyttävässä järjestelmässä tietokantapisteet voivat kommunikoida suoraan keskenään. 2. Kahden tietokantapisteen välillä ei voida siirtää tietoa myöskään epäsuorasti kyselypisteen kautta. Vaikka kyselypiste voi vastaanottaa tietoa tietokantapisteestä SQL:n select-lauseen tuloksena, se ei voi lähettää välitulostietoa prosessoitavaksi toiseen tietokantapisteeseen, koska sovelluksen tietokantaliittymä rajoittuu SQL-lauseisiin. Puoliliitosoptimoinnin askeleen 1 matkiminen on siis käytännössä mahdotonta. (Askeleessa 1 relaation projektio lähetetään toiseen tietokantapisteeseen liitettäväksi siellä toisen relaation kanssa.) Tarkastellaan vielä pystysuoriin palasiin employee1 ja employee2 ositettua relaatiota employee ja siihen monitietokantajärjestelmän pisteessä s 1 kohdistettua kyselyä select e 1.name from employee1 e 1, employee2 e 2 where e 1.ssn = e 2.ssn and e 2.title = manager and e 1.salary > Aiemmin esitetyistä kolmesta suoritussuunnitelmasta suunnitelmat 1 ja 2 eivät tule kysymykseen (edellä esitetyistä syistä). Sovellussuunnittelija voi kuitenkin matkia suunnitelmaa Pisteeseen s 2 lähetetään laskettavaksi kysely select from employee1 where salary > , jonka tulos R 1 palautetaan kyselypisteeseen s Pisteeseen s 3 lähetetään laskettavaksi kysely select ssn from employee2 where title = manager, jonka tulos R 2 palautetaan kyselypisteeseen s Kyselypisteessä s 1 lasketaan R 1 :n ja R 2 :n liitos ja projisioidaan tulos attribuutille name: R 3 = select R 1.name from R 1, R 2 where R 1.ssn = R 2.ssn. Tämän suunnitelman kustannus, siirrettyä tavua, on edelleen parempi kuin yksinkertaisimman ratkaisun, jossa palaset employee1 ja employee2 siirretään kokonaisuudessaan kyselypisteeseen ( = siirrettyä tavua)

15 Tietokantasuunnitelman ja kyselyiden virittäminen Kuten keskitetyssä tietokantajärjestelmässä, hajautetun tietokantajärjestelmän kyselysuunnittelu sisältää eri vaihtoehtojen arvioimista: Operaatioiden suoritus eri pisteissä. Välitulosten tai kokonaisten relaatioiden siirtäminen pisteestä toiseen kyselyn suorituksen aikana. Puoliliitosten suorittaminen. Heurististen optimointisääntöjen käyttö relaatio-operaatioiden uudelleen järjestämiseksi kyselylausekkeessa. Globaalin kyselynoptimoijan käyttämiin strategiavalintoihin ei sovellussuunnittelijalla ole merkittäviä vaikutusmahdollisuuksia. Sitä vastoin sovellussuunnittelija voi yleensä määrätä hajautetun tietokannan rakenteesta, mm. tiedon ositustavasta. Tällä taas voi olla huomattava vaikutus kyselysuunnitteluun, koska tietokannan rakenne vaikuttaa globaalin kyselynoptimoijan käytettävissä oleviin suunnitelmavaihtoehtoihiin. Sama pätee myös monitietokantajärjestelmään, jossa kyselysuunnitelman tekee sovellussuunnittelija manuaalisesti. Keskitetyssä tietokannassa sovellussuunnittelija voi muuttaa tietokannan fyysistä kaaviota esimerkiksi lisäämällä relaatioihin hakemistoja tai luomalla materiaalistettuja näkymiä. Loogista kaaviota sovellussuunnittelija voi muuttaa esimerkiksi normaalistamalla tai epänormaalistamalla relaatioita. Hajautetun tietokannan tapauksessa sovellussuunnittelijalla on vielä muitakin mahdollisuuksia: Relaatioiden sijoittelu eri pisteisiin. Relaatioiden osittaminen eri tavoin ja palasten sijoittelu eri pisteisiin. Relaatioiden tai niiden sisältämien tietoalkioiden toisintaminen ja toisinteiden sijoittelu eri pisteisiin. Kuten keskitetyssä järjestelmässä, yksittäinen suunnittelupäätös voi johtaa tiettyjen operaatioiden nopeutumiseen ja toisten hidastumiseen. Suunnittelijan on arvioitava tietokantasuunnitelmaa sen mukaan, mikä on minkin sovellusoperaation suhteellinen frekvenssi ja kuinka tärkeää on operaation suoritustehto ja vasteaika Verkkokauppasovelluksessa inventory-relaation osittaminen vaakasuorasti varastopisteisiin nopeuttaa paikallisia sovelluksia, jotka liittyvät tavaratoimituksiin, mutta hidastaa globaaleja sovelluksia, joissa on tarpeen liittää relaation palasia, kuten esimerkiksi kaupan koko varastotilanteen laskemisessa. Eri suunnitelmavaihtoehtojen arvioinnin tuloksena yritys saattaa päättää, että tavaratoimitussovelluksen pitää suoriutua nopeasti, kun taas varastotilanteen laskeva sovellus voidaan suorittaa harvemmin eikä sen vasteajalle ole merkittävää vaatimusta. Varastotilanteen laskevaa sovellusta voitaisiin kyllä nopeuttaa toisintamalla varastojen tietoja päätoimipisteen tietokantaan. Mutta tämä vaihtoehto tulisi varmaan hylätyksi, koska varastotilannetietoa päivitetään usein joka kerta, kun tilaus toimitetaan ja koska toisinteiden päivittämisestä aiheutuvat tiedonsiirtokustannukset ovat paljon suuremmat kuin varastotilannesovelluksen ajaminen toisintamattomassa tietokannassa. Oraclen hajautetut tietokannat Monen muun kaupallisen järjestelmän tapaan Oraclen avulla toteutettu hajautettu tietokantajärjestelmä perustuu paikallisten kaavioiden yhdistekaavioon, jossa taulujen osittaminen ei ole tuntumatonta. Globaalin kaavion puuttuminen ilmenee esimerkiksi siitä, ettei eri pisteissä sijaitsevien taulujen välille voi luoda viite-eheysrajoitetta (viiteavainta). Hajautetun järjestelmän kullakin tietokantapalvelimella on yksilöivä globaali tietokantanimi (global database name), joka muodostetaan pisteen verkkoaluenimestä (esim. bodbacka.cs.helsinki.fi) ja paikallisesta tietokantanimestä (esim. ilmo): ilmo.bodbacka.cs.helsinki.fi. Tietokantanimiä säilytetään erityisessä (Oraclen nimipalvelimen tai LDAP-hakemistopalvelimen alaisessa) nimihakemistossa

16 Kun palvelimesta s 1 halutaan operoida palvelimeen s 2, on s 1 :ssä luotava tietokantalinkki (database link) s 2 :een (etäpalvelimeen). Esim. linkki palvelimeen ilmo.bodbacka.cs.helsinki.fi: create public database link ilmo.bodbacka.cs.helsinki.fi. Tämä linkki on julkinen (public), so. linkin luoneen palvelimen kaikilla sovelluksilla on pääsy linkin avulla etäpalvelimeen. Yksityinen (private) linkki sitä vastoin luodaan osaksi paikallisen palvelimen tiettyä tietokantakaaviota, jolloin ainoastaan linkin omistaja tai kaavioon kuuluvat PL/SQL-aliohjelmat voivat operoida linkin välityksellä etätietokantaan. Globaali (global) linkki on käytössä yli koko verkon. Minkä tahansa tietokannan käyttäjät ja PL/SQL-aliohjelmat voivat käyttää linkkiä. Globaaleja linkkejä hallinnoidaan Oraclen nimipalvelun avulla. Linkki määrittelee lisäksi mm., millä käyttäjänimellä linkin käyttäjä kirjautuu etätietokantaan ja miten käyttäjä todennetaan. Kun linkki etäpalvelimeen on luotu, paikallisen palvelimen sovellukset voivat viitata etäpalvelimen tietokannan tauluihin liittämällä niiden nimiin asianomaisen tietokantalinkin: select student-id from student@ilmo.bodbacka.cs.helsinki.fi where name = Meikäläinen, Matti Määrittelemällä etätietokannan taulun nimelle paikallinen synonyymi voidaan kätkeä sovellukselta taulun sijainti: create synomym student for student@ilmo.bodbacka.cs.helsinki.fi Nyt sovelluksessa voidaan viitata etätauluun kuten paikalliseen tauluun: select student-id from student where name = Meikäläinen, Matti Tällä tavalla Oraclessa toteutuu sijainnin tuntumattomuus Etätietoon kohdistuvat SQL-kyselyt ja -päivitykset jaetaan Oraclessa seuraaviin tyyppeihin: Etäkysely (remote query): SQL-kysely, joka kohdistuu yhden etätietokannan tauluihin (kuten esimerkissä edellä). Etäpäivitys (remote update): SQL-päivityslause, joka kohdistuu yhden etätietokannan tauluihin. Hajautettu kysely (distributed query): SQL-kysely, joka kohdistuu kahteen tai useampaan tietokantaan. Hajautettu päivitys (distributed update): PL/SQL-aliohjelma (kutsuttuna suoraan tai herättimen kautta), joka sisältää eri tietokantoihin kohdistuvia päivityksiä. Hajautettuja kyselyitä optimoidaan käyttäen Oraclen kustannusperustaista optimoijaa. Paikallinen Oracle-palvelin hajottaa hajautetun SQL-kyselyn eri etätietokantoihin kohdistuviksi etäkyselyiksi, lähettää ne etätietokantoihin käsiteltäviksi ja muodostaa etäkyselyiden vastauksista hajautetun kyselyn vastauksen. Oracle mahdollistaa heterogeenisen hajautetun tietokannan, jossa Oracle-palvelimien lisäksi on muiden toimittajien palvelimia. Heterogeenisyys voidaan kätkeä käyttäjältä. Tuntumattomien yhdyskäytävien (transparent gateway) avulla Oracle-palvelin voi olla yhteydessä useiden muiden järjestelmätoimittajien tietokantapalvelimiin. Yhdyskäytävä on (useimmiten vieraassa palvelinkoneessa toimiva) Oracle-ohjelmisto, joka tarjoaa Oracle-palvelimelle SQL-liittymän vieraaseen palvelimeen. Hajautetut transaktiot ovat mahdollisia myös heterogeenisessä järjestelmässä. Hajautetun transaktion atomisuus taataan kaksivaiheisella sitoutumiskäytännöllä. Oracle-sovelluksen SQL-lause, joka kohdistuu vieraaseen palvelimeen, muunnetaan tuntumattomasti vieraan palvelimen tunnistamaksi SQL-lauseeksi. Sovellus voi toisaalta suoraan operoida vieraan palvelimen tietokantaan tämän käyttämällä SQL-murteella (pass-through SQL)

17 Hajautettujen transaktioiden hallinta M. Kifer, A. Bernstein & P. M. Lewis: Database Systems. An Application-Oriented Approach. Complete Version. Pearson Addison Wesley, 2006; sivut , luvun 24 (implementing distributed transactions) kohdat 24.1 (implementing the ACID properties), 24.2 (atomic termination), 24.3 (transfer of coordination), 24.4 (distributed deadlock), 24.5 (global serialization) ja 24.6 (when global atomicity cannot be guaranteed); sivut , luvun 23 (architecture of transaction processing systems) kohta 23.4 (the TP monitor: global atomicity and the transaction manager). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Sixth Edition. McGraw-Hill, 2010; sivut ja ja , luvun 19 (distributed databases) kohdat 19.3 (distributed transactions) ja 19.4 (commit protocols), kohdan 19.5 (concurrency control in distributed databases) alakohdat (single lockmanager approach), (distributed lock manager) ja (deadlock handling), sekä kohdan 19.6 (availability) alakohta (coordinator selection). A. Silberschatz, H. F. Korth & S. Sudarshan: Database System Concepts. Fifth Edition. McGraw-Hill, 2006; sivut ja ja , luvun 22 (distributed databases) kohdat 22.3 (distributed transactions) ja 22.4 (commit protocols), kohdan 22.5 (concurrency control in distributed databases) alakohdat (single lockmanager approach), (distributed lock manager) ja (deadlock handling), sekä kohdan 22.6 (availability) alakohta (coordinator selection). C. Mohan, D. Haderle, B. Lindsay, H. Pirahesh & P. Schwartz: ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. ACM Transactions on Database Systems 17:1 (1992), ; sivut 114, kohta 4.3 (transaction table), ja , kohdan 6 (restart processing) alakohdat 6.1 (analysis pass), 6.2 (redo pass) ja 6.3 (undo pass). G. Samaras, K. Britton, A. Citron & C. Mohan: Two-phase commit optimizations and tradeoffs in the commercial environment. ICDE 1993, Proc. of the 9th IEEE Internat. Conf. on Data Engineering, 1993, Hajautetun tietokannan transaktiot, s. 63. Atominen sitoutuminen, s. 71. Kaksivaiheinen sitoutumiskäytäntö, s. 75. Usean alueen ylittävä atominen sitoutuminen, s. 86. Häiriöiden käsittely kaksivaiheisessa sitoutumiskäytännössä, s. 90. Pisteen elvytys häiriöstä, s. 94. Hajautettujen transaktioiden X/Open-käsittelymalli, s Hajautettu lukkiuma, s Globaali sarjallistuvuus, s Heikommat sitoutumiskäytännöt, s Hajautetun tietokannan transaktiot Hajautetun tietokantajärjestelmän jokainen piste s pystyy käsittelemään paikallisia transaktioita (local transaction), jotka operoivat ainoastaan pisteessä s säilytettäviin tietoihin. Piste voi myös osallistua globaaleihin transaktioihin (global transaction) eli hajautettuihin transaktioihin (distributed transaction), jotka operoivat useampien eri pisteiden tietoihin. Hajautettu transaktio, joka operoi pisteissä s 0,s 1,...,s n säilytettäviin tietoihin, koostuu alitransaktioista (subtransaction) T 0,T 1,...,T n, missä kukin T i on paikallinen transaktio eli operoi ainoastaan pisteen s i tietoihin. Alitransaktio T i käsittää siis hajautetun transaktion ne tietokantaoperaatiot, jotka kohdistuvat pisteen s i tietoihin. Piste s i (tai sen transaktionhallitsin), jonka suoritettavana on hajautetun transaktion jokin alitransaktio, on osallinen (cohort, participant) kyseiseen hajautettuun transaktioon. Hajautettu transaktio on itse asiassa joukko paikallisia transaktioita, joiden suoritusta koordinoidaan. Transaktion koordinoijana (coordinator) on useimmissa tapauksissa transaktion aloituspisteen transaktionhallitsin. Transaktion aloittajan valitseminen transaktion koordinoijaksi ei kuitenkaan aina ole paras ratkaisu. Aloituspiste ei ehkä ole luotettavin transaktion osallisista. Transaktio saattaa olla aloitettu jonkin toiminnon seurauksena myyntipisteen päätteeltä ja siihen voi sisältyä operointia kaupan pääkonttorin ja asiakkaan pankin tietokantapalvelimiin. On turvallisempaa koordinoida transaktio näistä palvelimista käsin. Tämä edellyttää mahdollisuutta siirtää transaktion koordinointi pisteestä toiseen. Toinen syy koordinoinnin siirtoon voi olla transaktion sitoutumisen koordinoinnin aikana vaihdettavien viestien määrän optimointi