Hajutatud andmebaaside teema lahtikirjutus ja lugemisülesanded

Kõige lihtsamal juhul on meie andmed ühes konkreetses andmebaasis ühes arvutis. See on selgelt kõige kergemini hallatav viis ja enamasti võimaldab ka päringuid kõige kiiremini teha. Miks aga vahel niimoodi mitte teha? Üldiselt on kaks peamist põhjust, mis tekitavad hoopis erinevaid probleeme ja ülesandeid:

• Data warehouse teema: vaja integreerida palju päris erinevaid infosüsteeme/andmebaase.
• Distributed databases teema: andmebaas on liiga suur ja/või liiga palju kasutajaid, et üks masin välja veaks, vaja jagada töö hulga masinate vahel

Data warehouse teema: kuidas eri andmebaase integreerida

Olukord: ettevõttes või organisatsioonis on palju eri osakondi oma infosüsteemide ja andmebaasidega. Näiteks, eraldi tootmisüksused, eraldi laoarvestuse, personali, finantsteenistuse üksused. Riigi mastaabis eraldi ministeeriumid ja ametid, näiteks politsei andmebaasid, kinnisvara andmebaasid jne. Sellised andmebaasid tekivad ja neid hallatakse üksteisest suhteliselt sõltumatult.

Seejuures on

• hea, et iga andmebaas jõuab tüüpiliselt ühes masinas kenasti töötada
• halb, et on väga keeruline teha süsteemi, mis teeks päringuid üle paljude eri andmebaaside korraga (a la päringus oleks korraga vaja infot laoarvestuse ja finantsteenistuse andmebaasidest).

Siin valdkonnas lahendatakse seda viimast, "halb" muret, reeglina sel viisil, et tehakse eraldi infot koondav andmebaas mida nimetatakse andmelaoks (data warehouse): sinna tõmmatakse regulaarselt infot kokku eraldi andmebaasidest. Selleks teeme iga baasi külge proge, mis ööseti pumpab päeva data kesksesse baasi ühisesse schemasse:

• sellelt saab teha joine
• tekivad päevased snapshotid

Et data warehouse tekiks, on vaja teha nn ETL proged:

• Extract proged
• Transform proged: teisendab data ühise schema jaoks
• Load: pumpad transformituddata warehouse andmebaasi

Põhieesmärk data warehousel: regulaarne ülevaateraportite tegemine.

Veidi sarnane või seotud teema on Linked data, mis on teine suund/eesmärk integreerimiseks: andmete scrapemine webist ja kogumine apidest ehk machine-readable web. Selle ideoloogiline fookus läks "semantic web" projekti, mis muutus akadeemiliseks ja ebapraktiliseks. Põhiefekt oli push kasutada rdf-i universaalse dataformaadina. Tim Berners-Lee rebrandis ja refokuseeris oma tegevuse ses suunas hiljem kui "Linked Data" .

Detaile lisaks

• Kalle Tominga loengumaterjalid: presentatsioon.
• Põhjalik tutorial: loe läbi esimesed osad, kuni (kaasa arvatud) ETL (Extract, Transform, and Load) Process. Kui sul tekib huvi teema vastu, siis vaata täiendavalt järgmisi osi.
• Kalle Tominga doktoritöö. Kui sul tekkis huvi teema vastu, siis siin kiireks tutvumiseks, et mis küsimused näiteks tekivad ja kuidas neid lahendada. Põhifookus töös on spetsiifilisel küsimusel, et kuidas uurida, kust andmed jõuavad erinevatesse päringutesse/raportitetesse ja milliseid tabeleid/välju rohkem kasutakse. Loomulikult ei jõua sa seda tööd süvenemisega lugeda.

Distributed databases teema: kuidas jagada ühe baasi töökoormus mitme masina vahel

Võimalikud olukorrad:

• üks konkreetne suur andmebaas (näiteks Skype kõned, kliendid jne või Google ülemaailmsed andmebaasid jms) on liiga suur selleks, et üks masin jõuaks temaga hakkama saada, st piisava kiirusega päringuid teha, andmeid lisada jne,
• või tahame lisaks, et ülemaailmse maailmabaasi osad oleks mingi piirkonna klientidele lähemal, et optimeerida võrguliiklust (CDN teema)
• või on meil vaja töökindlust tõsta, tehes andmebaasist klooni, millele kohe üle minna, kui põhiandmebaasi masin miskipärast rikkis või temaga ei ole ühendust.

Seejuures on kaks suurt küsimust:

• Kuidas infot andmebaasis eri masinate vahel jagada ja sünkroniseerida
• Kuidas teha päringuid kiiresti, kui info on eri masinate vahel jagatud

Näiteks, skypes läks kohe alguses vaja kasutajate ja nende tegevuste andmebaasi jagamist mitme masina vahel. Väikese süsteemi puhul ei juhtu neid asju kunagi.

Olulised (näite)süsteemid: Memcached ja Redis

Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.

Oluline ja võimsam ja rohkem kasutatav analoogiline süsteem on redis.

Mõlemid on key-value baasid:

{"http://xx.com/api/people":23,
 "bsesd": "dfsdfsdf",
 ...
} 

Nend põhirakendus: päringute cachimine.

Tüüpilised API päringud:

• keyd
• aeg, millal salvestati
• data

Memcachedit on lihtne panna korraga mitme masina peale. Variandid mis oleks:

• (memcached ei tee seda) iga server sisaldab kogu datat
• (seda memcached teeb) iga server sisaldab osa datat

Mis juhtub, kui uus data tuleb mingi keyga "k1":

• peame otsustama mis serverisse panna
• päring otsib "k1"-te: peame teadma mis serveris ta on ja sealt küsima. Selleks:
  • arvutad key hashi
  • hash("k1") oleks ntx 192202
  • jagad serverite arvuga, saad jäägi: see on serveri nr

Redise kaks põhierinevust memcachedist:

• Salvestatud väärtused saavad olla keerulisemad andmestruktuurid.
• Redises toimub hajutamine toimub hierarhiliselt master-slave põhimõttel, memcachedis on see lihtsam hashipõhine, nagu ülal kirjeldatud.

Vt ka ok võrdlus.

Tükkideks jagamine ning replikeerimine andmebaasides

Tükkideks jagamise põhiststsenaariumid:

• data ei mahu ära või
• server ei jaksa vastata päringutele

Jagame osa datat ühte serverisse teise osa teise, kolmanda kolmandasse jne

Mis põhimõtte järgi? Variandid:

• Variant 1 (horisontaalne): jagame väga suured tabelid a la memcachedi moodi ridade kaupa, näiteks kasutajanime esitähe järgi:
  • a-c: server 1
  • d-k: server 2.
  • ...
  • x-z: server N

• Variant 2: osa tabeleid serverisse 1, osa serverisse 2, jne.

• Variant 3 vertikaalne: osa tulpasid suurest tabelist server 1, osa server 2,

Arusaadavalt on neid kolme varianti võimalik kombineerida.

Lühikese ülevaate annab wikipedia partitioning artikkel

Küllalt sarnane asi on replikeerimine: koopiate hoidmine mitmes baasis. Eesmärk võib olla sama, mis ennist kirjeldatud (suured mahud) või töökindluse tõstmine (kui mõni masin rikki läheb).

Detaile lisaks:

• Postgres replication intro
• Postgres clustering and replication
• Postgresi enda dokud teemal