7.SUURTE ANDMEBAASIDE ADMINISTREERIMISE ISEÄRASUSED

7.1. Suured andmebaasid – midagi erilist?

Käesolevas peatükis räägime andmebaaside erinevate ressursside dimensioonidest, mille mahtude suurenemisel võivad oluliselt muutuda need nõuded ja tehnilised vahendid, mida tavaliselt nende ressursside haldamiseks kasutatakse.

Muutuvad dimensioonid

Korrektselt toimiva infosüsteemi tähtsaimaks aluseks on “õigesti” projekteeritud ja rakendatud andmebaas, kuid see, mis peab olema “õigesti” projekteeritud ja rakendatud, on oma mõõtmetelt tunduvalt laiem kui seda on andmebaas klassikalises tähenduses. Reaalselt eksisteeriv andmebaas omab oma terviklikku ja tegelikku tähendust ainult vaadelduna koos tema kasutuskeskkonna ja kasutajatega.

Andmebaasi mõiste piiride hägusus

Tavaliselt kui räägitakse andmetebaasidest, siis mõeldakse selle all enamasti instrumentide komplekti, mis sisaldab:

Andmebaasi all mõistetakse enamasti

●

struktureeritud andmeid – skeemid (schemes), tabelid (tables), vaated (views) jms.

Andmed

●

tabelite vahelisi seoseid – relatsioonid (relations) ja seose terviklikkus (referential integrity)

Seosed

●

andmeotsingu kiirendeid – indeksid (indexes)

Indeksid

●

piiranguid – andmetüübid (data types), formaadid (formats), tingimused (constraints) jms.

Piirangud

●

andmebaasiprotseduure (procedures)

Protseduurid

●

andmete käsitluskeelt – SQL-keel (Structured Query Language) või kirje kaupa pöördus (RLA- Row Level Access)

Käsitluskeel

Kui andmebaasi vaadata tõepoolest ainult sellise instrumentide kogumina, siis võib „suure“ andmebaasina käsitleda ainult suure andmemahuga andmebaase. Andmebaasisüsteeme tootvate firmade käibesse ongi tekkinud mõiste VLDB (Very Large Database), millega tähistatakse väga suuri andmekogumeid, mis on organiseeritud andmebaasidena. Üldiselt kapseldatakse kogu probleemistik suurte andmebaaside puhul peamiselt nelja teemasse:

Väga suur andmebaas - VLDB

●

andmete pärimise kiirus – suurtes andmebaasides kulub andmete pärimise peale oluliselt rohkem aega, kuna vajalike andmete otsimine suurema hulga andmete seast võtab lihtsalt rohkem aega. Lisaks sellele kipuvad suuremates andmebaasides ka päringute tulemused (selection) olema pikemad. Kõik see nõuab kiireid kettaseadmeid ja oluliselt parema metoodikaga programme.

Andmete pärimise kiirus

●

andmete varundamise metoodikad, mis tagaksid piisavalt lühikese ajaga varunduskoopiate tegemise; probleemi tekitab see, et mida rohkem on andmeid, seda kauem võtab aega nende varundamine. Paraku on aga varundamiseks kasutada võimalik aeg piiratud. Kasutatakse meetodeid, kus terviklik varundus koopia tehakse ainult üks kord – kõige alguses. Edaspidi tehakse varunduskoopiaid nendest andmebaasi osadest, mis eelmisest varunduskoopiast alates on muutunud. Uus terviklik varunduskoopia tehakse eelmisest terviklikust koopiast lisades sellele muudatuste varunduskoopia jne.

Andmete varundamise metoodikad

●

andmete taastamine võimalikult lühikese ajaga – see on üks keerukamaid probleeme. Kui varundada saab andmeid ositi (nagu ülal pool kirjeldatud), siis taastada saab andmebaasi alati ainult tervikuna – viimasest loodud terviklikust varunduskoopiast. Siin on kasutiusel erinevad meetodid andmebaaside kiirlaadimiseks.

Andmete taastamise metoodikad

●

Andmete jaotamine erinevate seadmete vahel tagamaks andmete võimalikult kiiret riistvaralist käsitlust. See teema haakub otseselt kõigi eelmiste teemadega, kuid on siiski täiesti eraldi seisev probleem – riistvara aeglus on oluliseks piiravaks teguriks kõigi eelnevate probleemide lahendamisel. Lisaks andmete jagamisele erinevate seadmete vahel ja seeläbi paralleeltöötluse võimaluse tekkimisele otsitakse pidevalt uusi ja kiiremaid tehnilisi lahendusi. Nii näiteks on Oracle uues andmebaasiserveris kasutusel kuni 2TB suurune välk-mälu cash mis asetseb „ketaste ja kasutajate vahel“, ning muudab töö andmetega kümneid kordi kiiremaks.

Andmete jaotamine

Tegelikkuses on „andmebaaside suurusega“ seotud probleemide juured hoopis laiemad, kui seda on lihtsalt andmete suur maht. Sama suureks probleemiks, kui andmete suur maht, võib andmebaaside puhul osutuda mistahes teine omadus, mille maht on võrreldes tavalisega ülepaisutatud. Nii näiteks võib mahult suhteliselt keskmise või isegi tagasihoidliku suurusega andmebaasi haldamise teha tavalisest oluliselt keerukamaks tavatult suur kasutajate hulk või andmete äärmiselt kõrge konfidentsiaalsuse tase.

Andmebaaside suuruse mitu tahku

Selleks, et andmebaasi suuruse probleemi vaadata laiemalt, peame me veidi laiemalt vaatama ka andmebaase endid. Tegelikkuses ei vaadeldagi andmebaase enam ammu sugugi nii kitsalt, kui me tegime seda käesoleva jaotise alguses. Tegelikkuses võib igale toimivale andmebaasile (aga selliseid me ju vaatleme) lisada üsna mitu instrumenti, ilma milleta reaalses töös andmebaasidega hakkama ei saa – eriti, kui meie andmebaas on suur (ükskõik, mille poolest siis ta suur on):

Andmebaas laimealt vaadatuna

●

monitooringu vahendid – selleks, et näha ressursside kasutamise muutumist ja pudelikaelu ressursside kasutamisel

Monitooringu vahendid

●

andmebaaside administreerimise vahendid – kasutajate haldamine, mälustruktuuride haldamine, süsteemi parameetrite häälestamine.

Administreerimise vahendid

●

õiguste tagamise vahendid, mille abil garanteeritakse, et kasutajatele jagatud õigused ka realiseeruvad.

Õiguste tagamine

●

liidesed teiste süsteemidega – ODBC, OLE DB, JDBC, native link (mis on andmebaasi spetsiifiline), XML, SOAP, jne.

Liidesed teiste süsteemidega

●

andmebaaside vahelise andmete edastamise vahendid, mis võimaldavad hoida erinevaid andmebaase sünkronis ja vahetada informatsiooni andmebaaside vahel

Andmebaaside vaheline andmevahetus ja sünkroniseerimine

●

rakendused andmebaaside kasutamiseks

Rakendused

Kui nüüd hakata üle kõigi ees poo kirjeldatud instrumentide vaatama, mille poolest üks andmebaas „suur“ saab olla, siis märkame kohe, et andmebaasi võib suureks teha hoopis midagi muud, kui seda on andmete maht. Järgnevalt püüamegi vaadelda erinevaid „mõõtmeid“ mille poolest üks andmebaas võib olla „suur“.

Andmebaasi „suurus“ võib peituda hoopis milleski muus kui suures andmete mahus

„Kuidas“ või „mille poolest“ üks andmebaas siis SUUR olla võib? Selliseid tahke on üsna mitu. Ühest me juba rääkisime. See on andme mahult suur andmebaas. Aga vaatame nüüd teisi ka.

3.1. „Multi-andmebaas“

Ei ole ilmselt sellist ettevõtet, mille infosüsteemi kõik rakendused kasutaksid sama andmebaasi. Aga olenevalt ettevõtte suuruselst ja selle sisemise struktuuri mitmekesisusest võib neid andmebaase, mida kasutatakse, olla hoopiski palju rohkem kui neid tavalistes tingimustes (3-5) kasutatakse. Seega - andmebaas võib olla suur alam-andmebaaside arvult. See tähendab seda, et mingil põhjusel on kunagi infosüsteem üles ehitatud selliselt, et iga infosüsteemi osa kasutab omaette andmebaasi ja kui neid infosüsteemi osi on meil palju, siis ongi meil käes ka üks üpris suur probleem. On selge, et kui need erinevad infosüsteemi osad moodustavad kokku ühtse terviku, siis on nendes andmebaasides kokku väga suur infoliiasus. Mida see tähendab? Tähendab see seda, et samu andmeid vajatakse mitmete erinevate infosüsteemide töös. Kuna iga neist kasutab tööks erinevat andmebaasi, siis peavad need andmed olemas olema kõikides neis baasides, mida kasutavad infosüsteemi osad neid vajavad. Ja see võib tekitada olulisi probleeme.

Palju (alam)andmebaase – suur infoliiasus

Kui samad andmed asuvad mitemetes baasides, siis on nad sõltumatult muudetavad. Mistahes andmebaasis olevaid andmeid võib muuta läbi selle rakenduse, mis konkreetse andmebaasiga töötab. Samas kui neid samu andmeid muudetakse teises andmebaasis läbi teise rakenduse ... siis need samad andmed, mis peaksid kirjeldama samu asju annavad meile erinevatest andmebaasidest pärides erinevad tulemused. See tähendab aga seda, et ühel päeval oleme me selles seisus, kus igas andmebaasis on mingi kirjeldatava objekti kohta erinevad andmed. Loomulikult ei ole nad täiesti erinevad. Loomulikult ei „muutu“ nad selliseks, et pole enam võimalik kindlaks teha, et nad pole enam ühte ja sama objekti kirjeldavad - erinevused ilmnevad tavaliselt üksikutes nüanssides. Kuigi kasutajad on üsna leidlikud ja oma „oskuste“piires ka „teovõimelised“ juhtub sellist asja harva aga mõni kord siiski. Üheks selliseks võimalueks andmete „tundmatuseni muutmiseks“ on see, kui kasutaja mingil põhjusel „otsustab“, et neid andmeid tal enam vaja pole ja muudab ühe objekti andmeid nii palju, et need muutuvadki teise objekti andmeteks. Ja olemegi „lõhkise küna“ ees – üks objekt (sest ID jäi ju samaks) ja kahed andmed.

Andmebaaside vaheline ebakõla

Probleem ise on sõnastatav väga lihtsalt: „kui sama objekti kohta on palju erinevaid andmeid, siis millised andmed on õiged?“. Sama lihtsalt on sõnastatv ka lahendus „samu andmeid tohib samal ajahetkel muuta ainult ühes kohas korraga. Kõikidesse teistesse kohtadesse tuleb need andmed pärast nende muutust sünkroniseerida.“. „Koha“ alla mõeldakse siin ühte konkreetset andmebaasiandmebaasi. See, mitu rakendust ja töökohta neid andmeid seal andmebaasis muuta saavad on juba teisejärguline küsimus. Oluline on, et „samal aja hetkel“ toimuks muutus ühes kohas ja teised kohad „saaks sellest muutusest teada“ läbi sünkroniseerimise protsessi. See „aja hetk“ ei pruugi aga väga lühike olla. Sõltuvalt sünkronisatsiooniprotsessi olemusest (kas jooksvalt (on-line) või perioodiliselt (off-line)) võib see ulatuda isegi kuni ööpäevani (kui andmete sünkroniseerimine toimub näiteks igal öösel) või isegi kaugemale.

„Aja hetk“ - ajavahemik kahe andmete sünkroniseerimise vahel

On-line sünkroniseerimise korral, mis on küll protsessi seisukohalt kõige parem aga samas ka kõige kallim ja haavatavam lahendus, võib andmete muutmise protsessi organiseerida järgnevalt. Kui mingis baasis asutakse andmeid muutma, siis saadab see andmebaas, kus andmeid muudetakse teistele baasidele, kus neid samu andmeid veel võib olla, teate millega ütleb „mina asun muutma andmeid, teie blokeerige kõik muudatused“. Pärast õnnestunud muudatus saadab ta teistele baasidele muutunud andmed. Viimased uuendavad endas muutunud andmed ja vabastavad lukustuse. Andmete muutmise ebaõnnestumise korral saadetakse teistele baasidele lihtsalt teade, et muudatusi pole vaja enam blokeerida.

Muudatuste jooksev (on-line) sünkroniseerimine

Andmebaaside joooksva sünkroniseerimise protsessi on mugav kasutada – see võimaldab andmebaasides jagada vabalt tegevusi ilma nende toimumise kohta piiramata. Samas aga on see protsess probleemide korral haavatav isegi sinna maani, et äriprotsessid saavad sellisel määral takistatud, et äritegevus lakkab. Vaatame sellist äriprotsessi, kus laosüsteemis vormistatakse saatelehti ja raamatupidamissüsteemis nende samade saatelehtede alusel arveid. Kui tegemist on andmete jooksva sünkroniseerimisega, siis võime me äriprotsessi kirjeldusest tingituna lubada saatelehtede muudatusi teha nii laosüsteemis mkui ka raamatupidamissüsteemis. Piisab kui me ühes nendest süsteemidest edastame teisele poolele teate selle kohta, et „meie praegu muudame – ära sina muuda“. Kui nüüd aga sünkroniseerimisprotsess ei toimi ja tagastab selle teate saatmisel vea, siis ei saa me alustada ka muutmist ennast, sest teine pool ei tea, et meise seda praegu teeme ja võib alustada samal ajal samade andmete muutmist. Samuti käitub teine pool – kuna ka tema ei saa meiega ühendust, siis ei saa ka tema tegevust alustada ja protsessid ongi mõlemal pool takistatud. Kuna ühendus puudub, siis on takistatud kõik sellised tegevused, mis eeldavad üle mitmete baaside andmete lukustamisi, Võib küll kehtestada, nn. peremees-andmebaasi, kus muudatused on lubatud ka siis, kui on-line lukustust ei õnnestu teha. Sellisel juhul peab aga sünkronisatsiooniprotsess olema oluliselt keerulisem ja suutma ühenduse tekkimisel kõik vajalikud andmed teistesse baasidesse ära saata.

Jooksva sünkroniseerimise haavatavus

Muudatuste perioodiline sünkroniseerimine ei jäta meile nii palju vabadust äriprotsesside planeerimisel, lisades juba endasse sisse programmeritud viitega jäikust äri protsessidesse. Lisaks viitele ei jää meil ka midagi muud üle, kui peame kõikide andmebaaside vahel sünkroniseeritavate andmete jaoks määrama nende „kodu-andmebaasi“ st. selle andmebaasi, kus neid andmeid muuta tohib ja kust nad siis järgmise sünkronisatsiooni aja saabumisel sünkroniseeritkase teistesse andmebaasidesse. Siin ei pea muidugi mõtlema sellele, et andmeid sünkroniseeritakse korra päevas või nädalas jne. Andmete perioodilise sünkroniseerimise sageduseks võib olla väga vabalt ka tund või isegi viis minutit. Siin ongi aga kogu äriprotsess üles ehitatud eeldusel, et andmed muutuvad ühes kohas ja sünkroniseeruvad alles teatud aja tagant. Kui sellises protsessis mõni andmete sünkronisatsioon jääb vahele ei juhtu veel midagi hirmsat. Mõnedele tegevustele järgnevate tegevuste tegemine venib küll ajas, kuid teisi tegevusi saab edasi teha.

Muudatuste perioodiline (off-line) sünkroniseerimine

Mida siit siis järeldada võib? Mida rohkem on selliseid andmebaase, kus töö käigus vahetatakse andmeid, seda suurem on oht, et infosüsteemi töö takistuseks saab just see andmevahetus. Samuti tekib oht, kui andmete vahetusprotsess on vigaselt üles ehitatud, et kõigis andmebaasides ei uuene andmed viimase muudatuse järgi vaid kusagil jääb midagi uuendamata. See on tegelikult veel suurem probleem, kui see et tööd ei saa teha. Pole hullemat asja andmebaasides, kui andmed mida ei saa usaldada. Ja mida rohkem on selliseid andmebaase, millede vahel peab andmeid sünkroniseerima, seda keerulisemaks läheb kogu see töö. Kui seda tööd mitte korralikult juhtida siis lõppeb (ja tõe poolest lõppeb) asi täieliku kaosega.

Probleem!

Lahenduseks on sellistel juhtudel ühtse andmebaaside vahelise andmevahetuskeskkonna üles ehitamine, mis kannab hoolt selle eest, et ühest andmebaasist välja saadetud andmed jõuaksid kõigisse nendesse teistesse baasidesse, kuhu nad jõudma peavad. Lisaks sellele, et andmeid õigetesse kohtadesse saadetakse jäetakse ka maha tõestatud protokoll selle kohta kust kuhu ja millal andmed liikusid. Ühtlasi puhverdatakse vajadusel ka „katkiseid linke“ st. kui mingi andmete edastussihtpunkt on „õigel hetkel“ kättesaamatau, siis võimalusel (kui äriprotsess seda võimaldab)saadetakse talle andmed hiljem – siis kui temaga on jälle võimalik ühendust saada.

Lahendus?

3.2. Andmebaaside hajus geograafiline paigutus

Andmebaaside hajus geograafiline paigutus iseensest ei ole suuremaks probleemiks siis, kui nad oma vahel andmeid ei vaheta. Siis on tegemist iga andmebaasi korral täiesti tavalise andmebaasiga, milles pole erilist. Kui aga andmebaaside geograafilist hajusust kombineerida eelmises jaotises kirjeldatud andmebaaside vahelise andmevahetuse problemaatikaga, siis saame seal kirjeldatust oluliselt suurema probleemi.

Andmebaasi asukoht ja andmevahetus

Loomulikult ei mõelda siin „hajusa geograafilise paigutuse“ all seda, et meie andmebaasi serverid on ühe hoone erinevatel korrustel. Tegelikkuses ei ole Eesti tingimustes mõtet isegi rääkida sama linna piires hajutatusele, kuna siinne andmeside on päris hästi arenenud ja probleeme väga palju pole. Probleemi tekkimisel võib omale lihtsalt üürida garanteeritud läbilaske võimega eraldatud kanali. Seda muidugi siis,kui see asi ennast äriliselt ära tasub. Eesti piires kehtib see sama loogika isegi terve riigi piires – kui teistes riikides on pankadel suuri probleeme üleriigiliste on-line teenindusvõrkude organiseerimisega, siis Eesti vastavad probleemid jäävad juba rohkem kui kümne aasta taha. Seega hajususe kriteeriumiks ongi see, kus serverite vahelises andmeedastuses tuleb hakata, tingituna kanalite omadustest, kasutama teisi vahendeid ja meetodeid, kui seda tehakse geograafiliselt kompaktses keskkonnas. Näiteks Eesti tingimustes, kasutades eraldatud, garanteeritud läbilaske võimega kaugühendusi võib juhtuda, et geograafiline hajusus ei avaldagi mingit mõju. Samas , kui Kreekas, kus sama linna erinevates linnaosades pole päeva erinevatel aegadel elektrit (see lihtsalt lülitatakse korda mööda koormuse vähendamiseks välja) võib geograafiline hajusus olla juba suur kõrvuti asetsevate majade vahel, kui nad kuuluvad erinevatesse linnaosadesse. Igatahes on üks kindel, kui koos toimivad serverid väljuvad ühe hoone piirest või ühe omaniku piirest, siis tuleb teha analüüs ja vaadata, kas ei ole vaja maandada kusagil mingeid riske, mis on tingitud just andmebaaside hajusast paigutusest.

Kui hajus on hajus?

Serverite geograafiline hajusus võib olla probleemiks aga võib seda ka mitte olla. See võib olla ka suureks plussiks. Näiteks võtame Google koos oma arvatava 100 -200 tuhande serveriga. Kõiki neid serverid ei sünkroniseerita oma vahel. Nad teevad oma tööd gruppide kaupa – igal grupil mingi konkreetne ülesanne. Serverite poole pöördumisel on piisav, kui mingi grupi liige vastab ja organiseerib vastuse sellest grupist. Kui mõni grupp pole kättesaadav, siis tehakse tööd ilma selleta, kuna informatsioon, mida töödeldakse pole 100% määratletava kooslusega. Seega kui 80% võrgust töötab on kõik juba hästi. See et need serverid on üle maailma hajutatud annab sellisele süsteemile lisatöökindlust – kusagil ikka on elektrit, ei toimu sõda ja inimesed ei streigi. Seda muidugi juhul, kui arhitektuur on sobiv selle ülesande lahendamiseks.

Geograafiline hajusus ei pruugi probleemiks aga ei pruugi

Samas kui me räägime finantssüsteemidest (näiteks pangad), siis peab toimingu tegemiseks olema 100% kindlusega kätte saadav kogu toimingu info – ei saa öelda, et me ARVAME, et teie kontol on nii palju raha või pole seal üldse raha. Asju peab teadma täpselt. Näiteks saab inimene pangalt tellida teenuse kus läbi SWIFT kanali tehakse tehinguid teises pangas tema eest. Kui nüüd tegevuse käigus, näiteks ei saa pärida enne panga toimingu tegemist tema konto jääki (kui see peaks vajalikuks osutuma), siis on takistatud ka kõik sellele järgnevad tegevused.

Geograafiline hajusus võib takistada tegevsi

Suurim probleem geograafiliselt hajutatud andmebaaside koos kasutamisel on see, et tavaliselt jääb erinevate andmebaaside vahele piirkond, mis ei ole ühegi andmebaasi omaniku (kui neid on mitu) kontrolli alla vaid seal toimetavad andmete edastajatena mingid kolmandad firmad. Nende tehniline tase, töövõime ja ühtesobivus piirkonniti ja riigiti olla väga erinev. Kontrollimatu on see igatahes. Igatahes erinevatel põhjustel võib olla mistahes ajahetkel andmete edastamine ühest andmebaasist teise takistatud. Selle põhuseid on peamiselt kaks: kas ei jõua andmed kohale seetõttu, et tõrge tekkis kanalis, või ei ole vastu võttev süsteem suuteline mingil ajahetkel andmeid vastu võtma.

Suurim probleem!

Lahendus on tegelikult asünkroonses andmevahetuses. See tähendab seda, et andmevahetus peab olema üles ehitatud selliselt, et protsess, mis saadab andmed ei jää kunagi ootama vastust vaid läheb oma protsessiga edasi.- andmete või vastuse saabumist ootab spetsiaalne protsess, mis andmete või vastuse saabumisel teavitab õiget protsessi ja annab sellele andmed töötlemiseks üle. See protsess, mis aga andmeid saadab kontrollib andmete vastu võtmist saaja käest ja kui seda ei kinnitata, siis üritab mõne aja pärast andmeid uuesti saata – seda nii kaua, kui andmete saatmine õnnestub. Loomulikult tuleb andmete saatmise ebaedukusest või edukusest teavitada seda protsessi, mis andmed saatmiseks ette valmistas või siis seda protsessi, mis ootab eeldatavat vastust. Lahenduseks on siin MQ (Message Queueing) süsteemide kasutamine. (Sonic MQ/XQ, IBM MQ Series, MS Exchange server jms.), mis suudavad puhverdada teadete saatmist nii, et kui mingil põhjusel ei jõua teade tõestatult adressaadini, siis korratakse seda ajavahemike tagant nii kaua kui see õnnestub.

Lahendus – Message Queueing

3.3. Suur kasutajate arv

Suur kasutajate arv võib oluliselt mõjutada seda, kui suurena me andmebaasi tunnetame. Tunda annab see peamiselt kahes asjas. Esiteks nõuab iga kasutaja, kes andmebaasi poole pöördub teatavat serveri jõudllust ja ka mälu mahtu. See võib muutuda probleemiks, kui need paljud kasutajad tahavad andmebaasi poole pöörduda samaaegselt – kaustaja puhvrite loomiseks kasutatav mälu võib lihtsalt otsa saada. Selle probleemi lahendused on muidugi suhteliselt lihtsad. Loomulikult tuleb alustada sellest, et serveri operatiivmälu maht tuleb viia lubatud maksimumini. Paraku ei pruugi alati aidata ka sellest. Sellisel juhul tuleb kasutada andmebaaside poole pöördumiseks vahe-serverid (näiteks aplikatsioonservereid), mis serveri poolt vaadatuna on nähtavad ühe füüsilise kasutajana, kuid tegelikult puhverdavad/vahendavad andmebaasiserverile mitemete erinevate kasutajate pöördumisi. Selliseid vahendus-servereid on võimalik paigaldada piisavalt palju selleks, et leevendada serveri mälu vajadust.

Palju üheaegseid kasutajaid

Loomulikult saab eriti ressursinõudlike andmebaasirakenduste juures kasutada andmebaasiserverite kobar-lahendusi, kus mitu andmebaasiserverit töötab sama andmebaasi vastu ja need serverid jagavad oma vahel koormust. Ainsaks teada olevaks andmebaasi kobar-serveri (cluster) rakenduseks on Oracle RAC (Real Application Clusters). Kuigi kobar-serveritest räägitakse rohkem andmebaaside käideldavuse seisukohalt on nad olulised ka andmebaasi ressursi laiendamisel selleks, et töödelda suurema hulga kasutajate poolt saadetud korraldusi.

Kobar-server

Kui kasutajaid on palju, kuid nende õigused on suurte gruppidena sama sugused, siis taandub kasutajate arvuga seotud probleemistik eelkirjeldatule – uue kasutaja tekkimisel lisatakse ta mingisse õiguste gruppi ja kui tema töised ülesanded muutuvad selliseks, mis nõuavad muid õigusi, kui tal seni need olnud on, siis neid muudetakse. Kuna õigused on suhteliselt homogeensed, siis kasutajate gruppide vahelised liikumised toimuvad harva ja suurema tõenäosusega seisneb kasutaja järgmine õiguste muudatus selles, et ta lahkub ja talt võetakse kõik õigused. Kui aga siia lisandub kasutajaõiguste keerukas struktuur, siis saame juurde veel ühe keerukuse astme – keegi peab hoidma kasutaja õigused infosüsteemis-andmebaasis vastavuses nende kasutajate tegelike töiste õigustega. Kui nüüd toimub veel ka suur kasutajate liikumine ühest grupist teise, siis olemegi kätte saanud uue probleemi – kasutajaõiguste korras hoidmiseks kuluvate tööde maht võib ületada mõistlikkuse piiri. Lisaks sellele jääb alati oht, et kellelgi on mõned õigused mida tal enam olema ei peaks, ikkagi ära võtmata jäänud. Teistpidine puudus, et kellelegi on mingid õigused andmata jäänud, ei ole tõenäone, kuna see tuleb kohe välja – inimene lihtsalt ei saa vajalike õigusteta tööd teha. Samas kui õiguste ära võtmata jätmine võib märkamatuks jääda isegi aastateks. See on aga seda suurem turvarisk, mida suurem on infosüsteem ja „õrnemad“ seal hoitavad andmed.

Keerukad kasutajaõigused

Siin „puhast“ andmebaasipõhist võin tehnilist lahendust sellele probleemile polegi. Küll aga on olemas lahendus, mis seob omavahel andmebaasi kasutajaõigused ja inimese rolli töises tegevuses. Üks asi, mis kindlasti töötaja kirjelduses muutub, kui tema asukoht organisatsioonis muutub on tema ametikoht. Kui nüüd kasutajate üldised õigused kirjeldada ära ametikoha põhisena, siis töötaja ametikoha vahetumisel muutub ka tema põhiõiguste pakett. See töötaja kes lahkub töölt lahkub ka oma ametikohalt ja jääb see tõttu ilma kõikidest õigustest. Tegelikult peaksidki ametikohaga seotud õigused olema kirjeldatud nii, et „99%“ juhtudest nendest töötajale piisaksi – ega's töötaja pea ju tegema muid tegevusi, kui seda on tema ametikohaga määratud tegevused. See „1%“ juhtudest, kus on vaja eriõigus tuleb nö. „eriõigustena“ ka realiseerida. St. seda, et eriõigusi saab taotleda ainult mingiks tähtajaks ja tähtaja saabumisel „kaovad“ need automaatselt. Selline lähenemine vahetab töötaja ameti muutumisel välja ka tema kasutajaõigused ning eriõigused ei kesta igavesti. Seega on soovitud tulemus saavutatud ja olukord kontrolli all.

Lahendus

3.4. Andmebaasi poole tehtud pöördumiste suur arv

Nii nagu andmebaasi suur füüsilina maht teeb aegalsemaks päringute töötlemise teeb seda sama ka suur pöördumiste arv andmebaasi poole. Olenemata algsete põhjuste erinevusest on tulemus ikka see sama. Kui esimesel juhul tuleb tulemuse saavutamiseks töödelda palju andmeid selle pärast, et andmebaasis lihtsalt on palju andmeid, siis teisel juhul tõstab töödeldavate andmete mahu suureks oluliselt väiksema andmebaasi peal see, et andmebaasi lihtsalt tehakse palju päringuid. Vaatamata sellele, et andmeid on vähem „korvatakse see puudus“ suure nõudlusega nendele vähestele andmetele.

Väiksem baas, palju pärimguid = suurem baas vähem päringuid -> ketta ja protsessori ressursi ammendumine

Erinevalt andmemahult suurte suurtest andmebaasidest pole siin eriliseks probleemiks varunduskoopiate tegemisele ja andmete taastamisele kuluv aeg – andmeid pole lihtsalt nii palju, et see probleemseks muutuks. Samas andmete pooole pöördumise kiiruse probleemid on samad. Kõik see nõuab kiireid kettaseadmeid ja oluliselt parema päringumetoodikaga programme. Samuti on abiks andmete jaotamine erinevate seadmete vahel tagamaks andmete võimalikult kiiret riistvaralist käsitlust (vt. p. 7.1)

Suurema jõudlusega riistvara vajadus

3.5. Info konfidentsiaalsuse kõrge tase

Olulisi nõudeid esitab andmebaasile seal paiknevate andmete konfidentsiaalsuse kõrge tase. Asi pole eriline probleem kui rääkida „tavalistest“ andmetele juurdepääsu reguleerimise vahendistest, mis algavad kasutajaõiguste kirjeldamisega andmebaasides ja tulemüüride rakendamisega. Oluliseks kuluks võib siin osutuda kõrge turvalisusega serveriruumide ehitamine, mis pekas vastu füüsilistele rünnakutele ja välistaks juurdepääsu serveritele looduskatastroofide ajal. Viimasel juhul lisanduvad olulised serveri ruumi geograafilise paiknemise riskid, mis on oluliselt kõrgemad seismiliselt aktiivsetes piirkondades.

Kulud kõrge turvalisuse tasemega serveri ruumide ehitamisel

Riistvarale esitatud nõuded kasvavad siis, kui lisaks eel pool kirjeldatud meetoditele on vajalik andmebaasides andmete krüpteerimine. Kuna andmete baasi salvestamisel on vakjalik andmete krüpteerimine ja sealt pärimisel nende dekrüpteerimine, siis lisab see kõik serveri protsessori jõudluse suurvajadust. Andmete enda salvestamine ja lugemine kettamassiivil ei anna mingit lisakoormust, sest andmete maht krüpteerimise käigus ei muutu.

Andmete krüpteerimine

Protsessori jõudluse suurendamise vajadust aitab vähendada andmete osaline krüpteerimine. On peaaegu kindel (ei saa siiski välistada erijuhte), et kõik baasis talletatavad andmed ie ole sellise konfidentsiaalsuse tasemega, et neid kõiki peaks krüpteerima. Tavaliselt piisab andmete konfidentsiaalsuse tagamiseks vaid nende kõige olulisema osa krüpteerimisest.

Andmete osaline krüpteerimine

3.6. Suur muudatuste sagedus

Muudatuse all ei mõelda siin andmete sagedat muutumist vaid andmebaasi struktuuri muutumist. Andmebaasi struktuuri sage muutumine toob kaasa üsna suuri riske. Siin on lisaks andmete hoolikale varundamisele väga oluline ka programmide ja protseduuride varundamine. Kui andmete struktuur muutub muutub sellega koos ALATI ka programmide sisu. Kui mitte palju, siis kas või vähekenegi. Seega suure tõenäosusega tuleb andmebaasi riknemisel taastada ka programmid, sest andmete taastamise tulemusena võib taastuda mingi eelnevalt kehtinud strukuur, mis vajab käsitluseks sellele struktuurile vastavaid programme. Seega tuleb iga andmete varunduskoopia puhul teada, millise programmi versiooniga need andmed on käsitletavad. St. Kui taastada andmed mingist varunduskoopiast, peab olema täiesti kindlalt teada, millisest varunduskoopiast tuleb taastada programmid.

Andmete ja programmide varundamise sünkroniseerimine

See ei tähenda nüüd muidugi seda, et ülejäänud juhtudel ei peaks teadma, millisele andmete varunduskoopiale vastab milline programmide varunduskoopia, kuid juhtudel, kui andmete struktuur väga tihti ei muutu on seda vastavust tunduvalt lihtsam tuvastada.

On veel üks aspekt, mida sellistel juhtudel tuleb eriti hoolikalt jälgida. Kui meie andmete maht on suur, ja me teeme varunduskoopiad kombineeritud meetodil, siis võib juhtuda, et meil on vaja teha varundukoopiad nii enne kui pärast muudatuste teodstamist. Esimene koomia selleks puhuks kui on vaja taastada olukord enne andmebaasi struktuuri muutust ja teine selleks puhuks, kui meil on vaja taastada olukord pärast andmebaasi muudatusi koos sellele järgnevate andmete muudatuste taastamisega logidest. Mitte, et seda poleks mõteka teha ka mistahes muu andmebaasis truktuuri muudatuse korral aga kui mujal on sellise käitumsie valimisel otsustamise ruumi (kas sedasi teha või mitte), siis sagedasti muutuva struktuuriga andmebaaside korral on muutsi liiga palju ja selel hetkel tehtava vea tagasi võtmise vajadus oluliselt suurema tõenosusega.

Varunduskoopia enne ja pärast muudatus

3.7. Kasutajate „poliitiline“ hajutatus

Kasutajate õiguste määramisele loob lisa keerukust ettevõtte organisatsioonilise struktuuri keerukus. Seda juhul, kui sama infosüsteemi kasutajad asuvad erinevates riikides – erinevates riikides, sõltuvalt konkreetses riigis kehtivast seadusandlusest, võivad kehtida erinevad sätted kasutajate õiguste piiramiseks/lubamiseks. Nagu ikka, seal kus algab poliitika lõppevad mõistlikud soovitused – siin tuleb probleemi lahendamisel lähtuda konkreetsest juhtumist ja leida just konkreetsele probleemile. Ühe ainsa soovituse võib siiski anda. Kui infosüsteemil on vaja andmebaasi jaoks kirjeldada õigusi üle mitme riigi kasutajate, siis tuleb õiguste süsteemile lisada „riigi dimensioon“, mis toimib paralleelselt ettevõtte organisatsioonile kirjeldatud õigustega. Seejuures on riigipõhised määratlused ülimuslikud – kui ettevõtteorganisatsiooni põhine õiguste määratlus läheb vastuollu riigipõhiste määratlustega, siis õiguste sisu määravad riigi pühised määratlused.

Algab poliitika – lõppevad mõistlikud soovitused

3.8. Kombinatsioon „mitmest suurusest“

Tavaliselt kaasneb andmebaasides ühe „dimensiooni“ paisumine ka mõne teise „dimensiooni“ kasvu „kaasa tõmbamises. Nii näiteks kipub paljude kasutajatega andmebaasides olema palju andmeid ja selliste andmebaasi poole tehakse ka palju pöördumisi. Samuti kipub olem ka nii, et kui baasis on palju kasutajaid, siis on ka kasutajaõiguste struktuur keerulisem.

Tavaliselt ülepaisutatud „dimensioonid“ kombineeruvad

Olenemata andmebaasi või infosüsteemi (esialgsest) väiksusest peab kogu tema modelleerimine ja loomine olema läbi viidud sama põhjalikkusega kui mistahes suure infosüsteemi korral - esialgselt väikestel süsteemidel on kalduvus kasvada suurteks. Kui seda märgatakse liiga hilja võib see viia vajaduseni infosüsteem välja vahetada, sest tema edasine areng, püstitatud eesmärgi raames, võib muutuda võimatuks.

Peaaegu kõik süsteemid saavad kord suureks