Hajutatud andmebaaside teema lahtikirjutus ja lugemisülesanded

Allikas: Lambda

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

Loe palun kõigepealt läbi teemade ülevaade järmistes kahes peatükis ja seejärel detailsemad materjalid viimases peatükis.

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

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


Replikeerimine baasides

Põhiststsenaarium:

  • 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: 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.
  • Eksootiline variant 3: osa tulpasid suurest tabelist server 1, osa server 2,

Arusaadavalt on neid kolme varianti võimalik kombineerida.

Materjalid lugemiseks ja vaatamiseks

Data warehouse teemal

  • Kalle Tominga loeng ja materjalid: sa oled võibolla neid varem näinud IT sissejuhatuse aines, nüüd oleks sobiv nad uuesti üle vaadata: Kalle loeng, otsi "October 7, 2019" video ja vaata läbi vähemalt esimene pool. Sinna kõrvale presentatsioon.
  • Põhjalik tutorial: Kindlasti 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.

Täiendavalt on soovitav tutvuda:

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


Hajutatud andmebaasid:

Täiendavalt on soovitav tutvuda:

  • semi-join on spetsiaalne põhimeetod joinide optimeerimiseks andmebaaside osadest eri masinates. See väike presentatsioon tasub läbi lugeda.
  • alternatiivne hea ülevaade Siin antakse eelmise põhjaliku tutorialiga sarnane ülevaade, aga lühem ja lihtsam ja veidi teise vaatega. Kui sulle eelmine põhjalik tutorial jäi segaseks, siis tasub korra täiendavalt vaadata siia.

Täiendavalt on soovitav tutvuda teemaga Postgresi näitel: