Jaotatud andmebaasid ettevõtetele

CAP-teoreem on jaotusteooriate nurgakivi. Loomulikult ei vaibu vaidlused selle ümber: ka määratlemised ei ole kanonilised, ja ranget tõestust pole... Siiski, seistes kindlalt igapäeva mõistuse positsioonides™, mõistame me intuitsiooniliselt, et teoreem on tõene.

Ainus asi, mis ei ole ilmne, on täht 'P'. Kui klaster jaguneb, siis ta otsustab – kas mitte vastata, kuni kvoorum on kogutud, või anda need andmed, mis on olemas. Selle valiku tulemuste alusel klassifitseeritakse süsteem kas CP-ks või AP-ks. Cassandra võib näiteks käituda nii ja naa, sõltumata isegi klasteri seadistustest, vaid iga konkreetse päringu parameetritest. Aga kui süsteem ei ole 'P' ja see on jagunenud, siis – mis siis?

Sellele küsimusele on vastus veidi ootamatu: CA-klaster ei saa jaguneda.
Mis klaster see siis on, mis ei saa jaguneda?

Sellise klastri kohustuslik atribuut on ühine andmete salvestussüsteem. Enamikul juhtudel tähendab see liitumist SAN-iga, mis piirab CA-lahenduste rakendamist suurte ettevõtete hulka, kes suudavad seadistada SAN-infrastruktuuri. Selleks, et mitu serverid saaksid töötada samaaegselt ühtede ja samade andmetega, on vajalik klasteri failisüsteem. Sellised failisüsteemid on saadaval HPE (CFS), Veritas (VxCFS) ja IBM (GPFS) portfellis.

Oracle RAC

Real Application Clustere valik sai esmakordselt tutvustatud 2001. aastal Oracle 9i väljaandes. Sellises klastris töötavad mitu eksemplari serverilt ühe ja sama andmebaasi kallal.
Oracle võib töötada nii klasteri failisüsteemi kui ka oma lahendusega – ASM, Automatic Storage Management.

Iga eksemplar peab oma logi. Tehing toimub ja fikseeritakse ühe eksemplari poolt. Juhul kui eksemplar ebaõnnestub, loeb üks ellujäänud klastrite sõlmedest (eksemplaridest) selle logi ja taastab kadunud andmed – seeläbi tagatakse kättesaadavus.

Kõik eksemplarid toetavad oma vahemälu ning ühed ja samad lehed (plokid) võivad olla samal ajal mitme eksemplari vahemälus. Veelgi enam, kui mõni leht on vajalik ühe eksemplari jaoks ja see on teise eksemplari vahemälus, võib ta selle saada 'naabrilt' cache fusion mehhanismi abil, selle asemel et lugeda diskilt.

Aga mis juhtub, kui mõni eksemplar vajab andmete muutmist?

Oracle'i eripära on see, et tal pole eraldi lukustusteenust: kui server soovib rida lukustada, siis lukustuse kirje pannakse otse mälulehele, kus lukustatav rida asub. Tänu sellisele lähenemisele on Oracle monoliitsete andmebaaside seas tootlikkuse meister: lukustusteenus ei muutu kunagi kitsaskohaks. Kuid klastrikonfiguratsioonis võib selline arhitektuur põhjustada intensiivset võrgu liiklust ja vastastikuseid lukustusi.

Niipea, kui kirje on lukustatud, teavitab eksemplar kõiki teisi eksemplare, et leht, kus see kirje asub, on monopolirežiimis kinni. Kui teisele eksemplarile on vajalik muutmine samal lehel, peab ta ootama, kuni lehe muudatused on fikseeritud, st teave muudatuste kohta ei ole salvestatud kettajournaali (sel ajal võib tehing jätkuda). Juhtuda võib ka see, et lehte muudavad järjestikku mitmed eksemplarid ning siis tuleb lehe salvestamisel kettale välja selgitada, kellel on selle lehe ajakohane versioon.

Juhuslikud uuendused sama lehe kaudu erinevate RAC sõlmede kaudu toovad kaasa andmebaasi tootlikkuse järsu languse – nii palju, et klastrite tootlikkus võib olla madalam kui ühe eksemplari tootlikkus.

Oracle RAC'i õige kasutamine on andmete füüsiline jagamine (näiteks sektsioneeritud tabelite mehhanismi abil) ja igale sektsioonide kogumile pöördumine läbi eraldatud sõlme. RAC'i peamine eesmärk ei ole horisontaalne skaleerimine, vaid rikke taluvuse tagamine.

Kui sõlm hakkab südamepekslemiseks vastama, käivitab kõigepealt see sõlm, mis esimesena seda tuvastas, hääletusprotseduuri kettale. Kui ka siin ei registreerita kadunud sõlme, siis üks sõlmedest võtab enda kanda andmete taastamise kohustused:

• „külmutab” kõik lehed, mis olid kadunud sõlme vahemikus;
• loeb kadunud sõlme taastamislogisid (redo) ja rakendab uuesti neid muudatusi, mis on nende logide sisse kirjutatud, samal ajal kontrollides, kas teistel sõlmedel on muutuvate lehtede uuemad versioonid;
• tagastab lõpetamata tehingud.

Oracles on teenuse mõisted, et hõlbustada sõlmede vahetamist – virtuaalset eksemplari. Eksemplar võib teenindada mitmeid teenuseid ja teenus võib liikuda sõlmede vahel. Rakenduse eksemplar, mis teenindab teatud osa andmebaasist (näiteks klientide grupi), töötab ühe teenusega, samas kui teenus, mis vastutab selle osa andmebaasist, liigub sõlme rikke korral teise sõlme.

IBM Pure Data Systems for Transactions

Klasterlahendus andmebaaside haldamiseks ilmus Sinise Gigandi portfelli 2009. aastal. Ideoloogiliselt on see Parallel Sysplexi klastrile järglaseks, mis on üles ehitatud "tavalisele" riistvarale. 2009. aastal tuli turule toode DB2 pureScale, mis on tarkvaraplatvormide komplekt, ja 2012. aastal pakkus IBM tarkvaraalust ja riistvaralist komplekti nimega Pure Data Systems for Transactions. Seda ei tohiks segi ajada Pure Data Systems for Analytics'iga, mis on lihtsalt ümbernimetatud Netezza.

PureScale'i arhitektuur näeb esmapilgul välja nagu Oracle RAC: mitmed sõlmed on ühendatud ühise andmesalvestussüsteemiga, ja igal sõlmel töötab oma andmebaasi eksemplar koos oma mälualade ja tehinguajalooga. Kuid erinevalt Oracle'ist on DB2-s eraldiseisev lukuhalduse teenus, mida esindavad protsesside komplekt db2LLM*. Klasterkonfiguratsioonis viidatakse sellele teenusele eraldi sõlmele, mida Parallel Sysplex'is nimetatakse coupling facility (CF) ja Pure Data-s PowerHA-ks.

PowerHA pakub järgmisi teenuseid:

• lukuhaldur;
• üldine vahemälu;
• protsessidevaheline sideala.

Andmete edastamiseks PowerHA ja andmebaasi sõlmede vahel kasutatakse kaugjuurdepääsu mälule, seetõttu peab klasteri vahel olema toetatud RDMA protokoll. PureScale võib kasutada nii Infiniband'i kui ka RDMA over Ethernet'i.

Kui sõlm vajab lehte ja see leht ei ole vahemälus, siis sõlm küsib lehte globaalsetest vahemäludest ja ainult juhul, kui ka seal ei ole, loeb selle plaadilt. Erinevalt Oracle'ist, toimub päring ainult PowerHA-s, mitte naaber sõlmedes.

Kui eksemplar on vahetamas rida, blokeerib see selle eraldisrežiimis ja lehe, kus rida asub, jagatud režiimis. Kõik blokeeringud registreeritakse globaalsetes blokeerimishaldurites. Kui tehing on lõpetatud, saadab sõlme teate blokeerimishaldurile, kes kopeerib muudetud lehe globaalsetesse vahemälu, vabastab blokeeringud ja tühistab muudetud lehe teiste sõlmede vahemälu.

Kui leht, kus muudetud rida asub, on juba blokeeritud, loeb blokeerimishaldur muudetud lehe mälust, mis muudatused teinud sõlmem, vabastab blokeeringu, tühistab muudetud lehe teiste sõlmede vahemälu ja annab blokeeringu lehe tagasi sõlmele, kes selle soovis.

Muutunud, st „räpased” lehed võivad kettale kirjutada nii tavalisest sõlmedest kui ka PowerHA-st (castout).

Kui üks pureScale'i sõlm tõrkub, piirneb taastumine ainult nende tehingutega, mis katkestuse ajal olid veel lõpetamata: lehed, mida see sõlm on lõpetatud tehingutes muutnud, on globaalses vahemälu PowerHA-s. Sõlm käivitatakse kärbitud konfiguratsioonis ühel klastriserveritest, tagasi keerab lõpetamata tehingud ja vabastab blokeeringud.

PowerHA töötab kahel serveril, ja peamine sõlm replitseerib oma seisundi sünkroonselt. Peamise sõlme tõrke korral jätkab PowerHA klaster tööd varusõlmega.
Muidugi, kui andmekogule juurde pääseda läbi ühe sõlme, on klastri üldine jõudlus suurem. PureScale võib isegi märgata, et teatud andmeala töödeldakse ühe sõlmega, ning siis käsitletakse kogu selle ala blokeeringud kohapeal ilma kommunikatsioonita PowerHA-ga. Ent niipea, kui rakendus püüab nendele andmetele juurde pääseda läbi teise sõlme, taastub tsentraliseeritud blokeeringute käsitlemine.

IBM-i sisetestid koormusega, mis sisaldab 90% lugemist ja 10% kirjutamist, mis on väga sarnane tegelikule tööstuslikule koormusele, näitavad peaaegu lineaarset skaleerimist kuni 128 sõlme. Kahjuks ei avalikustata katsetingimusi.

HPE NonStop SQL

Hewlett-Packard Enterprise'il on ka oma kõrge kättesaadavuse platvorm. See on NonStop platvorm, mis tuli turule 1976. aastal ettevõtte Tandem Computers poolt. 1997. aastal omandas ettevõtte Compaq, mis omakorda liitus Hewlett-Packardiga 2002. aastal.

NonStop'i kasutatakse kriitiliste rakenduste, näiteks HLR või pangakaartide töötlemise, loomiseks. Platvormi tarnitakse seadme (appliance) kujul, mis sisaldab arvutusnode, andmesalvestussüsteemi ja kommunikatsiooniseadmeid. ServerNeti võrk (kaasaegsetes süsteemides – Infiniband) teenib nii node'ide vahelist suhtlust kui ka juurdepääsu andmesalvestussüsteemile.

Süsteemi varasemates versioonides kasutati patenteeritud protsessoreid, mis olid omavahel sünkroniseeritud: kõik toimingud viidi läbi sünkroonselt mitme protsessori poolt ja kui üks protsessor tegi vea, lülitus see välja, samal ajal kui teine jätkas tööd. Hiljem ületas süsteem tavaprotsessoritele (esialgu MIPS, seejärel Itanium ja lõpuks x86) ning sünkroniseerimiseks hakati kasutama teisi mehhanisme:

• teated: igal süsteemi protsessil on topelt-"vari", millele aktiivne protsess perioodiliselt saadab teate oma seisundi kohta; kui peamine protsess ebaõnnestub, alustab vari tööd viimasest teadest määratud hetkel;
• häälte andmine: andmesalvestussüsteemil on spetsiaalne riistvarakomponent, mis võtab vastu mitu identset päringut ja täidab need ainult siis, kui päringud kattuvad; füüsilise sünkroniseerimise asemel töötavad protsessorid asünkroonselt ja nende töö tulemused võrreldakse ainult sisendi/väljundi hetkedel.

Alates 1987. aastast töötab NonStop platvormil relaatsiooniline andmebaasisüsteem – esmalt SQL/MP ja hiljem SQL/MX.

Kogu andmebaas jaguneb osadeks, millest igaühe eest vastutab oma Data Access Manager (DAM). See võimaldab andmete salvestamist, vahemällu salvestamist ja lukustamismehhanismi. Andmete töötlemisega tegelevad täitmisprotsessid (Executor Server Process), mis töötavad samadel sõlmedel, mis vastavad andmehalduri jaoks. SQL/MX planeerija jagab ülesanded täitjate vahel ja liidab tulemused. Kooskõlastatud muudatuste tegemiseks kasutatakse kahefaasilist kinnitamisprotokolli, mida tagab TMF (Transaction Management Facility) teeg.

NonStop SQL oskab prioriseerida protsesse nii, et pikad analüütilised päringud ei takistaks tehingute täitmist. Kuid selle eesmärk on just lühikeste tehingute töötlemine, mitte analüüs. Arendaja garanteerib NonStop-klasteri kättesaadavuse tasemel viis "üheksa", mis tähendab, et seisak on vaid 5 minutit aastas.

SAP HANA

Esimene stabiilne andmebaasi HANA (1.0) väljaanne ilmus novembris 2010 ning SAP ERP pakett tõi välja HANA-le maist 2013. Platvorm põhineb ostetud tehnoloogiatel: TREX Search Engine (kolonnande andmete otsing), P*TIME andmebaas ja MAX DB.

Sõna "HANA" on akronüüm, High performance ANalytical Appliance. See andmebaas tarnitakse koodina, mis saab töötada igasugustel x86 serveritel, kuid tööstuslikud installatsioonid on lubatud ainult sertifitseeritud seadmetel. Üksused HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC pakuvad lahendusi. Mõned Lenovo konfiguratsioonid võimaldavad isegi töötamist ilma SAN-ita – kluster GPFS kohalikel ketastel täidab ühise andmesalvestuse rolli.

Erinevalt eespool loetletud platvormidest on HANA mäluandmebaas, see tähendab, et andmete peamine pilt hoitakse operatiivmälu, samas kui kettale kirjutatakse ainult logid ja perioodilised mängupildid – taastamiseks hädaolukordades.

Iga HANA klastrisõlm vastutab oma andmeosa eest, andmekartograafia hoitakse spetsiaalses komponendis – Name Server, mis asub koordinaatori sõlmes. Andmeid sõlmede vahel ei dubleeritud. Info lukustuste kohta hoitakse samuti igas sõlmes, kuid süsteemis on globaalne deadlock-detektor.

HANA klient laadib klastre topoloogia, kui ta ühendub, ja saab hiljem otseselt suhelda mis tahes sõlmaga, sõltuvalt vajalikest andmetest. Kui tehing hõlmab ainult ühe sõlme andmeid, saab see tehing täita kohalikult, kuid kui muutuvad mitme sõlme andmed, pöördub algsõlm koordinaatori poole, kes avab ja koordineerib jaotatud tehingut ning fikseerib selle optimeeritud kahefaasilise fikseerimise protokolli abil.

Koordinaatori sõlm on duplikaat, seega, kui koordinaator ebaõnnestub, astub koheselt tööle varusõlm. Kui aga ebaõnnestub andmesõlm, on ainus võimalus pääseda tema andmetele – käivitada sõlm uuesti. Üldiselt hoitakse HANA klastrites varu (spare) serverit, et kaotatud sõlm saaks võimalikult kiiresti uuesti käivitatud.

Allikas: habr.com