Tämä postaus jatkaa blogisarjaani tietomallintamisesta (Tietomallinnus – Osa 1: Intro). Alla linkit muihin tietomallinnuksen blogisarjan blogeihin.

OLTP-tietomallin hyödyt

OLTP-tietomallinnuksesta on monia hyötyjä, jotka voivat parantaa liiketoiminnan tehokkuutta ja päätöksentekoa. Tässä ovat keskeisimmät hyödyt:

Parannettu suorituskyky ja tehokkuus: Hyvin suunniteltu OLTP-tietomalli minimoi tietokannan viiveet ja maksimoi suorituskyvyn tarjoamalla nopeat luku- ja kirjoitusoperaatiot. Tämä on erityisen tärkeää transaktiointensiivisille sovelluksille, joissa nopea datan käsittely on kriittistä.

Tietojen eheys ja luotettavuus: Normalisointiprosessin kautta tietokannan tietojen toisteisuus vähenee ja tietojen eheys paranee. Kun tieto tallennetaan vain kerran, päivitysten, lisäysten ja poistojen yhteydessä virheiden riski pienenee, mikä lisää tietokannan luotettavuutta.

Vähemmän lukitustilanteita ja rinnakkaisuuden hallintaa: OLTP-tietomallit on suunniteltu minimoimaan lukitustilanteet ja parantamaan rinnakkaisuuden hallintaa, mikä on tärkeää suurissa ja monimutkaisissa järjestelmissä, joissa useat käyttäjät suorittavat transaktioita samanaikaisesti.

Skaalautuvuus: Tehokkaan tietomallinnuksen ansiosta OLTP-järjestelmiä on helpompi skaalata vastaamaan liiketoiminnan kasvua. Kun tietokannan rakenne on suunniteltu huolellisesti, järjestelmä voi käsitellä suurempia tietomääriä ja lisääntyviä käyttäjämääriä ilman suorituskyvyn merkittävää heikkenemistä.

Parempi päätöksenteko: Vaikka OLTP-tietokannat eivät suoraan sovellu raportointiin ja analytiikkaan, niiden keräämä ajan tasalla oleva ja luotettava data on arvokasta tietoa päätöksenteolle. Tehokkaan datan keräämisen ja hallinnan ansiosta organisaatiot voivat tehdä tietoon perustuvia päätöksiä nopeammin.

Kustannussäästöt: Tehokas tietomallinnus voi vähentää tarvetta jatkuvasti investoida lisäresursseihin, kuten lisämuistiin tai tehokkaampiin prosessoreihin, suorituskyvyn ylläpitämiseksi. Tämä voi johtaa merkittäviin säästöihin pitkällä aikavälillä. Edelleen, mitä tehokkaampi OLTP-tietokanta-alusta on, sitä suuremmat ovat myös sen generoimat lisenssisäästöt on-premises-ympäristössä ja kapasiteettipohjaisen laskutuksen säästöt julkipilvessä.

Ylläpidon ja kehityksen helpottuminen: Selkeä ja hyvin suunniteltu tietomalli helpottaa ylläpitoa ja uusien toiminnallisuuksien kehittämistä. Kun tietomalli on järjestelmällinen ja looginen, kehittäjien on helpompi ymmärtää ja tehdä muutoksia järjestelmään.

Näin ollen, OLTP-tietomallinnuksen hyödyt ulottuvat operatiivisen tehokkuuden parantamisesta aina strategisen päätöksenteon tukemiseen, mikä tekee siitä kriittisen osan nykyaikaista liiketoimintaa.

Miksi OLTP-tietomallinnus?

Operatiiviset eli ns. OLTP-tietokannat ovat transaktiointensiivisiä. Tämä tarkoittaa, että dataa kirjoitetaan ja päivitetään tietokantaan tiuhaan tahtiin lukuoperaatioiden lisäksi, usein 60/40 – 90/10 RW-suhteessa. Tällaisia ovat mm. ERP-tietokannat. OLTP-työkuormille tyypillisiä piirteitä ovat pienet tulosjoukot sekä yksinkertaiset kyselyt. Edelleen; OLTP-työkuormat ovat luonteeltaan satunnaisista luku- ja kirjoitusoperaatioista koostuvia, joissa on pienempi tallennusblokkikoko kuin tietovarastojärjestelmissä. OLTP-työkuormille on tyypillistä myös latenssiherkkyys. 

Kaikki tämä asettaa erityisiä vaatimuksia tietomallille, jotta tietokannanhallintajärjestelmän suorituskyky ja skaalautuvuus ei muodostu pullonkaulaksi, kun sen työkuormat ja käyttäjämäärät lisääntyvät. Tämän takia hyvä OLTP-tietomalli onkin varsin polarisoitunut verrattuna hyvään tähtimalliin (tietovarasointi). Hyvä OLTP-tietomalli onkin summeerattuna sellainen, jossa oliot ja niiden ominaisuudet esitetään kerran ja vain kerran, relaatioineen. Täten saadaan tietokannan transaktionaalinen suorituskyky maksimoitua ja mahdolliset lukitustilanteet minimoitua. 

Mihin OLTP-tietokanta ei sovellu 

Koska operatiivisen tietokannan tietomalli on optimoitu transaktionaaliseen dataan, on siitä usein hidasta ja monimutkaista kysellä suuria tietomääriä. Juuri tästä syystä OLTP-kannat eivät sovellu hyvin raportointiin, koska raportoinnissa on tyypillistä yhdistellä, summata ja jalostaa suuria datamääriä keskenään. Kaikki tämä johtaa OLTP-kannassa helposti korkeaan prosessorin käyttöasteeseen, muistiongelmiin sekä hallitsemattomiin levykuormiin ja lukitustilanteisiin.  

Tyypillinen raportoinnin evoluutio tällaisissa tietokannoissa on ns. ”laastariratkaisu”, eli ensin tehdään erillisiä raportointitauluja tai muistinvaraisia tauluja OLTP-kantaan. Sitten kun tämä ei enää riitä, aletaan replikoida reaaliaikaisesti dataa kantakopioon, joka on tarkoitettu vain kyselykäyttöön. Kaikki tämä johtaa kuitenkiin hitaaseen, kompleksiseen, virhealttiiseen ja siiloutuneeseen raportointiin. Viimeistään tässä vaiheessa onkin järkevää mallintaa erillinen datamart tai konsernitietovarasto (EDW), joka on tietomalliltaan optimoitu suurien tietomäärien pitkäkestoiseen varastointiin ja suoraviivaiseen raportointiin. Tietovarastomallinnuksen menetelmistä ja parhaista käytännöistä kerron lisää tulevissa blogipostauksissani. 

Tietokannan normalisointi 

Tietokannan normalisointi on systemaattinen metodi, joka tähtää maksimaaliseen tiedon saatavuuteen ja tallennuksen eheyteen. Metodia seuraamalla voidaan kehittää tehokkaita operatiivisia tietokantoja. Normalisoinnin ideana on asteittain pienentää tiedon toisteisuutta eli redundanssia sekä parantaa tietomallin eheyttä. Nyrkkisääntönä voidaan pitää, että: 

  • Kukin tieto on esitetty vain yhdessä paikassa 
  • Relaatiossa voi esiintyä vain siihen kuuluvaa dataa 
  • Päivitys kohdistuu vain yhteen paikkaan kerrallaan 

Normalisointi tarkoittaa käytännössä tietokantataulujen (=oliot ja niiden ominaisuudet sekä relaatiot) järjestämistä tietyllä tavalla. Tauluja voidaan tarpeen mukaan luoda uusia ja niiden välillä voidaan siirtää attribuutteja. Alkuperäisenä normaalimuotojen kehittäjänä tunnetaan herra nimeltään Edgar F. Codd. 

Ensimmäinen normaalimuoto (1NF) 

Ensimmäinen normaalimuoto esittää, että tietokannan jokaisen sarakkeen arvot ovat atomisia. Normalisointi toteutuu pilkkomalla moniarvoiset attribuutit omiin tauluihinsa. Otetaan hauska esimerkki. Meillä on viulisteja, jotka omistavat on kukin yhdestä moneen stradivariusta: 

Tämä tulisi jakaa kahteen erilliseen tauluun:  

  • Muusikoiden tiedot 
  • Stradivariukset 

Toinen normaalimuoto (2NF) 

Määritelmän mukaisesti; toinen normaalimuoto kieltää muiden kuin avainattribuuttien ei-triviaalit toiminnalliset riippuvuudet avainehdokkaan osaan.  

  • Jos jokaisen taulun avain koostuu vain yhdestä attribuutista, tietokanta on toisen normaalimuodon mukainen. 
  • Jos kantaan kuuluu tauluja, joiden avainkandidaatti koostuu useasta eri attribuutista (=komposiittiavain), ei mikään attribuutti, joka ei ole avain, saa olla osittain toiminnnallisesti riippuva mistään avainehdokkaasta. 
  • Jos attribuutti on riippuvainen koko avaimesta, eikä pelkästään osa-avaimesta, se saa sijaita taulussa toisen normaalimuodon mukaan. 

Esimerkki. Stradivarius -taulussa on komposiittiavain eli ehdokasavain (Stradivarius, valmistusmaa). Taulu ei siis ole 2NF-muodossa: 

Kaikki kentät, jotka eivät ole riippuvaisia komposiittiavaimesta (pituus, paino), riippuvat Stradivarius-kentästä, mutta ainoastaan hinta riippuu myös valmistusmaasta. Tämä taulu voidaan muuttaa toiseen normaalimuotoon tekemällä Stradivariuksesta ehdokasavain, jotta jokainen ei-ehdokasavainmäärite riippuu koko ehdokasavaimesta, sekä poistamalla hinta erilliseen taulukkoon, jotta sen riippuvuus Valmistusmaasta voidaan säilyttää: 

Kolmas normaalimuoto (3NF) 

Kolmas normaalimuoto kieltää nbiiltä attribuuteilta, jotka eivät ole avaimia, “ei-triviaalit funktionaaliset riippuvuudet” muihin kuin avainehdokkaiden ylijoukkoon (=superset). Esimerkkitapauksessamme; Stradivarius-taululla on edelleen ei-triviaali funktionaalinen riippuvuus (väri on riippuvainen Stradivariuksesta). Siksi skeema ei ole 3NF:ssä, joten ei-triviaalit funktionaaliset riippuvuudet poistetaan sijoittamalla väri omaan tauluunsa sekä valmistusmaa omaan tauluunsa, johon viitataan hinnastotaulusta, ja lopuksi vielä lisätään puuttunut relaatio Viulistin ja Stradivariuksen väliltä: 

Yhteenveto

Normaalimuotoja on kaikkiaan 6NF saakka. Kuitenkin OLTP-mallintamisessa harvoin tarvitaan edes neljättä normaalimuotoa.  

Tarvitseeko organisaatiosi apua OLTP-tietokannan mallintamisessa? Ota yhteyttä allekirjoittaneeseen niin jutellaan lisää! 

Jani K. Savolainen 
jani.savolainen@dbproservices.fi 
0440353637 
VP & Chairman
DB Pro Services Oy

Tämä postaus aloittaa blogisarjan tietomallinnuksesta. Alla linkit muihin tietomallinnuksen blogisarjan blogeihin.

Tietomallinnuksen hyödyt

Tietomallinnus on keskeinen vaihe tietokantojen suunnitteluprosessissa, ja sillä on useita hyötyjä. Tietomallinnuksen avulla voidaan varmistaa, että tietokanta on tehokas, joustava ja laajennettavissa tulevaisuuden tarpeisiin. Tässä on joitakin tärkeimpiä hyötyjä, joita tietomallinnuksesta on tietokantojen suunnittelussa:

1. Ymmärryksen parantaminen: Tietomallinnus auttaa suunnittelijoita ja sidosryhmiä ymmärtämään liiketoiminnan prosesseja ja tiedonkäsittelyn vaatimuksia syvällisemmin. Se tarjoaa visuaalisen esityksen tiedon rakenteesta, suhteista ja rajoitteista, mikä helpottaa yhteistä ymmärrystä ja kommunikointia.

2. Tehokkuuden lisääminen: Hyvin suunniteltu tietomalli mahdollistaa tietokannan tehokkaamman käytön, koska se minimoi tarpeettoman datan toistumisen ja optimoi tiedon tallennuksen ja haun.

3. Joustavuus ja laajennettavuus: Kun tietokanta on suunniteltu huolellisesti tietomallinnuksen avulla, sen rakenne on joustavampi ja helpommin mukautettavissa muuttuviin liiketoiminnan tarpeisiin ja teknologisiin vaatimuksiin.

4. Laadun parantaminen: Tietomallinnus auttaa tunnistamaan ja korjaamaan suunnitteluvirheitä varhaisessa vaiheessa, mikä vähentää virheitä ja parantaa tietokannan laatua ja suorituskykyä.

5. Tietoturvan ja yksityisyyden varmistaminen: Tietomallinnuksen avulla voidaan suunnitella tietokannan turvatoimet ja yksityisyydensuoja alusta alkaen, mikä varmistaa arkaluonteisen tiedon asianmukaisen käsittelyn ja suojauksen.

6. Kustannusten vähentäminen: Vaikka tietomallinnus vaatii alkuinvestointia, aikaa ja resursseja, se voi säästää merkittävästi kustannuksia pitkällä aikavälillä vähentämällä tarvetta tietokannan jälkikäteisille muutoksille ja korjauksille.

7. Standardisoinnin edistäminen: Tietomallinnus auttaa noudattamaan alan standardeja ja parhaita käytäntöjä, mikä helpottaa integraatiota muiden järjestelmien kanssa ja edistää tiedon yhteentoimivuutta.

Tietomallinnus on siis olennainen osa tietokantojen suunnittelua, joka auttaa rakentamaan tehokkaita, luotettavia ja tulevaisuuden tarpeisiin mukautuvia tietokantoja.

Miksi ja milloin tietomallinnus tehdään

Tietomallinnus, eli tietomallintaminen on tärkein yksittäinen vaihe reaaliaikaisen (OLTP) tietojärjestelmän tai tietovaraston (DW, Datamart) toteutuksessa. Tämän tehtävän suorittaa tyypillisesti asiaan vihkiytynyt tietomallintaja. Tietomallinnus kuvataan usein kaksivaiheisena prosessina: Sen ensisijaisena tarkoituksena on luoda ylätasolla yhteinen käsitekartta liiketoiminnan, tietokantaosaajien (data-arkkitehti, DBA), datainsinöörien (Data Engineer) sekä data-analyytikoiden (Data Analyst) välille. Tällöin puhutaan käsiteanalyysistä. Kun käsiteanalyysi on valmis, valitaan skenaarioon parhaiten sopiva tietomallinnusmetodi ja suunnitellaan ns. fyysinen tietomalli. Fyysisen tietomallin pohjalta voidaan sitten toteuttaa varsinainen tietokanta. Fyysisiä tietomalleja ovat mm.

  • OLTP- eli relaatiomalli (3NF)
  • Star Schema (tähtimalli)
  • Snowflake Schema (lumihiutalemalli)
  • Enterprise Data Warehouse BUS
  • Data Vault

Fyysisen tietomallin tehtävänä on palvella liiketoiminnan tarpeita mahdollisimman tehokkaasti. Hyvä fyysinen tietomalli ottaa liiketoimintatarpeiden lisäksi huomioon mm. seuraavat seikat:

  • Tietokantaratkaisun suorituskyky sekä skaalautuvuus käyttöskenaarion mukaan
  • Tietomallin ymmärrettävyys
  • Tietomallin ylläpidettävyys sekä:
  • Tietomallin helppokäyttöisyys tietokantakyselyiden laatimisessa

Usein tietomallinnuksessa tehdään sellainen virhe, että käsiteanalyysin sijaan lähdetään kuvaamaan suoraan tietokannan fyysistä tietomallia, joka johtaa mm. siihen, että DBA tuo turhaan monimutkaisia teknisiä yksityiskohtia liiketoiminnan pohdittavaksi. Lisäksi tuollaisessa lähestymistavassa on merkittävä vaara, että liiketoiminta tulee tähän fyysiseen tietomalliin väärinkuvatuksi ja sitä kautta fyysisen datamallin refaktorointikustannukset voivat olla dramaattiset, etenkin jos ollaan jo tuotannossa. Vaikka jotkin fyysiset tietomallit kuten Data Vault 2.0 ja suoraviivaisesti toteutettu Star schema (full load), antavatkin paremmin anteeksi mahdollisia ”suunnittelukukkasia”. Tämän takia tietomallintamiseen kannattaa suhtautuakin iteratiivisena prosessina, jossa tietomallia hiotaan asteittain, kunnes lopputulos vastaa tarkasti liiketoimintaa. Lisäksi on hyvä tiedostaa, että hyväkään fyysinen tietomalli ei millään tavoin korvaa kyvykkään DBA:n osuutta tietokannan suorituskyvyllisten ominaisuuksien maksimoimisessa, vaan ainoastaan antaa siihen ainoastaan parhaan mahdollisen pohjan. Jos verrattaisiin datahanketta talonrakentamiseen, voitaisiinkin ajatella, että tietomallintaminen on eräänlaista arkkitehtityötä ja tietokannan fyysinen koodaaminen insinöörityötä.

Tietomallinnuksen ylätason käsiteanalyysi

Tietomallinnuksessa olennaisia ovat oliot, olioiden ominaisuudet sekä olioiden väliset suhteet eli relaatiot. Reaalimaailmassa voidaan kuvata miltei mikä tahansa kokonaisuus mielekkäästi ja ymmärrettävästi nk. käsitemallin avulla. Reaalimaailmassa olioita ovat ne asiat, joilla voi olla useita ominaisuuksia eli attribuutteja. Yksittäinen olio voi sitten joko liittyä tai olla liittymättä toisiin olioihin. Tätä suhdetta olioiden välillä kutsutaan relaatioksi.

Ohessa yksinkertaistettu esimerkki koulumaailmasta, jossa mallinnetaan lukion oppilastietojärjestelmää:

Olioita ovat:

  • Opettaja
  • Oppilas
  • Oppiaine
  • Kurssi

Ominaisuudet jakautuvat olioittain:

Opettajan ominaisuuksia ovat esimerkiksi:

  • Etunimi
  • Sukunimi
  • Syntymäaika
  • Opettajanumero (numero, joka identifioi oppilaan tietojärjestelmässä)

Oppilaan ominaisuuksia ovat esimerkiksi:

  • Etunimi
  • Sukunimi
  • Syntymäaika
  • Oppilasnumero (numero, joka identifioi oppilaan tietojärjestelmässä)

Oppiaineen ominaisuuksia ovat esimerkiksi.

  • Nimi (Englanti, Matematiikka, Psykologia jne.)
  • Kategoria (Kielet, Luonnontieteet, Kasvatustieteet jne.)

Kurssin ominaisuuksia ovat esimerkiksi:

  • Nimi (Englannin preppauskurssi abeille, Tilastotieteen perusteet, Johdanto psykologiaan)
  • Kesto (Kurssin kesto opintoviikkoina)
  • Alkupvm (Esim. 1.4.2023)
  • Loppupvm (Esim. 30.5. 2023)

Relaatio siis kuvaa olioiden välistä suhdetta. Relaatioita voi olla erilaisia. Niitä kuvataan käsitteillä ”nolla”, ”yksi” tai ”monta”. Esimerkiksi:

  • Opettajalla voi olla ”yhdestä moneen” kurssia opetettavanaan
  • Kurssi voi liittyä vain ”yhteen” (=tiettyyn) oppiaineeseen
  • Oppilaalla voi olla ”nollasta moneen” kurssia valittuna (kun oppilas aloittaa kurssien valitsemisen niitä ei ole yhtään valittuna)

Tästä voidaan edelleen olemassa olevien sääntöjen varassa päätellä että:

  • Opettajalla voi olla ”yhdestä moneen” oppiainetta (joku oppiaine on oltava ja jotkut opettaja hallitsevat useammankin oppiaineen)
  • Opettajalla voi olla ”nollasta moneen” oppilasta tietyssä kurssissa (joskus oppilaat eivät valitse tiettyä kurssia ollenkaan)
  • Oppilaalla voi olla ”yhdestä moneen” oppiainetta valittuna (pakko olla ainakin yksi oppiaine)

Käsiteanalyysissä muodostuvaa tietomallia voidaan ylätasolla kuvata yksinkertaisimmillaan näin:

Nyt kun ylätason käsitemalli on selkeä, introan fyysisiä tietomalleja.

Fyysinen tietomalli – OLTP- eli relaatiomalli (3NF)

Operatiiviset eli ns. OLTP-tietokannat ovat transaktiointensiivisiä. Tämä tarkoittaa, että dataa kirjoitetaan ja päivitetään tietokannassa tiuhaan tahtiin lukuoperaatioiden lisäksi. Tällaisia ovat mm. ERP-järjestelmien tietokannat. OLTP-työkuormille tyypillisiä piirteitä ovat pienet tulosjoukot sekä yksinkertaiset kyselyt. Hyvä OLTP-tietomalli on sellainen, jossa oliot ja niiden ominaisuudet esitetään hyvin normalisoituna, kerran ja vain kerran, relaatioineen. Täten saadaan tietokannan transaktionaalinen suorituskyky maksimoitua ja mahdolliset lukitustilanteet minimoitua. Lue täältä lisää OLTP tietokantojen mallinnusmenetelmästä.

Fyysinen tietomalli – Star Schema (tähtimalli)

Eräs fyysisten tietomallien tyypeistä on ns. tähtimalli. Se on raportointitietokannoissa (data mart, EDW) yleisimmin käytetty tietomalli. Tähtimalli on myös OLAP-teknologiassa käytetty skeema ja sitä käytetään hyvin yleisesti myös Power BI-raportoinnissa. Tähtimallin skeema sijoitetaan lähes poikkeuksetta omaan tietokantaansa sen intensiivisten lataus- / tietokantakyselykuormien takia, jotka poikkeavat merkittävästi perinteisten OLTP-kantojen työkuormatyypeistä. Tähtimallissa esitetään laskennallinen data ns. faktatauluissa, joita ympäröivät laskennallista tietoa tyypittävät dimensiotaulut. Lue täältä lisää Star Schema (tähtimalli) tietokantojen mallinnusmenetelmästä.

Fyysinen tietomalli – Snowflake Schema (lumihiutalemalli)

Lumihiutalemalli on eräs fyysisen tietomallintamisen menetelmä, jolla voidaan rakentaa tietovarastoja ja data martteja. Se on läheistä sukua tähtimallille ja hieman etäisemmin data vaultille. Lumihiutalemallissa on enemmän tauluja sekä niiden välisiä liitoksia kuin tähtimallissa, toisin sanoen malli on normalisoidumpi kuin tähtimallissa mutta denormalisoidumpi kuin OLTP-mallissa: Siinä missä tähtimallissa kunkin faktataulun ympärille generoituu yksiulotteisia ”tähden sakaroita” eli dimensioita, lumihiutalemallissa normalisoidaan dimensiorakennetta niveltämällä tähtien sakaroihin ns. ”alidimensioita”. Lue täältä lisää Snowflake Schema (lumihiutalemalli) tietokantojen mallinnusmenetelmästä.

Fyysinen tietomalli – Enterprise Data Warehouse BUS

Enterprise Data Warehouse BUS on eräs fyysisen tietomallinnuksen menetelmä, tai enemmänkin arkkitehtuurinen tapa ajatella tietomallinnusta, jolla voidaan rakentaa konsernitietovarastoja tähtimallin päälle siten, että se ottaa huomioon bisneksen ns. 360-näkymän. Tämä tarkoittaa käytännössä eri järjestelmien välistä yhteistä master dataa, jotka mallinnetaan dimensioiksi. Lue täältä lisää Enterprise Data Warehouse BUS tietokantojen mallinnusmenetelmästä.

Fyysinen tietomalli – Data Vault

Data Vault on tietomallinnuksen ja tietovarastoinnin menetelmä, joka soveltuu monimutkaisen ja muuttuvan tiedon liiketoimintaympäristöön. Tällaisissa liiketoimintaympäristöissä dataa luetaan tietovarastoon useista eri lähteistä suurilla volyymeilla. Data Vault -menetelmän ajatuksena on rakentaa yksilöllisesti linkitetty joukko normalisoituja tietokantatauluja ja mahdollistaa näin tarkka tiedontaso. Data Vault -menetelmässä yhdistetään kolmannen normaalinmuodon (OLTP) ja dimensionallisen tietomallintamisen parhaat puolet yhdeksi hybridimalliksi. Lue täältä lisää Data Vault tietokantojen mallinnusmenetelmästä.

Kiinnostuitko aiheesta? Onko organisaatiossasi ehkä käynnistymässä tietojärjestelmähanke, johon tarvitset tietomallintamisen ammattilaisen apua? Ole hyvä ja ota meihin yhteyttä, ehkä voimme olla avuksi!

Jani K. Savolainen

VP & Chairman

DB Pro Services Oy

Sinua saattaa kiinnostaa myös:
SQL-tietokanta – historia, nykytila ja tulevaisuus: nykytila
Power BI pro ja eri lisensiointimallit
Tiedonhallinta: Kuinka hyödyntää organisaation dataa laajasti, mutta hallitusti
Mikä on Lakehouse tietoalustaratkaisu ja kuinka organisoida data tehokkaasti Lakehousessa?

Raportointitietokannan auditointi Verolle

Microsoftin suosituksen pohjalta DB Pro Services päätyi keskustelemaan laajasta raportointitietokannan auditoinnista Verohallinnolle. DB Pro Servicen kokeneille konsulteille tämä on  yksi tyypillisimmistä projekteista joissa pitää nopeasti analysoida nykytoteutus, tunnistaa sen mahdolliset ongelmakohdat ja ehdottaa korjaavat toimenpiteet. Joten tälläkin kertaa saimme asiakkaan vakuutettua, että meistä voisi olla merkittävää apua tunnistettujen haasteiden selvittämisessä ja korjaamisessa.

Usein tämäntyyppisiin projekteihin liittyy lisäksi valittujen kehityskohteiden toteutus, mutta tässä tapauksessa testasimme ehdottamiamme muutoksia erillisessä ympäristössä ja saimme erinomaisia tuloksia. Projekti eteni sovitussa aikataulussa ja budjetissa. Ohessa asiakkaan palaute suoritetusta työstä:

“Annoimme DB Pro Servicen asiantuntijoille toimeksiannon auditoida laaja raportointitietokantamme. Asiantuntijat tekivät havaintoja, analysoivat syitä ja kokeilivat / suosittelivat korjaustoimia, joilla saatiin aikaiseksi selkeitä parannuksia. Kokemus yhteistyöstä oli erittäin positiivinen.”

Mikko Laakso, Verohallinto

Yksi DB Pro Servicen fokusalueita on Microsoft-pohjaisten tietokanta-, tietovarasto- integraatio- ja raportointiratkaisuiden auditointi ja sen pohjalta tehtävä kehityssuunnittelu ja toteutus. Auditointeja on tehty yrityksen historian alusta alkaen ja tähän mennessä yli 50 eri asiakasympäristöä on läpikäytyinä. Auditoinnin lopputuloshan voisi olla myös se, että kaikki on täydellisessä iskussa. Sellaista toteutusta ei kuitenkaan ole vielä tähän päivään mennessä tullut vastaan vaan aina on jotain kehitettävää löytynyt. Useimmiten riittää nykyisen toteutuksen parametrien ja muiden asetusten optimointi, mutta luonnollisesti voi tulla eteen myös tilanteita, joissa todetaan, että tavoitellun suorituskyvyn varmistamiseksi vaaditaan isompaa arkkitehtuuri- tai alustapäivitystä ja / tai koodioptimointia.

Uskallamme luvata, että historian myötä konsulttiemme kokemuksesta ja matkan varrella kehittämistämme tehokkaista diagnostiikkatyökaluista ja -menetelmistä on varmasti hyötyä jokaiselle organisaatiolle, joka kaipaa apua Microsoft-pohjaisten kanta- tai raportointiratkaisuiden suorituskykyhaasteisiin. Olipa sitten kysymyksessä on premise -pohjainen toteutus tai Azure-pilviratkaisu.

Kannattaa muistaa, että ohjelmiston suorituskykyongelmat voivat johtua ihan yhtä hyvin kantaratkaisusta, integraatiopisteistä tai sovelluksen ja kannan välisen rajapinnan toteutuksesta kuin ohjelmistonkin toteutuslogiikasta. Teettämällä meillä DW / BI / ETL / kantaratkaisun diagnostiikan saa varmuuden siitä, että onko kunkin osa-alueen suorituskyky riittävä. Mikäli ei, meiltä löytyy ongelmien tunnistamiseen ja korjaamiseen huippukonstit ja -konsultit!

Kerromme mielellämme lisää, jos tunnistat tämäntyyppisiä haasteita omassa organisaatiossasi.

Lue myös: Power BI-raportointi – tasapaino tekniikan ja muotoilun välillä 

Milloin tietokanta-alustan modernisointi on perusteltua?

Tietokanta-alusta kehittyy jatkuvasti sen myötä, kun organisaatioon tulee uusia sovelluksia, käyttäjiä ja lisää dataa. Yleensä juurisyynä on kasvava ja kehittyvä liiketoiminta, mutta myös stabiilimmissa tilanteissa tietokanta-alusta ja siihen kohdistuva kuormitus voi ajan saatossa muuttua merkittävästikin. Siten se alustakokonaisuus, joka aikanaan on rakennettu parhaiden käytäntöjen mukaisesti ja sen hetkisen kuormituksen pohjalta, ei välttämättä enää 3-4 vuoden jälkeen vastaakaan tämän päivän liiketoimintavaatimuksiin.

Tarve modernisointiin voi tulla myös versiotuen loppumisen myötä. Nythän olemme tilanteessa, jossa SQL Server 2008 ja 2008 R2 -versioiden tuki loppuu tulevana kesänä (9.7.2019). Microsoftin linjaus asiasta on, että ”tuen päättyminen tarkoittaa, että säännöllisten tietoturvapäivitysten julkaiseminen loppuu. Kyberhyökkäykset yleistyvät ja kehittyvät jatkuvasti. Sovellusten ja datan käyttäminen ilman tukea jäävillä ohjelmistoversioilla voi aiheuttaa merkittäviä tietoturva- ja vaatimustenmukaisuusriskejä. On erittäin suositeltavaa, että asiakkaat päivittävät järjestelmänsä niiden uusimpiin versioihin. Se takaa parhaan suorituskyvyn ja tehokkuuden sekä säännölliset tietoturvapäivityksen”.  

Liiketoiminta-, tai tietoturvakriittisten järjestelmien yhteydessä ei pidä käyttää vanhentuneita, ohjelmistotoimittajan tuen piiristä pudonneita tietokantaversioita. Tai jos käyttöä kuitenkin jatketaan niin sen taustalla tulee olla tietoinen päätös ja siihen liittyvä riskiarviointi on tehtävä.

Microsoftin tuotetuen loppuminen vaikuttaa myös sovellustoimittajiin: uudet sovellukset eivät välttämättä toimi vanhan SQL Server -version kanssa, ja tällöin liiketoiminnan sovelluspäivitys voi muuttua laajemmaksi hankkeeksi kantakerroksesta alkaen.

Uudet SQL Server -versiot sisältävät merkittäviä parannuksia

Jos edellä oleva olikin hieman peloittelua niin sitten positiivisiin puoliin, joita modernisoinnilla on saatavilla. SQL Server 2008R2 on oivallinen kantamoottori, mutta merkittävää kehitystä on vuosikymmenen aikana tapahtunut. Uudet versiot tuovat mukanaan parannuksia ja mahdollisuuksia data-alustan kehittämiseen on valtava määrä. Ja mikä parasta, monet uudet ominaisuudet eivät vaadi Enterprise -versiota vaan ne on tuotu myös Standard -versioon.

SQL Server -versiopäivitys

Muutamia esimerkkejä uudempien SQL Server -versioiden sisältämistä parannuksista:

  • Ylläpitäjiä ilahduttavia ominaisuuksia ovat parannukset vikasietoisuuteen ja järjestelmän valvontaan sekä suorituskykyyn. AlwaysOn Availability Groupit mahdollistavat vikasietoisuuden yksinkertaisten DAS-ratkaisujen (Direct Attached Storage) avulla. Korkean käytettävyyden ratkaisun voi toteuttaa ilman mutkikasta infraa vaativaa SAN -ratkaisua, FibreChannelia, iSCSI -verkkoja tai virtualisointialustan raakalevyjä.
  • QueryStore kerää automaattisesti tietoja kyselyistä ja niiden suorituskyvyssä tapahtuneista muutoksista. Tämä helpottaa merkittävästi järjestelmän suorituskyvyn seuraamista, eikä erillistä valvontasovellusta välttämättä tarvita.
  • Resource Governor mahdollistaa työkuormien jaottelun ja sekä levy- että prosessoriajan kiintiöinnin. Esimerkiksi pitkille analysointi- ja ETL -latausajoille voidaan asettaa kiintiö, joka hillitsee niiden vaikutusta muuhun käyttöön.
  • Valtaosa tietokantapalvelimista kärsii levyjen hitaudesta, ja tämä korostuu iäkkäämmässä ympäristössä jossa myös levyjärjestelmä on vuosia vanha. Tyypillistä on myös suorittimien suhteellisen suuri joutenolo. Kun palvelin odottaa tietojen hakua levyltä, ei prosessoreillakaan ole juuri tekemistä. Tässä SQL Server tarjoaa uusia mahdollisuuksia: käytetään vähän suoritinaikaa datan pakkaamiseen ja purkamiseen lennossa. Tällöin levyn käsittely vähenee ja suorituskyky paranee. Rivi- ja sivutason pakkaaminen ovat olleet aiemmin Enterprise -version herkkuja, mutta SQL Server 2016 SP2 toi ne myös standardiversioon.
  • Columnstore index sekä pakkaa että ryhmittelee tiedot sarakkeittain perinteisen rivityksen sijaan. Tämä mahdollistaa analytiikkalaskennassa merkittäviä suorituskykyparannuksia.
  • Sovelluskehittäjien aika on yrityksessä merkittävä menoerä. Heitä ilahduttavatkin uudet ominaisuudet, kuten R- ja Python -tuki, natiivituki Json -tietorakenteille, uusia T-SQL -funktoita merkkijonojen käsittelyyn,  DML-toimenpiteisiin sekä viimeinkin surullisen kuuluisan String or binary data would be truncated -virheilmoituksen paremmat diagnosointimahdollisuudet.

Kuinka onnistut tietokanta-alustan modernisointihankkeessa

Modernisointi on järkevää aloittaa nykyisen alustan auditoinnilla. Auditoinnilla selvitetään resurssivaatimukset (CPU, muisti ja levytila), jotta pystytään varmistamaan uuden alustan resurssien riittävyys vuosiksi eteenpäin  ̶   eli tyypillisesti 4-5 vuodeksi. Resurssien tarve voidaan ennustaa seuraamalla nykyisen alustan resurssien käyttöä esimerkiksi kolmen kuukauden ajalta. Seurantaa voidaan tehdä käsipelillä tai käyttämällä siihen soveltuvaa ohjelmistoa, kuten SQL Governor. Mitä pidemmältä ajalta seurantaa tehdään sitä tarkempi ennuste tulevaisuuden tarpeista voidaan luoda.

SQL Governor uuden tietokanta-alustan suunnittelu ja optimointi

Modernisoinnissa tulee huomioida myös uuden alustan optimointi tulevan käytön vaatimuksiin. Tietokanta-alustan optimoinnin voi jakaa karkeasti kolmeen vaiheeseen; rauta/virtuaali-palvelimen optimointi, käyttöjärjestelmä-asetusten määrittely sekä itse SQL Server -asetusten optimointi. Jokaisen osa-alueen määrittely on tehtävä tarkoin, jotta vältytään tulevaisuuden suorituskykyongelmilta.

Siirtovaiheessa voidaan, ja kannattaakin, tehdä myös tietokantatason optimointia, muun muassa ottamalla käyttöön uuden SQL Server -version tuomia ominaisuuksia (Columnstore index, kompressointi jne..). Muutenkin on hyvä ottaa käyttöön parhaita tietokantatason käytäntöjä, kuten datan jakaminen useaan tiedostoon, suurten taulujen partitiointi, jne.

Uuden alustan käyttöönoton jälkeen on hyvä tehdä uusi auditointi noin kuukauden käytön jälkeen. Uudella alustalla esimerkiksi kyselyiden suorituspolut voivat olla hyvinkin erilaisia vanhaan verrattuna. Indeksien käyttö ja uusien indeksien tarve voikin olla hyvä selvittää.

Esimerkki onnistuneesta tietokanta-alustan uudistamisesta

Lopuksi käytännön esimerkki toteutetusta modernisointiprojektista, jossa DB Pro Servicen asiantuntijoilla oli merkittävä rooli.

Asiakkaamme Versowoodin modernisointiprojektissa uudistettiin sekä käyttöjärjestelmä- että tietokanta-alusta, tavoitteena kokonaisuus, joka vastaa tarpeisiin pitkälle tulevaisuuteen. Hankkeen lopputuloksena saavutettiin uusi tietokanta-alusta, jolla asiakas sai merkittäviä parannuksia tietokanta-alustan suorituskykyyn  ̶  parannukset vaihtelivat parhaimmillaan 40% ja 80 % välillä.

”Kokonaisuudessaan projekti onnistui hyvin ja täytti tavoitteensa, joka oli saavuttaa tarpeisiimme optimoitu alustakokonaisuus, joka palvelee meitä useita vuosia”, totesi Versowoodin Antti Kari meille projektin jälkeen.

Häämöttääkö sinullakin tietokanta-alustan uudistamishanke edessäsi? Ota yhteyttä ja jutellaan, miten voimme olla avuksi!

DB Pro Services
Jani Savolainen, VP & Chairman
Mikko Hyvärinen, Lead DBA & Architect, Partner