Kirjoitan tämän blogisarjan siksi, että olen huomannut, ettei SQL Serverin wait statistics-analyysistä ole kirjoitettu kovinkaan montaa kattavaa blogia siitä, miten se todella toimii ja kuinka tätä tulisi analysoida. Aihe on kuitenkin tuiki tärkeä siksi, että suuri osa SQL Serverin oireista ilmenee wait statseja diagnosoimalla. Wait statsit ovat kuin lääkärin keinovalikoima analysoida kipuilevan potilaan oireita, joiden pohjalta voidaan rajata potentiaalista diagnoosia, sekä syventää ymmärrystä ongelman juurisyystä, parhaimmillaan jopa suoraan ratkaista se.

Wait statistics – mikä se on?

Kun SQL Server käy ja kukkuu, se käytännössä aina odottaa jotakin resurssia, olkoon se verkko, levyoperaatio, taululukko, prosessorisuoritus, mikä ikinä. Tämä siksi, että SQL Serverin toiminta koostuu, rajusti yksinkertaisettuna, lukuisista rinnakkaisista tehtävistä (task), joita allokoidaan prosessorin suoritussäikeille (worker thread). Nämä suoritussäikeet pyrkivät huolehtimaan siitä, että kaikki tehtävät suoritetaan tietyllä prioriteetilla. Joskus tulee ruuhkaa johonkin yksittäiseen resurssiin, kuten vaikkapa verkkoon tai tallennusjärjestelmään, ja silloin joudutaan odottelemaan tavallista kauemmin säikeiden suoritusta loppuun. Tämä on juurikin sitä statistiikkaa, jonka normaaliolojen (baseline) sekä otosten (snapshot) välinen ero kertoo siitä, mitkä arvot poikkeavat normaalista. SQL Server kerää tätä statistiikkaa systeeminäkymiinsä millisekunnin tarkkuudella. Tässähän on suora allegoria verikokeisiin! SQL Serverin wait stats -diagnostiikka eroaa kuitenkin ihmisen verenkuvan diagnosoinnista pääsääntöisesti siinä, että jokaisella SQL Serverillä on yksilöllinen baseline toisin kuin ihmisten ”ihannearvoilla” esim. hemoglobiinin suhteen. Tämä johtuu siitä, että wait statsit ovat suhteellisia: Verkko, palvelimet ja storage ovat eri, instanssikongfiguraatiot ja tietokanta-asetukset ovat eri, SQL Serverin versiot ja editiot ovat eri ja tietokantaskeemat, -sisällöt ja niiden käyttötapa optioineen ovat aivan eri, miltei aina, ympäristökohtaisesti.

Vaikka aihe on erittäin keskeinen SQL Serverin sielunelämän ymmärtämiseksi, kuitenkaan moni tietokantojen kanssa päivittäin toimiva koodari, Data Engineer tai jopa DBA ei huomiokseni tiedä riittävästi tai lainkaan tästä asiasta. Ehkä kuitenkin kannattaisi tietää. Perään heti varoituksen sana kuitenkin: Aihe on hyvin monsäikeinen ja paikoin vaikeaselkoinen, siksi aiheeseen perehtyminen vaatii hieman kärsivällisyyttä – ja aikaa. Jo yksistään siksi, että SQL Server 2022:ssa on pitkästi yli 1000 erilaista wait statsia ja lisää tulee koko ajan, jokaisessa SQL Server-versiossa (SQL Server 2017: 921 kpl, SQL Server 2022: 1335 kpl). Tosin kaikkia wait statseja sinun ei tarvitse tietää, koska kaikki niistä eivät ole merkittäviä SQL Serverin performanssidiagnostiikan kannalta – jo muutaman kymmenen keskeisimmän wait statsin ymmärtäminen auttaa sinua paljon.

SQL Server-diagnostiikka yleisesti

SQL Serverin suorituskykyä diagnosoitaessa on huomioitava hyvin laaja-alainen joukko asioita, kuten:

• Palvelin- ja virtualisointialusta
• Verkko- ja tallennusratkaisu
• Käyttöjärjestelmä asetuksineen
• SQL Server-instanssit ja tietokannat asetuksineen
• Indeksointi, statistiikat ja tietokantakyselyt
• Wait statistis
• Plan cache
• Query tracing

Wait statistics-analyysi on erinomainen tapa aloittaa SQL Server-diagnostiikka eritoten silloin, kun vallitsevasta ongelmasta ei ole mitään hajua. Toki myös järjestelmäkonfiguraatiot on syytä käydä läpi, sillä verrattain usein törmää ns. ”sellofaaniasetuksiin” sekä epäoptimaalisiin systeemikonfiguraatioihin, jotka voivat vaikuttaa järjestelmän kokonaissuorituskykyyn ratkaisevasti. Tosin nämä ovat jo sinällään monesti juurisyitä, eivät niinkään ”taudin oireita”, joita juurikin haetaan tyypillisesti wait statsien avulla.

Vaikka saatkin kattavan käsityksen kokonaisuudesta diagnosoimalla wait statseja, tässä on kuitenkin koira haudattuna: Kuten jo aiemmin mainitsin, kullakin SQL Serverillä on yksilöllinen baseline. Tällöin, kun ongelma on jo päällä, on haastavempaa nähdä, mikä on poikkeuksellista wait statseissa. Ja koska SQL Server nollaa wait statsit aina instanssin restartin yhteydessä, on viisasta käyttää eritoten liiketoimintakriittisissä tietokantapalvelimissa aina jotain ulkoista SQL Serverin monitorointi- / performanssioptimointisoftaa, kuten SQL Governoria, jolloin pystyt vertailemaan reaaliaikaista wait stats -otostasi sen aiemmin muodostuneeseen baselineen.

Wait Statisticsin historiaa – lyhyt oppimäärä

SQL Serverin ensimmäinen versio julkaistiin vuonna 1989 OS/2 -alustalle. Microsoft työskenteli yhteistyössä Sybasen kanssa vuoteen 1995 saakka aiheen tiimoilta. Kun sitten SQL Serverin 6.0 -version myötä Sybasen ja Microsoftin tiet erkanivat, wait statsit ovat olleet se mekanismi, jolla SQL Server Operating System, tuttavallisemmin SQLOS, tallentaa sisäisten prosessiensa muutoksia ajan funktiona. SQL Serverin 2005-versiosta lähtien wait statseja on voinut kysellä nykymuotoisesti Dynamic Management Viewien kautta (DMV) aiemmin käytössä olleiden DBCC-kyselyjen sijaan.

SQL Serverisi wait statseja voit ihmetellä tästä systeeminäkymästä:

select * from sys.dm_os_wait_stats;

SQLOS – ensikurkkaus konepellin alle

Ennen SQL Server 2005:ää sen alustakerros oli hyvin rajoittunut ja SQL Serverin moni operaatio suoritettiin käyttöjärjestelmätasolla. Tämä tarkoitti sitä, että SQL Serverin oli vaikeaa pysyä perässä uusissa hardwaremuutoksissa ja tekivät siitä käyttöjärjestelmäversioriippuvaisen, mikä hidasti ja rajoitti konkreettisesti uusien, tehokkaampien hardware-ominaisuuksien hyödyntämismahdollisuuksia. Tämän takia SQL Serverin versioon 2005 kehitettiin kokonaan uusi alustakerros, SQLOS, joka on pitkälle konfiguroitava. Sen tärkein tehtävä on ohittaa käyttöjärjestelmätaso ja sopeutua hyödyntämään maksimaalisesti nykyistä ja tulevaa hardware-alustaa.

Miksi SQLOS?

Windows OS käyttää ns. ”preemptive scheduling” -lähestymistapaa: Se tarkoittaa, että jokainen prosessi, joka tarvitsee prosessoriaikaa, saa sitä Windosilta viipaleen, jota kutsutaan nimellä ”quantum”. Prosessin prioriteetti taas lasketaan monimuuttujayhtälöstä, johon vaikuttavat mm. resurssien käyttö, odotettu ajoaika, aktiivisuustaso jne. Preemptive scheduling -mekanismia hyödyntämällä Windows voi keskeyttää yhden prosessin, mikäli jokin toinen prosessi korkeammalla prioriteetilla tarvitsee prosessointiaikaa. Tällainen skedulointimekanismi olisi myrkkyä SQL Serverin suorituskyvylle, koska SQL Server voisi helposti jäädä jonkin toisen, korkeamman prioriteetin sovelluksen jalkoihin. Tämän takia SQL Serverillä onkin SQLOS:ssä ikioma, non-preemptive skedulointimekanisminsa, joka varmistaa, ettei käyttöjärjestelmä pääse ”väliin sekoilemaan” silloin, kun käyttöjärjestelmää ei tarvita.

Summa summarum

Tässä blogijaksossa opimme, että wait statisticsit näyttelevät tärkeää roolia SQL Serverin performanssidiagnostiikassa. Tämän lisäksi opimme, että kaiken tämän mahdollistaa SQLOS. Seuraavaksi sinun tulisi ymmärtää, mitä ovat sellaiset veijarit kuin SQLOS:n Schedulerit, Taskit ja Worker threadit. Niiden toiminnalliset perusteet onkin syytä ymmärtää, ennen kuin voimme porautua tarkemmin wait statsien kiintoisaan sielunelämään. Siitä seuraavassa blogijaksossani!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

Osana blogisarjaa erilaisista datatiimien rooleista käyn tässä blogissa läpi data-analyst roolin merkitystä osana datatiimiä. Data-analystin rooli voi mukautua ja sekoittua data scientist, data architect tai data engineer tekemiseen projektin mukaan, mutta
lyhyesti tiivistettynä data-analystin tärkein tehtävä on toimia sillanrakentajana liiketoiminnan ja datatiimin välillä. Tämä ei itsessään kerro vielä paljon, joten avaan asiaa kolmen mielestäni tärkeimmän data-analystin taidon kautta.

Data-analystin tärkeimmät taidot:

• Analytiikan taustalla olevan liiketoimintatarpeen ymmärrys
• Datan mallinnus raportointitarpeiden näkökulmasta
• Tarinankerronta datan avulla
  
  

Valitsin nämä kolme kokonaisuutta blogiini myös sen takia, että näiden kolmen kokonaisuuden avulla voimme kuvailla ylätasolla miten hyvin tyypillinen data-analytiikka projekti etenee.

Analytiikan taustalla olevan liiketoimintatarpeen ymmärrys

Data-analytiikka pyrkii tukemaan ja parantamaan päätöksentekoa. Konkreettisesti sen tavoitteena on vähentää mutuilua päätöksenteossa ja mahdollistaa tietoon perustuva päätöksenteko. Tämä ei kuitenkaan tarkoita, että hiljainen tieto, kuten kokemukseen tai vaistoon perustuvat näkemykset, katoaisi päätöksenteosta kokonaan. Sen sijaan suhde datan ja hiljaisen tiedon välillä muuttuu. Allegoriana tästä toimii vesilasi: jos historiallisesti päätöksenteon “vesilasissa” on ollut puoli desiä dataa ja puolitoista desiä mutua, data-analytiikka voi auttaa kääntämään tilanteen päälaelleen. Tällöin päätökset perustuvat ensisijaisesti dataan, mutta hiljainen tieto täydentää analyysiä.

 Historiallisesti päätöksenteon tueksi on kehitetty useita järjestelmiä, kuten Decision Support Systems (DSS) ja Executive Information Systems (EIS). Nykyisin Business Intelligence (BI) -työkalut edustavat modernia data-analytiikan paradigmaa. BI-työkalut, kuten Power BI ja Tableau, erottuvat EIS-järjestelmistä etenkin kyvyllään yhdistää tietoa useista eri järjestelmistä sekä tarjoamalla mahdollisuuden itsepalveluraporttien rakentamiseen. Tämä tekee BI:stä entistä joustavamman ja käyttäjälähtöisemmän työkalun päätöksenteon tueksi.

Koska data-analytiikan tavoitteena on tukea päätöksentekoa, data-analyytikon on tärkeää ymmärtää, mitä päätöksiä liiketoiminta pyrkii tekemään. Tämä tarkoittaa sitä, että analyytikon on perehdyttävä tarkasti liiketoiminnan tarpeisiin ja niiden erityispiirteisiin. Kysymällä oikeita kysymyksiä ja syventymällä tarpeisiin analyytikko pystyy varmistamaan, että analytiikasta tuotettava tieto vastaa juuri niihin kysymyksiin, joilla on merkitystä liiketoiminnalle. Tämä parantaa analyysin vaikuttavuutta ja auttaa yritystä tekemään tietoon perustuvia päätöksiä.

Datan mallinnus raportointitarpeiden näkökulmasta

BI-työkalut ovat tyypillisesti se paikka mistä eri järjestelmissä olevaa dataa tutkitaan. Tästä syystä BI-työkaluissa taustalla oleva datamalli on kriittinen osa analytiikkaa, sillä huonosti rakennettu datamalli vaikeuttaa analytiikkaa. BI-työkalujen laskentatehokkuus kärsii, jos data malli on huonosti suunniteltu. Tämä johtaa usein analytiikan hitauteen ja lisäkustannuksiin lisenssien osalta.

Datan mallinnus on kriittinen osa dataprojektia, sillä kun datainsinöörit, data-arkkitehdit ja data-analystit ovat samaa mieltä siitä millaista datamallia rakennetaan heidän, välisensä yhteistyö on sujuvampaa. Yhteinen visio siitä miten data tulisi strukturoida tiivistää dataprojektin vision ja näin mahdollistaa tehokkaamman työnteon.

Data-analystin tulisi myös ymmärtää miten eri datamallit vaikuttavat performanssiin visualisointien näkökulmasta ja miten työkalut kyselevät erilaisissa datan tallennusvaihtoehdoissa. Tyypillisesti näissä työkaluissa data on BI-työkalujen datamalleissa joko muistipohjainen (in-memory storage) tai realiaikainen (live connection, directquery). Muistipohjaisissa malleissa dataa kysellään tyypillisesti työkalun omalla teknologialla, (vertipaq, hyper, associative engine), kun taas realiaikaisissa yhteyksissä kielenä on usein, mutta ei aina, SQL.

Datan tallennustyyppi vaikuttaa siihen millainen datamallin tulisi olla data-analytiikan osalta. Tämä on ilmeisintä, kun datamäärät ovat valtavia ja datamallin optimointi on analytiikan edellytys. Esimerkkinä tästä toimii seuraava tilanne:

Yritys X haluaa tutkia varastosaldojaan WMS järjestelmästä missä varastotapahtumat ovat tallennettu kumulatiivisesti. Jotta yritys X saa nykyisen varastosaldon, heidän täytyy laskea varastohistoria 10 vuoden ajalta. Tämä tarkoittaa 500 miljoonan rivin laskentaa.

Tällainen skenaario tulisi nostaa data-analystille paljon kysymyksiä. Mikä on liiketoimintatarve? Millaisia visualisointeja datasta halutaan tehdä? Millä granulariteetti tasolla dataa halutaan tutkia? Voiko kumulatiivisen laskennan tehdä kannassa? Jos liiketoiminta haluaa nähdä datan transaktiotasolla ja mahdollisesti kaiken datan samassa kuvaajassa, osa laskennasta täytyy tehdä jo data-alustalla. Jos laskenta tehdään visualisointitasolla, on todennäköistä, että BI-työkalu antaa seuraavan tyyppisen virheilmoituksen: ” Visual has Exceeded Available Resources”/ ”Out of Memory”. Ratkaisuna voisi olla esimerkiksi malli, jossa data-alustalla lasketaan yhteen tauluun nykyistä kuukautta edeltävät varastosaldot kumulatiivisesti ja Bi-työkalussa tehtäisiin loppuosa laskennasta dynaamisesti. Toisaalta jos liiketoiminnan kanssa käytävästä dialogista ilmenee, että päätöksenteon tueksi riittää kuukausitason näkymä varastosaldoista datan voidaan aggregoida kuukausitason tauluun. Tämä vähentää käsiteltävän datan määrää valtavasti ja näin ratkoo ongelman.

Data-analystin tulee myös pystyä miettimään millainen datamalli vastaa liiketoimintatarpeen vaatimuksiin dimensio- ja faktataulujen osalta. BI-työkaluissa tehtävä analytiikka on luonteeltaan dynaamista ja sen toiminta on usein riippuvainen erilaisista dimensioista millä dataa halutaan suodattaa. Talousanalytiikassa hyvä esimerkki voisi olla kustannuspaikka tai liiketoimintayksikkö kohtainen suodatus. Jotta liiketoiminta käyttäjä voi tarkastella faktataulun pohjalta laskettuja tunnuslukuja dimensiotaulujen relaatiot täytyy olla toimivia. Data-analyst hahmottaa mitä lopullinen raportointi vaatii näiden taulujen osalta ja näin voi kommunikoida vaatimuksen datainsinöörille.

Tarinankerronta datan avulla

Data-analytiikan tavoite on mahdollistaa ”eureka-hetket” jolloin datasta paljastuu havaintoja minkä avulla voidaan tehdä faktaan pohjautuvia päätöksiä. Erilaiset datan visualisointi menetelmät soveltuvat erilaisiin data tyyppeihin juuri tästä syystä.

Olen kirjoittanut blogin siitä, miten voit valita oikean visualisointityypin datalle, mutta otetaan ääriesimerkki siitä, miten datan visualisointi voi mahdollistaa tai esimerkin kohdalla estää havaintojen tekemisen. Seuraavat kaksi kuvaajaa esittävät samaa dataa.

Kuvaaja 1 pinottu Area chart:

Kuvaaja 2 pylväsdiagrammi samasta datasta:

Toisin kun ensimmäisessä kuvaajassa datan tulkitsija voi tehdä johtopäätöksiä datasta ja sen implikaatioista toisessa kuvaajassa. Data-analystin tehtävä on miettiä miten erityyppistä dataa voi esittää niin että siitä voi tehdä käytännöllisiä oivalluksia.

Pelkkä visualisointien oikeanlainen valinta ei kuitenkaan yksinään riitä tähän vaan data-analystin tulee miettiä myös raportointikokonaisuutta. Tämä on erityisen tärkeää, kun data projektissa pyritään rakentamaan itsepalvelu raportointikokonaisuuksia. Dashboardit ja raportit tulee suunnitella dataprojektissa niin, että kokonaisuus ei ole liian ”meluisa”. Enemmän on usein vähemmän raportoinnissa ja erilaisten design periaatteiden miettiminen ja seuraaminen kuuluu data-analystin tontille.

Käytännön esimerkki tästä dataprojektissa on valintojen implikaatioiden kommunikointi liiketoiminnan edustajille. On helppoa mukautua siihen mitä loppukäyttäjä toivoo ja rakentaa juuri sellaista raportointia mitä data-analystiltä pyydetään, mutta mielestäni tällaisessa tilanteessa hyvän data-analystin vastuulle kuuluu ainakin kertoa mitä seurauksia, sillä on datan analysoinnin näkökulmasta, jos raportointi rakennetaan liian monimutkaiseksi ja liian täyteen erilaisia visualisointeja.

Yhteenveto

Yhteenvetona voidaan todeta, että data-analystin rooli on keskeinen osa datatiimiä, ja heidän tehtävänsä on toimia sillanrakentajana liiketoiminnan ja datatiimin välillä. Data-analystin tärkeimmät taidot – liiketoimintatarpeen ymmärtäminen, datan mallinnus raportointitarpeiden näkökulmasta ja tarinankerronta datan avulla – auttavat varmistamaan, että analytiikka tukee liiketoimintapäätöksentekoa tehokkaasti. Data-analysti ei vain valitse oikeita visualisointeja ja rakenna toimivia datamalleja, vaan myös varmistaa, että raportointi on selkeää ja käytännöllistä loppukäyttäjälle. Hyvin suoritettu analytiikka parantaa päätöksenteon laatua ja mahdollistaa tietoon perustuvan päätöksenteon, joka tukee yrityksen strategisia tavoitteita.

DB Pro Services tarjoaa huippuluokan data-analyytikoita, jotka hallitsevat Azure- ja AWS-alustat sekä Databricks-, Snowflake-, Fabric- ja Synapse-tietoalustat. Ota yhteyttä, niin autamme sinua ja organisaatiotasi hyödyntämään dataa tehokkaasti ja tekemään parempia päätöksiä!

Valtteri Nättiaho

Lead Data Analyst

S-posti: Valtteri.Nattiaho(a)dbproservices.fi

LinkedIn: Valtteri Nättiaho | LinkedIn

Puhelin: +358 400 847 405

Valtteri on Power BI:n syväosaaja, joka tykkää ratkoa data-analytiikkaan liittyviä haasteita. Hänellä on kokemusta Power BI:stä vuodesta 2016 alkaen ja pyörittelee ohjelmistoa myös vapaa-ajallaan, jolloin hänet saattaa bongata golf-kentän lisäksi myös Fabricin Power BI foorumeilla, missä hän vastailee Power BI ongelmiin.

Sinua saattaisi kiinnostaa myös:
Mikä on datainsinööri?
Mikä on DBA (Database Administrator)?

Tässä blogisarjan toisessa osassa kiteytän oman konesalin ja julkipilven keskeisiä eroavaisuuksia osana data-alustojen FinOps-toteutuksia. Vaikkakin yhteneväisyyksiä löytyy monella osa-alueella, useat eroavaisuudet johtuvat perustavanlaatuisista eroista kustannusrakenteissa, resurssiallokaatioissa sekä toimintamalleissa näiden kahden ympäristön välillä. Selvimmin tilannetta voidaan kuvata vertailemalla data-alustoja FinOps:n näkökulmasta:

Kustannusmalli ja palvelun hinnoittelu

Kustannusmallin erot ovat selkeät ja avautuvat parhaiten klassisen Capex / Opex -ajattelun kautta:

Julkipilvi	Oma konesali
Pay-as-You-Go: Kustannukset perustuvat resurssien kulloiseenkin käyttöasteeseen ja ne laskutetaan kuukausittain, mikä tarjoaa yksityiskohtaisen näkyvyyden resurssikulutukseen (esim. laskentateho, datan liikkuminen ja tallennus).	Kiinteät kustannukset: Kustannukset ovat kiinteän kaltaisia, joita voidaan jaksottaa erilaisilla maksujärjestelyillä. Infrastruktuuriin (laitteistot, lisenssit, tilat) tehdään mittavia etukäteisinvestointeja. Konesalin käyttökustannukset (esim. jäähdytys ja sähkö) ovat luonteeltaan toistuvia.
Joustava hinnoittelu: Asiakas voi optimoida omia kulujaan sitoutumalla tiettyihin palveluihin ja kapasiteettiin ja saada tätä kautta säästöjä. Julkipilvi tarjoaa asiakkaalle ketterän tavan kuluttaa käytön mukaan ja välttää etukäteisinvestointeja. Ketteryyden mukana saattaa tulla korkeammat kustannukset ja ne on syytä analysoida yhdessä liiketoiminnan hyötyjen kanssa.	Staattinen hinnoittelu: Kustannusten määrä on vakio käytöstä riippumatta. Kustannuksia voidaan kohdentaa käyttäjien mukaan, mutta organisaation kokonaiskustannus on kohdentamisen lähtökohta ja rajoittaa siten organisaation sisäisiä hinnoittelumahdollisuuksia. Organisaatio voi saavuttaa kustannustehokkuutta erilaisilla konsolidoinneilla ja optimoinneilla, joiden avulla käyttäjille jaettavaa kokonaiskustannusta saadaan pienemmäksi.

Resurssien skaalautuvuus

Resurssien skaalautuvuus ja joustavuus ovat merkittäviä tekijöitä organisaation FinOps -matriisissa, jossa pyritään kustannusoptimoimaan tarvittavia resursseja. Optimoinnissa on tyypillisesti kyse julkipilven joustavuuden ja oman konesalin kustannustehokkuuden sekä suorituskyvyn yhteensovittamisesta. Yksinkertaistetusti sanottuna julkipilvi on hyvä ratkaisu sellaisiin tarpeisiin, joissa resurssitarvetta on vaikea ennustaa ja oma konesali perustelee usein paikkansa silloin, kun resurssitarve on hyvin tiedossa.

Julkipilvi	Oma konesali
Skaalautuvuus tarpeen mukaan: Resursseja voidaan skaalata ylös- tai alaspäin dynaamisesti työkuormaperusteisesti. Julkipilvestä resursseja on saatavilla käytännössä rajattomasti.	Rajoitettu skaalautuvuus: Skaalaaminen saattaa edellyttää jossain vaiheessa uuden laitteiston hankintaa, asennusta ja konfigurointia, mikä vie aikaa. Alaspäin skaalautuminen voi olla hankalaa.
Elastisten työkuormien tuki: Ihanteellinen vaihteleviin työkuormiin, kuten eräajoihin tai koneoppimiseen sekä voimakkaasti kausiluontoisiin tapahtumiin ja uusien palveluiden käyttöönottoon.	Kapasiteettisidonnaisuus: Konesalin fyysinen kapasiteetti rajoittaa suorituskykyä ja skaalautuvuutta ja voi johtaa tilanteisiin, joissa resurssit loppuvat ilman lisäinvestointeja.

Kustannusten allokointi ja vastuullisuus

Kustannusten allokointi on julkipilvessä helpompaa. Toisaalta julkipilvessä voi joutua maksamaan samasta käyttökapasiteetista enemmän kuin omassa konesalissa. Oman konesalin kustannukset kuormittavat organisaatiota 24/7 -periaatteella, kun taas julkipilvestä ostetut palvelut ovat hinnoiteltu käytön mukaisesti. Jos asiakkaan toiminta keskittyy esimerkiksi kahdeksalle tunnille päivässä, miksi maksaa ylimääräisestä 16 tunnista?

Julkipilvi	Oma konesali
Yksityiskohtainen kustannusten kohdistaminen: Kustannukset voidaan kohdistaa tietyille projekteille, ryhmille tai sovelluksille erilaisten tunnisteiden, tilien tai tilausten kautta.	Karkea kustannusten kohdistaminen: Kustannukset ovat vähemmän yksityiskohtaisia ja jaetaan usein arvioiden tai kiinteiden prosenttiosuuksien perusteella, ellei yksityiskohtaista käytön seurantaa toteuteta. Kustannusten kokonaissumma, eli kohdennettava kustannus, pysyy kuitenkin aina samana.
Showback / Chargeback: Alkuperäiset työkalut, kuten Azure Cost Management tai AWS Cost Explorer, mahdollistavat yksityiskohtaiset kustannusten kohdentamiset.	Räätälöity Showback / Chargeback: Kattavan mallin toteuttaminenvaatii manuaalista kohdentamista tai kolmansien osapuolten ratkaisujen hankintaa.

Näkyvyys ja monitorointi

Data-alustan kustannusten ja palveluiden laadun näkyvyyden ja monitoroinnin osalta on hyvä valita sellainen ratkaisu, joka palvelee sekä oman konesalin ja julkipilven osalta yhtenä kokonaisuutena.  Omien konesalien ja julkipilvien data-alustojen kustannukset ovat usein omissa lokeroissaan, jolloin niiden vertaileminen voi olla haastavaa.

Julkipilvi	Oma konesali
Kustannusoptimointimahdollisuudet: seuranta on helppoa, mutta kustannusoptimointi vaatii perehtymistä ja samanlaista syväosaamista kuin omien konesalien osalta. Julkipilvien osalta kustannusoptimoinnin mahdollisuudet ovat merkittäviä ja vaikuttavia, koska optimoimalla saadaan nopeasti näkyviä vaikutuksia organisaation kokonaiskuluun.	Kustannusoptimointimahdollisuudet: Omien konesalien kustannusten optimoinnin osalta on ennemminkin kyse resurssien optimaalisesta ja tehokkaasta hyödyntämisestä, kuin kustannustason alentamisesta. Eli samalla resurssimäärällä saadaan tehtyä enemmän. Tämä sen takia, että tehdyt investoinnit ovat määrittäneet kokonaiskustannusten minimitason. Tämän takia omien konesalien ja julkipilvien vertailua olisi hyvä tehdä samalla pöydällä, jolloin pystytään objektiivisesti päättämään kustannustehokkain tapa tuottaa tarvittavia palveluita.
Palvelukohtaiset kustannustiedot kokonaiskustannusten alentamiseksi: Lähes välitön pääsy käyttötietoihin mahdollistaa ennakoivan kustannusten hallinnan lyhyellä aikavälillä palvelukohtaisesti. Organisaatio maksaa vain käyttämistään resursseista.	Palvelukohtaiset kustannustiedot kokonaiskustannusten oikealle jyvittämiselle: Käyttötiedot mahdollistavat kustannusten jyvittämisen, mutta jyvitettävää kokonaiskustannustasoa ei pystytä alentamaan nopeasti. Tällä kuitenkin varmistetaan kustannusten oikeudenmukainen kohdentaminen.

Optimointistrategiat

Julkipilven ja omien konesalien data-alustojen optimointimahdollisuuksissa on paljon samankaltaisuuksia, joskin omassa konesalissa työkuormien konsolidointimahdollisuudet ovat monipuolisempia ja kustannustehokkuuden osalta voidaan saavuttaa tyypillisesti huomattavasti suurempia parannuksia kuin julkipilvissä.

Julkipilvi	Oma konesali
Työkuormien optimointi (Right-Sizing) ja konsolidointi: Työkuormia voidaan konsolidoida  tietokanta- tai tietokantainstanssitasolla isompiin julkipilven hallinnoituihin instansseihin (Managed Instance) tai palvelimiin laitteistojen käytön optimoimiseksi. Lisäksi voidaan optimoida  virtuaalikoneiden ja tallennustasojen (storage tier) kokoa käyttötapausten perusteella kustannusten säästämiseksi.	Työkuormien optimointi (Right-Sizing) ja konsolidointi: Työkuormia voidaan konsolidoida  tietokanta-, tietokantainstanssi- ja  virtuaalikonetasolla isompiin palvelimiin laitteiston käytön optimoimiseksi Lisäksi voidaan optimoida  virtuaalikoneiden kokoa käyttötapausten perusteella kustannusten säästämiseksi.
Varatut instanssit (reserved instance) ja säästösuunnitelmat: julkipilvissä on mahdollisuus edullisimpiin hintoihin, jos on valmis sitoutumaan tiettyyn määrään resursseja.Tällöin joudutaan tekemään kompromissi julkipilven täysin kulutukseen perustuvan laskutuksen osalta.	Elinkaaren hallinta: Konsolidoimalla ja optimoimalla työkuormia voidaan varmistaa, että käytössä olevat laitteistot tuottavat optimaalisen hyödyn. Vanhentuneet ja rajallisen lisähyödyn tuottavat vanhemmat investoinnit voidaan korvata kokonaistaloudellisimmilla ratkaisuilla. Vaihtoehtoina on myös laitteistojen elinkaaren jatkaminen.
Dynaaminen resurssien skaalaus: Julkipilvissä on mahdollisuus automaattiseen resurssien skaalaamiseen käytön tarpeiden mukaan.	Työkuorman ajoitus: Tämä optimoi kuormituksen suorittamisen ajoitus virta- ja jäähdytyskustannusten vähentämiseksi. Ajoittamalla työkuormien suorittamista voidaan varmistaa resurssien tehokas käyttö ja myös leikata kuormituspiikkejä. Tällä eliminoidaan muun muassa liialliset investoinnit sekä turha sähkön ja jäähdytyksen käyttö.

Automaatio

Julkipilvissä automaatio on sisäänrakennettu, kun taas omissa konesaleissa se joudutaan rakentamaan erillisten automaatioratkaisuiden avulla. Molemmissa pystytään saavuttamaan erittäin korkea automaatioaste, mutta keinot ja tavat sen toteuttamiseen ovat erilaisia.

Julkipilvi	Oma konesali
Laajat automaatiovaihtoehdot: Mahdollisuus käyttää  serverless-teknologiaa, skriptejä ja orkestrointityökaluja dynaamiseen skaalaukseen ja resurssien hallintaan	Manuaalinen malli tai rajoitettu automaatio: Automaatio voi vaatia merkittäviä investointeja orkestrointityökaluihin (esim Ansible, Puppet tai Kubernetes, PowerShell, Dbatools)
Infrastruktuuri koodina (IaC): Palveluiden käyttöönotto ja skaalaaminen voidaan automatisoida IaC työkaluilla (esim. Terraform, Bicep).	Laitteistokohtaiset kokoonpanot: Omissa konesaleissa saattaa olla hyvinkin erilaisia laitteistokokonaisuuksia, joita ei ole suunniteltu toimimaan isona yhteisenä resurssivarantona. Virtualisointi auttaa, mutta silti laitteistokohtaiset ominaisuudet vaikuttavat optimointiin ja konsolidointiin.  SQL Governor-tyyppisissä ohjelmistoissa on erilaisia ominaisuuksia, jotka helpottavat merkittävästi erilaisten kokoonpanojen vertailua ja skenariointia kapasiteettitarpeiden ja suorituskykyvaatimusten osalta.

Taloudellinen joustavuus

Julkipilvi on taloudellisesti joustavampi malli kuin oma konesali. Niin julkipilvelle kuin omalle konesalille on omat perustellut paikkansa, mutta niiden roolien optiointi vaatii syvällisempää ymmärrystä ja laskentaa. Kategorinen kannanotto toisen edullisuudesta tai kalleudesta ei kestä tarkempaa analyysiä.

Julkipilvi	Oma konesali
Korkea taloudellinen joustavuus: Kaikki kulut ovat toimintakuluja (OPEX) ja organisaatiot voivat välttää pääoma- ja investointikustannuksia.	Korkeat pääomakustannukset (CAPEX): Vaatii pääomasijoituksia ja investointeja etukäteen ja tämä voi  vaikeuttaa sopeutumista muuttuviin taloudellisiin olosuhteisiin ja markkinamuutoksiin.
Ylikuormitus(Burst)kapasiteetti ja laajentumiskyvykkyys: Julkipilvi pystyy vastaamaanhelposti lyhytaikaisiin jaodottamattomiin työkuormiin ilman suuria investointeja.	Kapasiteettirajoitettu: Purskeiden hallinta vaatii yliprovisiointia tai ylimääräisen kapasiteetin vuokraamista, jotka molemmat ovat tyypillisesti kokonaistaloudellisesti kalliita vaihtoehtoja

Governance ja vaatimustenmukaisuus

Governancen ja vaatimustenmukaisuuden (säädökset ja standardit) suhteen julkipilvi on selkeästi vahvempi ja kustannustehokkaampi vaihtoehto kuin oma konesali. Tämä näkyy eritoten vahvasti reguloiduissa ympäristöissä. Julkipilvien osalta on hyvä pohtia oman data-alustan ja datan sijaintia. Monet julkipilvet saattavat mahdollistaa pääsyn dataan globaalisti ja datan sijainnin rajaaminen aukottomasti voi olla vaikeaa, tai jopa mahdotonta.

Julkipilvi	Oma konesali
Käytäntöjen täytäntöönpano: Esimerkiksi työkalut, kuten Azure Policy tai AWS Config, pakottavat käytön ja kustannusten hallinnan eri käyttäjätileille, joka osaltaan lisää hallinnon läpinäkyvyyttä.	Mukautettujen käytäntöjen tarve: Hyvän hallinnon (Governance)-vaatimukset  on toteutettava tyypillisesti kolmannen osapuolen työkaluilla.
Sisäänrakennettu tietoturva ja vaatimustenmukaisuus: Julkipilvet tarjoavat maailmanlaajuisten standardien (esim. GDPR, HIPAA) noudattamisen.	Mukautetut vaatimustenmukaisuustoimenpiteet: Organisaatioiden on varmistettava, että fyysiset ja toiminnalliset vaatimustenmukaisuusvaatimukset täyttyvät.

Tiimien välinen yhteistyö

Julkipilvi	Oma konesali
Tiimien välinen yhteistyö: Talous-, IT- ja erilaiset suunnittelutiimit pääsevat käsiksi itselleen relevanttiin tietoon heille optimoitujen näkymien kautta.	Siiloutuneet toiminnot: Yhteistyö eri toimintojen välillä voi olla vähemmän integroitua ja näkyä hitaampana toimintana. Uusien palveluiden käyttöönotto voi olla hidasta ja jopa häiritä liiketoimintaa. Konesaliautomaation avulla voidaan toteuttaa julkipilvimäistä automaatiota, mutta se tarkoittaa lisäinvestointeja.
Itsepalvelun hyödyntäminen: Käyttäjät voivat valmistella ja hallita tarvitsemiaan resursseja itsepalveluna. Automaation avulla pystytään eliminoimaan selkeitä käyttäjävirheitä.	Keskitetty hallinta: Tyypillisesti IT hallitsee resurssien valmisteluja, mikä voi johtaa mahdollisiin pullonkauloihin ja hitauteen palveluiden käyttöönotossa.

Loppusanat

Julkipilven ja oman datakeskuksen eroja voidaan tiivistetysti kuvata oheisella taulukolla:

Vaikka molemmat ympäristöt hyötyvät FinOps-käytännöistä, julkinen pilvi korostaa joustavuutta, läpinäkyvyyttä ja dynaamista kustannusten hallintaa, kun taas omat konesalit keskittyvät kiinteiden kustannusten optimointiin, resurssien käyttöön ja kapasiteetin suunnitteluun. Toteutusstrategiat ja -välineet eroavat toisistaan merkittävästi taustalla olevien arkkitehtuuri- ja rahoituserojen vuoksi.

Optimaaliset ratkaisut löytyvät usein näiden kahden maailman välimaastosta, niinsanotusta hybridiratkaisuista. Molemmille on paikkansa ja kustannustehokkaimman ratkaisun löytäminen vaatii molempien perinpohjaista tuntemista ja parhaiden puolien hyödyntämistä.

Julkipilvien positiiviset käyttäjäkokemukset ovat motivoineet omien konesalien ratkaisutoimittajia keskittymään pilvimäisen käyttäjäkokemuksen kehittämiseen. On hyvä muistaa, että pilvi ei ole paikka vaan toimintatapa. DB Pro:n SQL Governor -ratkaisun avulla näet sekä omien konesaliesi että julkipilven tilan ja voit tehdä tehokkaita FinOps-päätöksiä hallitusti ja keskitetysti data-alustasi suorituskykyyn ja kapasiteettioptimointiin liittyen. Voit lukea SQL Governorin ominaisuuksista tarkemmin lisää täältä: www.sqlgovernor.com

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

Finops organisaation johtamiskäytäntönä sopii aivan yhtä hyvin omien konesalien kuin julkipilvien kustannusten johtamiseen. Tällöin kuitenkin käytettävät metodologiat eriävät jonkin verran toisistaan, paikoin paljonkin. Onkin hyvä tunnistaa nämä lainalaisuudet, jotta voidaan kunnolla arvioida privaattipilven, julkipilven sekä mahdollisten hybridiratkaisuiden  investointi- ja elinkaarikustannuksia. Blogisarjassani käsittelen aihetta liiketoiminnan näkökulmasta kolmikantaisesti:

• Kipupiste
• Ratkaisu
• Tulos

FinOpsin soveltaminen omissa konesaleissa (private cloud, privaattipilvi)

FinOpsin johtamisen periaatteita voidaan hyödyntää omissa konesaleissa, vaikka lähestymistapa ja työkalut eroavatkin jonkin verran julkipilvestä. Vaikka FinOps on perinteisesti liitetty pilvialustoihin, sen kolmea perusperiaatetta voidaan soveltaa  organisaation omiin konesaleihin:

• Eri osapuolten taloudellinen vastuu
• Kustannusten optimointi
• Arvon tuottaminen

Käytön ja kustannusten näkyvyys

Kipupiste: Omien konesalien operatiivisten kulujen jyvittäminen palveluita käyttäville yksiköille ei ole välttämättä kovin tarkkaa ja oikeudenmukaista.

Ratkaisu: Konesalien data-alustojen älykäs ja reaaliaikainen käytönseuranta käyttäjittäin sekä huomioiden kaikki muuttuvat kulut (muun muassa prosessorin, muistin, verkkojen ja tallennuskapasiteetin käytön) antaa hyvän lähtökohdan kustannusten todelliselle kohdentamiselle.

Tulos: Organisaatio pystyy kohdentamaan data-alustojen konesalikulut oikeille käyttäjille ja liiketoiminnoille.

Kustannusten allokointi

Kipupiste: Konesaleissa monet käyttäjittäin ja liiketoiminnoittain jyvitettävissä olevat kulut allokoidaan kuitenkin kiinteillä jakosuhteilla. Tämä voi johtaa vääristyneisiin kannattavuus- ja kilpailukykylaskelmiin ja aiheuttaa merkittäviä haittoja esimerkiksi vertailtaessa vaihtoehtoisia tapoja tuottaa tarvittavia palveluita tai edelleen liiketoimintoja myytäessä johtaa tuotantokustannusten vääriin analyyseihin.

Ratkaisu: Chargeback-ja showback-toimintamallilla organisaatio pystyy allokoimaan kaikki data-alustoihin liittyvät kulut oikeudenmukaisesti ja läpinäkyvästi oikeille käyttäjille ja liiketoiminnoille.  Chargeback -toiminnallisuus kohdentaa kulut oikeille tahoille ja laskuttaa niiden mukaisesti, kun taas showback -toiminnallisuus jyvittää kulut mutta ei laskuta niitä. Organisaation sisäiset käytännöt ohjaavat sopivan käytännön käyttämiseen.

Tulos: Data-alustojen kulut kohdentuvat oikein niitä käyttävien tahojen suhteen ja organisaation eri tahot saavat todenmukaisen jyvityksen käyttämistään palveluista. Tämä on hyvä tapa kannustaa eri tiimejä optimoimaan resurssien käyttöä. Organisaatioden kilpailukyvyn ja kustannustehokkuuden kannalta on olennaista, että kaikki kustannukset on jyvitetty totuudenmukaisesti, koska se on tehokkain keino löytää tehostamiskohteita. Jos kustannukset jaetaan kiinteällä jakosuhteella, tehottomat ja kalliit yksityiskohdat piiloutuvat tasapaksuun harmaaseen.

Resurssien käytön optimointi ja kapasiteettisuunnittelu

Kipupiste: Yksi merkittävä ero omien konesalien ja julkipilvien välillä on resurssien joustavuus. Omat konesalit ovat tyypillisesti paljon pienempiä ja suunniteltu ennakoitavien työkuormien, kasvun ja riskimarginaalin mukaan. Konesalien elinkaari on tyypillisesti plus miinus viisi vuotta ja sen syklin sisällä tehtävät merkittävät muutokset ovat tyypillisesti kalliita ja niitä halutaan välttää.

Konesalit vaativat etukäteisinvestointeja, mikä tekee skaalautuvuudesta merkittävän huolenaiheen. Omat konesalit usein yliallokoidaan  ja hankittuja resursseja jää hyödyntämättä staattisen etukäteen tehtävän kapasiteettisuunnittelun vuoksi. Resessiivistä yliallokointia syntyy helposti jopa 50% epätarkasti määritelttyjen turvamarginaalien johdosta, aliallokointia paljon harvemmin.

Monet konesalien resursseihin liittyvät investoinnit ovat merkittävästi edullisemmin toteutettavissa elinkaaren alussa kuin kesken sitä. Tämä on yksi merkittävä syy yliallokoinnille.

Vaikka suunnittelu olisi tehty oikein nykyisen toiminnan kannalta, saattaa liiketoiminnassa tapahtua muutoksia, jotka johtavat yli- tai aliallokointeihin. Yritys- ja liiketoimintakaupat, erilaiset yhdistymiset ja viimeisimpänä tekoälyn mukana tuomat teknologiset ja kapasiteettivaatimukset ovat hyvä esimerkkejä.

Ratkaisu: Tulevaisuuden ennustaminen on vaikeaa, mutta sen luotettavuutta voi parantaa ymmärtämällä historiaa ja nykytilaa sekä teknologian ja liiketoiminnan kehitystä. Kun nämä elementit ovat samassa yhtälössä, optimaalinen kapasiteettisuunnittelu ja resurssien hyödyntäminen ovat saavutettavissa.

Mitoituksessa ja suunnittelussa on syytä käyttää sellaisia työkaluja ja käytäntöjä,  jotka huomioivat  data-alustojen kausiluonteisuudet, trendit, käyttökatkot, palveluajat, sekä liiketoimintojen vaatimukset, kuten skaalautuvuustarpeet, tietokantojen kriittisyysasteet ja vaaditut palvelutasot.

Tulos: Organisaation kannalta kriittisintä on varmistaa liiketoiminnan jatkuvuus. Yhtä tärkeää kuin varmistaa data-alustojen mitoitus alussa, on pitää ne optimaalisena koko elinkaaren ajan. Tällä varmistetaan paras mahdollinen kustannustehokkuus kriittisten palveluiden osalta.

Organisaation data-alustojen työkuormat ovat jatkuvassa käymistilassa, ja sen takia niitä on syytä pitää silmällä ei pelkästään palvelun laadun, vaan myös kustannustehokkuuden takia. Työkuormien oikeinmitoituksen, virtualisoinnin, kontituksen ja konsolidoinnin avulla varmistetaan optimaalinen kustannustehokkuus. Kun organisaatio on kyvykäs seuraamaan ja ennustamaan data-alustojen käytön kehittymistä, se pystyy myös optimoimaan tulevat hankinnat ja korvausinvestoinnit niin määrällisesti kuin aikataulullisesti.

Automaatio

Kipupiste: Data-alustoihin liittyvät konesalipalvelut ovat niinsanotusti resurssisyöppöjä. Data-alustat kuluttavat konesalien energiasta keskimäärin kolmanneksen ja datan määrän voimakkaasti kasvaessa, niihin tarvittava energia ja muut resurssit jatkavat kasvuaan. Tässä yhtälössä pienetkin kivet on hyvä kääntää, kun haetaan kokonaistaloudellisia ratkaisuja organisaatioiden palveluiden tuottamiselle.

Kustannustehokkuuden, laadun ja suorituskyvyn optimointi manuaalisesti on melkoinen, käytännössä mahdoton tehtävä. Henkilökustannukset nousevat tässä vaihtoehdossa liian suuriksi ja virheiden riski kasvaa.

Ratkaisu: Kun puhutaan data-alustojen analysoinnista ja optimoinnista, analysoitavia datapisteitä ja tekijöitä on niin paljon, että ainoa keino selvitä niistä on pitkälle viety automaatio. Automaatio itsessään ei tuota ratkaisua, vaan tarvitaan paljon tietoa palveluiden ja data-alustan käyttäytymisestä historiassa, nykyhetkessä ja haastavimpana kaikesta, kyvykkyyttä ennustaa tulevaisuutta. Kaiken tämän apuna toimii kokeneiden asiantuntijoiden henkilökohtainen osaaminen, teko- ja tukiäly sekä ennustavat analytiikkamallit, jotka analysoivat työmääriä ennakoivasti (pre-migration) sekä tarveperusteisesti (post-migration) .

Tulos: Automaation soveltaminen auttaa organisaatiota kääntämään jokaisen kiven kustannusoptimointihaasteessaan. Kapasiteetin suunnittelu oikean tiedon varassa automaation avulla auttaa organisaatiota minimoimaan investoinnit palvelun laadusta tinkimättä. Data-alusta elää ja muuttuu liiketoiminnan tarpeiden mukaan ja automaattinen resurssien allokointi kustannusoptimoidulla tavalla voi tuoda merkittäviä säästöjä. Vielä pidemmälle viedyt ratkaisut optimoivat myös organisaation työkuormien ajoitusta hyödyntämällä resurssien käytön syklisyyttä. Jokainen matala sykli on hukkaa ja korkea sykli on potentiaalinen palvelutasoriski – ja pahimmillaan uuden investoinnin sytyke.

Governance, yhteiset käytännöt ja yhteistyö

Kipupiste:  Omien konesalien data-alustojen liiketoiminnoille tuottamien palveluiden todelliset kustannukset, optimointimahdollisuudet ja säästö- sekä parannuspotentiaali jäävät usein tiedostamatta, koska niitä ei pystytä jyvittämään riittävän yksityiskohtaiselle tasolle.

Ratkaisu: Ollakseen kyvykäs maksimoimaan kustannustehokkuuttaan ja kilpailukykyään, organisaation on hyödyllistä laatia yhteiset käytännöt konesalien, eri palveluyksiköiden ja liiketoiminnan tiimien kesken. Käytäntöjen pitäisi sisältää ainakin tiedonvaihdon malleja eri tiimien välillä, tulevaisuuden ideoita ja tarpeita ja rohkaisua kompromissien hakemiseen, koska esimerkiksi niin kustannussäästöjen maksimoiminen kuin maksimaalinen nopeus vastata liiketoiminnan tarpeisiin voi johtaa kokonaiskuvassa ääripääratkaisuihin ja sitä kautta epäedullisiin lopputuloksiin. Kompromissi löytyy jostain noiden kahden ääripään väliltä.

Tulos: Organisaatio pystyy analysoimaan kaikkien data-alustoja hyödyntävien palveluiden oikeat kustannukset, optimointimahdollisuudet ja kustannussäästöpotentiaalit ja kohdentamaan kustannukset oikeille liiketoiminnoille, optimoimaan resurssit parhaan mahdollisen hyödyn saamiseksi ja toteuttamaan optimaaliset säästöt data-alustojen osalta.

Loppusanat

SQL Governor on markkinoiden ainoa työkalu, joka yhdistää niin omien konesalien kuin julkipilven kustannusjohtamisen (FinOps) yhdeksi hallituksi kokonaisuudeksi mahdollistaen suorituskyky-, kapasiteetti- ja laatuoptimoinnin samassa paketissa. Tekoälyä hyödyntävällä ohjelmistollamme on useita kansainvälisiä patentteja ennustavaan kapasiteettisuunnitteluun liittyen. Työkalun avulla voidaan automatisoida sekä tehostaa merkittävästi Microsoft-pohjaisten data-alustojen kustannusoptimointia. Tätä blogia kirjoittaessani olemme palvelleet lukuisten toimialojen keskisuuria sekä suuryrityksiä jo 12 maassa. Kiinnostuitko? Lue lisää täältä: www.sqlgovernor.com

Tämän blogin tarkoituksena on lisätä yleisesti tietoutta siitä, kuinka tietokantakeskeinen ohjelmistokehitys on välttämätöntä enterprise-tason järjestelmähankkeiden onnistumisen kannalta ja etenkin silloin, kun puhutaan big datasta. Blogissani otan kantaa lähinnä on-premises-ratkaisuihin, koska Microsoft Azure asettaa vielä tätä blogia kirjoittaessani tiettyjä rajoituksia ja reunaehtoja massiivisille SQL Server-pohjaisille tietokantaratkaisuille.

Usein tietokannan roolia vähätellään ohjelmistokehityksessä, vaikka se onkin miltei poikkeuksetta tärkein yksittäinen seikka tietojärjestelmän suorituskykyyn ja skaalautumiseen liittyen. SQL Server-tietokannat ovat monimutkaisia kokonaisuuksia, ja niihin kytkeytyy monenlaista skaalautumiseen, performanssiin ja saatavuuteen liittyvää osaamista. Hyvin harvoin kaikki nämä osa-alueet ovat yksittäisen tietokantaosaajan hallussa. Sen sijaan, mittavissa tietokantakeskeisissä ohjelmistokehityshankkeissa onkin varsin tavanomaista, että tietokanta-osaajia on useampi, kukin erikoistunut omalle osa-alueelleen:

• Data-arkkitehti (palvelininfrastruktuuri, virtualisointi, data-arkkitehtuuri, korkea käytettävyys, DR-suunnittelu, käyttäjät ja tietoturva)
• Tietomallintaja (ylätason käsitemallit ja tietokantamallinnus, indeksointi)
• Tietokantaohjelmoija (tietokantakyselyt ja optimointi, kuten indeksit ja konfiguraatiot)
• Datainsinööri (tietokantaintegraatiot, ETL ja ELT)
• DBA (tietokantarutiinit ja ylläpito)

SQL Server-tietokannan kokoluokan kasvaessa suurimpien käyttäjätaulujen osalta kymmeniin miljooniin riveihin, usein jopa kymmeniin miljardeihin riveihin tai enemmän, tietokanta ei enää skaalaa perinteisillä menetelmillä. Tällöin voidaan jo puhua big datasta SQL Serverin piirissä: Perinteiset keinot eivät enää riitä. Tämä tarkoittaa reaaliaikaisissa, operatiivisissa OLTP-kannoissa toistuvaa hidastuvuutta ja turhia käyttökatkoja, joskus jopa järjestelmän totaalista sakkaamista toimintakelvottomaksi, sekä tietovarastoissa liian pitkiä latausaikoja ja raporttien hidastumista, ym. konkreettista haittaa ja riskiä liiketoiminnalle. Tämän takia onkin ensiarvoisen tärkeää tunnistaa ne osa-alueet, joiden avulla tietokantaratkaisua voidaan systemaattisesti skaalata satoja, jopa tuhansia kertoja enemmän, kuin perus tietokantakehityksellä. Relaatiotietokantojen skaalaaminen jakaantuu erilaisiin osa-alueisiin. Näistä keskeisimpiä best practiceiden mukaisen data-arkkitehtuurin lisäksi ovat:

• Hyvä tietokantasuunnittelu
• Indeksointi ja statistiikka
• Partitiointi
• Materialisoidut näkymät ja Stored proseduret
• Tietokantakyselyiden optimointi
• Tietokantakonfiguraatiot
• Tietokantojen replikointi
• Vertikaalinen skaalaus (“rautaa rajalle”)
• In-Memory OLTP
• Caching
• Sharding (työläs, ei natiivi SQL Serverissä)
• Kapasiteettilähtöinen suunnittelu ja ennakointi

Jokaisesta näistä osa-alueesta olisi oikeutettua kirjoittaa oma bloginsa, mutta lähdetään nyt liikkeelle kuitenkin siitä, että kerron näistä osa-alueista lähinnä konseptuaalisesti sekä muutamia keskeisiä käytännön seikkoja.

Hyvä tietokantasuunnittelu

Hyvän tietokantasuunnittelun perusperiaatteena voidaan pitää sitä, että tietokanta normalisoidaan käyttötarkoituksensa mukaan. Esimerkiksi OLTP-tietokantaa suunniteltaessa tulee aina suunnitella tietokanta vähintään kolmanteen normaalimuotoon (3NF), jotta se suoriutuu runsaista pistemäisistä luku- ja kirjoitusoperaatioista mahdollisimman rivakasti. Vastaavasti tietovarastokannoissa on tyypillistä optimoida skeema ottamaan hyvin vastaan datamassoja suurina eräajoina ja raportoimaan massiivisia datamääriä tehokkaasti. Tämä taas vaatii tietokantaskeeman denormalisointia (2NF). Lue lisää tästä aiheesta varsin kattavasta blogisarjastani: Tietomallinnus – Osa 1: Intro – DB Pro Services

Indeksointi

Tehokas tietokanta elää ja hengittää indekseistä. Tämä on aivan oma taiteenlajinsa. Liikaa indeksejä ja päivitykset alkavat hidastua, liian vähän ja epäoptimaalisia indeksejä niin tietokantakyselyt alkavat hidastua. Väärät täyttöasteet fragmentoivat indeksejä syöden niiden tehokkuutta ja vanhentuneet indeksistatistiikat johtavat SQL Server kyselyoptimoijaa harhaan antaen epäoptimaalisia suoritussuunnitelmia. Hyvin suunniteltu indeksi taasen voi nopeuttaa hidasta tietokantakyselyä helposti jopa 1000-kertaisesti ja balansoidusti suunnitellut indeksit pitävät myös operatiiviset tietokantataulut suorituskykyisinä kaikissa tilanteissa. Kehittyneet indeksien ja statistiikan ylläpitorutiinit kuten DB Pro Servicen kehittämä ISM-komponentti turvaavat indeksien ja statistiikan suorituskyvyn myös silloin, kun niitä on enemmän kuin niitä ehtii päivittää ja datamäärät kasvavat teratavuihin tai enemmän. Indeksien tehokäyttöön liittyvät myös joskus Query Storen tehokas käyttö ja optimaalisten kyselyplänien tai indeksien eksplisiittinen pakottaminen silloin, kun Query Engine ei tähän pysty. Joskus joudutaan myös turvautumaan Legacy Cardinality Estimatorin käyttöön. Indeksointi lisää luonnollisesti myös levytilan tarvetta, useimmiten useita kymmeniä prosentteja.

Partitiointi

Partitioinnin ideana on pilkkoa SQL Serverin tietokantataulu vertikaalisesti siten, että se jaetaan useaan “alitauluun”, eli ns. partitioon. Partitiot ovat omia fyysisiä kokonaisuuksiaan, mutta muodostavat loogisesti ja eksplisiittisesti eheän kokonaisuuden, johon voi viitata aivan kuten muihinkin tietokantatauluihin. Partitioon liittyy looginen partitioavain, jonka perusteella kukin partitio eli n.s ”alitaulu” muodostuu. Partitioavaimessa voidaan viitata vaikkapa päivämäärään, jolloin partitioita syntyy yhtä monta kuin on päivämääriä taulussa kaikkiaan. Yleisesti nyrkkisääntönä on, että ~30 miljoonan rivin kokoinen tai sitä suurempi tietokantataulu kannattaa jo partitioida, koska tällöin taulun suorituskyky alkaa selvästi kärsiä. Partitioinnin suurimmat hyödyt ovat, että tietokantataulun suorituskyky säilyy riippumatta juurikaan taulun rivimäärästä, vaikka siellä olisi satoja miljardeja rivejä dataa. Toki tietokantakyselyn täytyy tuolloin kohdistua aina partitioavaimeen, jotta vältytään koko taulun skannaukselta ja sen sijaan haetaan data suoraan partitiosta. Toinen keskeinen partitioinnin hyödyistä on, että voidaan deletoida kokonaisia partitioita, vaikkapa à100M riviä, millisekunneissa sen sijaan, että deletointi kuormittaisi lokikantaa ja kestäisi rivi kerrallaan useita tunteja tai jopa päiviä, hidastaen radikaalisti koko tietokantaa. Kolmas hyöty on ns. ”partition switch”, jolla voidaan nopeuttaa esimerkiksi jatkuvasti muuttuvaa big dataa, kuten kuukausitason ETL-latauksia DW-kantaan vaikkapa tuoreimpien 3 kuukauden ajalta siten, että ladataan vastaavalla partitioinnilla implementoituun staging-tauluun ensin muuttunut data, ja sitten tehdään nopea ”partition switch” kuukausitason partitioihin, joka päivittää staging-taulun partitiot isoon historiatauluun. Operaatio tapahtuu yleensä millisekuinneissa, koska koko partitio ”istutetaan” kertaoperaationa kohdetauluun.

Materialisoidut näkymät ja stored proceduret

Materialisoidut näkymät, joita SQL Serverissä kutsutaan indeksoiduiksi näkymiksi, tarjoavat useita etuja, jotka voivat parantaa merkittävästi tietokannan suorituskykyä ja käytettävyyttä. Nopeampi tietokantakyselyn suorittaminen johtuu siitä, että  indeksoidut näkymät tallentavat kyselyn esilasketut tulokset, mikä lyhentää monimutkaisten tai resursseja vaativien kyselyjen suorittamiseen kuluvaa aikaa. Tämän lisäksi koska tulokset on esilaskettu ja tallennettu, järjestelmän ei tarvitse toistuvasti käyttää ja koota tietoja pohjana olevista taulukoista, mikä vähentää työmäärää. Näkymiin voi myös luoda omia indeksejä, mikä voi tehostaa kyselyitä entisestään. Vähentämällä järjestelmän laskennallista kuormitusta indeksoidut näkymät auttavat tietokantaa käsittelemään enemmän samanaikaisia käyttäjiä ja kyselyitä, mikä parantaa skaalautuvuutta. Myös kyselyt ovat yksinkertaisempia, koska indeksoidut näkymät voivat sisältää taulujen joinausta sekä aggregointia. Myös SQL Serverin Query Optimizer osaa hyödyntää tehokkaasti indeksoituja näkymiä. Vaikka indeksoidut näkymät ovatkin omiaan vähentämään esim. levy IO:ta, niiden haittapuolina mainittakoon ekstra levytila sekä kasvava kirjoituslatenssi (tietojen propagointi käyttäjätauluista näkymiin).

Stored proceduret ovat oiva tapa skaalata SQL Server -tietokannan suorituskykyä. Kun kapseloidaan useita T-SQL statementteja samaan batchiin proseduurin sisälle ja pitkien kyselyiden sijaan lähetetään pelkät parametrit osana proseduurikutsua, syntyy paljon vähemmän verkkoliikennettä clienttien ja serverin välille. Edelleen, SQL Server kääntää ja tallentaa stored proceruden suoritussuunnitelman muistiin sen ensimmäisen suorituksen yhteydessä. Seuraavat proseduurikutsut käyttävät suunnitelmaa uudelleen välttäen kyselyn parsimisen ja optimoinnin overheadia. Stored proceduret ovat myös vähemmän alttiita toistuvalle uudelleenkääntämiselle (recompilation) kuin ad hoc -kyselyt, varsinkin jos niissä käytetään parametreja. Keskittämällä logiikan tietokantaan stored proceduret vähentävät riippuvuutta client-sovellusten käsittelystä, mikä mahdollistaa paremman skaalautuvuuden korkean samanaikaisuuden OLTP-järjestelmissä. Stored proceduret myös vähentävät sovelluspalvelimien laskennallista kuormitusta suorittamalla raskasta tietojenkäsittelyä tietokannassa. Transaktionaalisuus voidaan myös kätevästi kapseloida osaksi stored proseduurien logiikkaa, jolloin tietokanta toimii mahdollisimman tehokkaasti.

Tietokantakyselyiden optimointi

Tietokantakyselyitä optimoimalla, samoin kuin tehokkaalla indeksoinnillakin, voidaan saavuttaa merkittäviä suorituskykyhyötyjä, käytännössä miltei yhtä merkittäviä kuin indeksoinnillakin. Esimerkiksi, huonosti tehty tietokantakysely ei osaa käyttää tietokantatauluun luotuja indeksejä, jolloin suoritussuunnitelma romahtaa. Tietokantaoptimointia tehtäessä tulee ymmärtää hyvin indeksien ja statistiikan taikutus, erilaisten muistinvaraisten ja persistoitujen taulurakenteiden, kursoreiden, operaattoreiden, joinien ja funktioiden vaikutus suorituskykyyn jne jne. Myös SQL Serverin versiolla on iso merkitys tässä asiassa. Tietokantakyselyiden optimoinnissa pääsee vauhtiin jo muutamassa päivässä, mutta tämän osa-alueen suvereeniin hallitsemiseen menee vuosia. Hyvän esimerkin tietokantaoptimoinnista löydät tuotesivuiltamme, liittyen komposiitti-indeksien käyttöön moniehtoisissa kyselyissä: SQL Server performance insights – OR vs UNION ALL is not always what it seems

Tietokantakonfiguraatiot

Käyttöjärjestelmätasontason asetukset, kuten power plan ja instanssitason konfiguraatiot, kuten max degree of parallelism ja cost threshold for parallelism sekä tietyt tietokanta-asetukset, kuten tempdb:n datatiedostojen konfigurointi, käyttäjätietokantojen filegroup- sekä datafileasetukset sekä tietyt tietokantaoptiot kuten statistiikkojen päivityssäännöt voivat kaikkiaan vaikuttaa yhdessä ja oikein konfiguroituina OLTP-tietokantapalvelimen suorituskykyyn helposti useita kymmeniä prosentteja, joskus jopa enemmän.

Tietokantojen replikointi

Tietokantojen replikointia voidaan harrastaa SQL Serverissä esimerkiksi log shipping-mekanismilla tietyissä rajoissa, sekä joustavammin ja reaaliaikaisesti Always On availability group -menetelmällä, joka on perinteisestä SQL Server -klusteroinnista pidemmälle kehitetty, tietokantatason HA-ratkaisu. Replikoinnin ideana on, että voidaan ns. ”ulos-skaalata”  operatiivista OLTP-työkuormaa, ja lukea dataa readable replikasta, joka on sijoitettu eri palvelimelle. Tällöin esimerkiksi ad hoc-raportointikuormat eivät rasita lainkaan operatiivista palvelinta. Edelleen; data engineerit voivat ladata operatiivisista kannoista eräajoina uusia datageneraatioita erilliselle tietovarastopalvelimelle ns. raportointikantaan eli datamarttiin, jolloin raportointi saadaan optimoitua sekä tietokantaskeeman että -kuorman kannalta optimaaliseksi.

Lue lisää log shippingistä täältä: Mitä tehdä SQL Server Log Shipping -ominaisuudella? – DB Pro Services.

Vertikaalinen skaalaus

Vertikaalisen skaalauksen idea on yksinkertainen: Jos tietokantapalvelimen muisti loppuu, lisää muistia. Jos prosessoriteho loppuu, lisää CPU:ta. Jos storage yskii, ota tiukempi tier tai dedikoitu storage käyttöön. Tässä on kuitenkin yksi ongelma: Tällöin hoidetaan ”oiretta, ei sairautta”, joka usein johtaa paisuvaan, hallitsemattomaan TCO:hon sekä huomattavasti järeämpiin SQL Server-lisenssikustannuksiin. SQL Server käyttää syystä eri resursseja paljon, ja jos telemetriikkaa devioi ns. baselinestä, on syytä olettaa, että jokin SQL Serverin syövereissä ei toimi tehokkaasti. Syypäänä on usein jokin asetus, indeksi, tietokantakysely tai tai muu vastaava. On paljon tehokkaampaa hoitaa kuntoon alkusyy kuin oire, ja usein tähän ”parantamiseen” riittää kokenut DBA. Joskus on kuitenkin aiheellista lisätä fyysistä kapasiteettia. Tämä on täysin normaalia, mutta sitä ei kannata tyypillisesti tehdä sokeasti, vaan vasta perusteellisen kapasiteetti- ja performanssidiagnostiikan jälkeen.

In-Memory OLTP

Tietokannan sisältöä voi myös nostaa tietokantaplvelininstanssin käyttömuistiin: In-Memory OLTP on SQL Serverin ominaisuus, joka on suunniteltu parantamaan merkittävästi tapahtumakuormitusten suorituskykyä hyödyntämällä muistissa olevia tietorakenteita ja optimoituja käsittelytekniikoita. Tämä SQL Server 2014:ssä esitelty ja myöhemmissä versioissa parannettu tekniikka sallii tiettyjen taulujen ja stored proseduurien sijaita ja suorittaa ne kokonaan muistissa.

Caching

Tallennusjärjestelmän levypintaa voidaan jakaa kylmään ja kuumaan dataan. Tällä tavalla saadaan skaalattua levyjärjestelmän performanssia niillä osa-alueilla, joissa se on oleellista. Relaatiotietokantojen tallennusvälimuistilla tarkoitetaankin välimuistimekanismin käyttöä usein käytettyjen tietojen tallentamiseksi nopeampiin tallennuskerroksiin, kuten muistiin, viiveen vähentämiseksi ja tietokannan suorituskyvyn parantamiseksi. Tallennusvälimuistia hyödyntämällä tietokannat voivat minimoida tarpeen hakea tietoja toistuvasti hitaammasta levypohjaisesta tallennustilasta, mikä parantaa merkittävästi luku- ja kirjoitustehokkuutta.

Sharding

Relaatiotietokannan sharding on tietokanta-arkkitehtuuritekniikka, joka partitioi tietokannan horisontaalisesti tietojen jakamiseksi useisiin tietokantoihin tai palvelimiin, joita kutsutaan shardeiksi. Jokainen shard sisältää avaimineen (=shard key) osan kokonaistiedoista, joiden avulla järjestelmät voivat skaalautua jakamalla kuorman useiden palvelimien kesken, mikä parantaa suorituskykyä, skaalautuvuutta ja vikasietoisuutta.

Huom! SQL Server ei tue shardingia natiivisti sisäänrakennettuna ominaisuutena, mutta sharding voidaan silti toteuttaa SQL Serverin sovellustason logiikan, tietokannan suunnittelutekniikoiden ja kolmannen osapuolen työkalujen tai frameworkkien yhdistelmällä.

SQL Serverin kapasiteettilähtöinen suunnittelu ja ennakointi

Mikäli haluat SQL Server-tietokanta-alustastasi TCO-optimaalisen, sekä sellaisen, että kapasiteetin pullonkaulat ja SLA:ta jyrsivät epäkäytettävyystilanteet eivät kuitenkaan pääse tekemään tuhojaan, on tärkeää mitata ja ennakoida tuotantoympäristön performanssin baselinea ja sen muutoksia jatkuvasti. Tähän erinomainen työkalu on SQL Governor-ohjelmisto, jolla voit ottaa koko data-alustasi performanssioptimoinnin ja kapasiteettioptimoinnin haltuun, riippumatta SQL Server data-alustasi kokoluokasta. Kiinnostuitko? Ole hyvä ja ota yhteyttä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

FinOps, eli Financial Operations on määritelmänsä mukaan ”kehys ja kulttuurikäytäntö, joka keskittyy taloudellisen vastuun tuomiseen pilvimenoihin tavalla, joka tasapainottaa kustannuksia, operatiivista tehokkuutta ja laatua.” FinOpsin avulla monialaiset tiimit, kuten rahoitus, suunnittelu, tuote ja toiminnot, tekevät yhteistyötä hallitakseen pilvikustannuksia tehokkaasti ja maksimoidakseen liiketoiminnan arvon. Käsitteeseen liittyy eräänlaisena sivutuotteena myös vastuullisuusnäkökulma (=sustainability). Huom! FinOpsia voidaan tehdä myös On-premisessä datamigraatioiden yhteydessä.

Datamigraatiot ovat tyypillisesti mittavia, monialaista osaamista vaativia hankkeita, joilla on merkittävä impakti bisnekseen. Datamigraatio on prosessi, jossa valitaan, valmistellaan, poimitaan sekä mahdollisesti muunnetaan tietoja ja siirretään ne pysyvästi dataympäristöstä toiseen. SQL Server-alustojen datamigraatio voi tapahtua useista syistä, kuten palvelinten tai tallennuslaitteiden vaihto, konsolidointi sekä datakeskuksen siirto on-premisestä julkipilveen, kuten Microsoft Azure. Kustannussyyt sekä niiden läpinäkyvyys, tietokannan tarve olla lähellä sovelluksia (pilveen viedyt sovellukset), tietoturva sekä operatiivinen tehokkuus ovat keskeisiä draivereita Azureen mentäessä. Kuitenkin, tietoalustan kustannukset eivät ole aina automaattisesti julkipilvessä edukkaampia kuin on-premisessä, eritoten jos FinOps-osuutta ylenkatsotaan.

SQL Server-datamigraatiot suoritetaan yleensä siten, että ne on mahdollisimman automatisoituja, mikä vapauttaa henkilöresursseja toisteisista rutiineista, ja jotta manuaalisessa toisteisessa työssä helposti tapahtuvia virheitä voitaisiin välttää. Vaikka migraatiot ovatkin usein pitkälle automatisoituja, niitä tulee monitoroida ja migraatioiden onnistumiset tulee aina verifioida huolellisesti: ”What goes out, must come in”.

FinOpsin osa-alueet

FinOps voidaan jakaa viiteen eri osa-alueeseen:

• Näkyvyys ja vastuullisuus
• Kustannusoptimointi
• Operatiivinen tehokkuus
• Tehokkaat tiimit
• Datalähtöinen päätöksenteko

Näkyvyydellä ja vastuullisuudella tarkoitetaan kustannusten reaaliaikaista läpinäkyvyyttä, ennustettavuutta, sekä kontrollia eri sidosryhmien välillä.

Kustannusoptimoinnin tavoitteena on saavuttaa säästöjä ja parempi TCO ilman, että palveluiden suorituskyvystä tai saatavuudesta tingitään. Tähän liittyy mm. sellaisia käsitteitä kuin oikein mitoittaminen (right-sizing), konsolidointi ja tarvelähtöinen dynaaminen skaalaus, mikä on julkipilven, kuten Azure, eräitä etuja.

Operatiivinen tehokkuus tarkoittaa sitä, että kustannusten seuranta on jatkuvaa ja kattavaa siten, että muuttuviin tarpeisiin kyetään reagoimaan nopeasti.

Tehokkaat tiimit tarkoittaa, että datainsinöörit suunnitellessaan sekä jatkokehittäessään data-alustaa ymmärtävät ja hallitsevat arkkitehtuurin ja konfiguraatioiden vaikutuksen data-alustan kustannuksiin. Tämä jakaa osaltaan kokonaiskustannusten vastuuttamista.

Datalähtöinen päätöksenteko FinOpsin avulla perustuu luotettavaan dataan, jonka avulla organisaatiot voivat paremmin ennakoida ja hallita kustannuksiaan.

FinOpsin rooli datamigraatioissa

FinOpsilla on merkittävä rooli datamigraatioissa sekä eritoten organisaatioiden siirtäessä työkuormia ja dataa paikallisista ympäristöistä pilveen. Kun otetaan huomioon pilvimigraatioiden kustannukset, monimutkaisuus ja taloudelliset vaikutukset, FinOps voi tarjota puitteet näiden kustannusten tehokkaalle hallinnalle ja optimoinnille.

FinOps jakaantuu datamigraatioissa seuraaviin osa-alueisiin:

• Migraatiota edeltävä suunnittelu ja kustannusarvio
• Migraation aikainen kustannusoptimointi
• Migraation jälkeinen kapasiteetti- ja kustannusoptimointi
• Hallinto ja vastuullisuus
• Dataohjatut oivallukset ja raportointi

Migraatiota edeltävä suunnittelu ja kustannusarvio

Migraatiota edeltävä suunnittelu ja kustannusarvio jakaantuu seuraaviin alakohtiin:

• SQL Server -performanssidatan monitorointi
• Budjetointi, ennustaminen ja kapasiteettisuunnittelu
• Tavoitteiden (KPI) määrittäminen

SQL Server -performanssidata tulee kerätä kaikilta SQL Servereiltä, instansseilta sekä tietokannoilta, jotta kapasiteettisuunnittelua ja konsolidointia voidaan tehdä kattavasti data-alustan kaikilla tasoilla. Tähän sopivia tuotteita ovat SQL Serverien monitorointiin ja kapasiteettisuunnitteluun erikoistuneet työkalut, kuten SQL Governor, jolla voidaan myös tunnistaa käyttämättömät tietokantaresurssit jo projektin alkuvaiheessa, ettei niitä turhaan siirretä uuteen ympäristöön tuottaen lisäkuluja.

Budjetointi ja ennustaminen tapahtuu parhaiten yhdistäen kokemusperäistä tietoa aiemmista vastaavista migraatioista sekä arvioimalla kapasiteettitarpeet laskemalla eri skenaarioita loogisille osa-alueille, kuten kehitys-, testi- ja tuotantoympäristöt liiketoiminta-alueittain.

Kapasiteettisuunnittelussa voidaan soveltaa seuraavia metodeja palvelinklustereihin, palvelimiin, instansseihin tai liittyen:

• Lift and Shift (siirretään työkuormat uuteen ympäristöön ”as is”)
• Right-sizing eli palvelinten tai Managed instanssien uudelleenmitoittaminen
• Serveritason konsolidointi (optimoidaan hostien kokonaismääärä)
• Instanssitason konsolidointi (optimoidaan hostattujen virtuaalikoneiden, Managed Instance poolien tai fyysisten palvelinten määrää)
• Tietokantatason konsolidointi (harmonisoidaan työkuormat jopa instanssitasolle saakka)

Tavoitteiden määrittämisessa määritelläänbudjetti ja rahalliset KPI:t, joiden puitteissadatamigraation on kokonaisuudessaan toteuduttava ja haluttu ROI saavutetaan.

Migraation aikainen kustannusoptimointi

FinOps-tiimit seuraavat migraatiokustannuksia reaaliaikaisesti, sekä tunnistavat mahdolliset odottamattomat kustannukset tai resurssipiikit pitääkseen menot kurissa. FinOpsin parhaat käytännöt sekä kapasiteettisuunnitteluohjelmistot kuten SQL Governor auttavat sopeuttamaan resurssien käyttöä merkittävästi historiaan pohjautuvien ennusteiden sekä reaaliaikaisten tarpeiden mukaan, välttäen palveluiden ylitarjontaa. Saattaa kuitenkin olla, että esimerkiksi SQL Serverin versionoston myötä, varsinkin jos edellinen versio on jo vanha (2008R2 – 2016), uudella palvelualustalla joudutaan optimoimaan uutta tietokantainstanssia, kuten esimerkiksi säätämään instanssi- ja tietokantatason konfiguraatioita, kuten Max degree of parallelism ja Cost threshold for paralellism -asetuksia. Muut optimoinnit on syytä jättää migraation jälkeiseen aikaan, kun telemetriikkaa ja SQL Serverin käyttöstatistiikkaa on kylliksi kerätty uudesta ympäristöstä. Tosin Query Store on syytä kytkeä päälle heti migraation jälkeen.

Pilvialustoissa on myös mahdollista käyttää erilaisia säästösuunnitelmia ja sitoumuksia pitkäkestoisiin migraatioihin liittyen, jolloin säästöjä saadaan lisää.

Migraation jälkeinen kapasiteetti- ja kustannusoptimointi

Migraation jälkeen FinOps-tiimi varmistaa, että kustannukset kohdistetaan tarkasti eri osastoille tai projekteille, jotta jokainen tiimi ymmärtää omat kulunsa. FinOps-tiimi auttaa myös tunnistamaan mahdollisesti jäljelle jääneet käyttämättömät resurssit, sekä helpottaa niiden poistamista tarpeettomien kustannusten välttämiseksi. FinOps-tiimi pyrkii jatkuvasti optimoimaan resursseja uudessa pilviympäristössä varmistaen, että työkuormat pysyvät kustannustehokkaina ajan mittaan.

Yleensä ensimäisen kerran 1 kokonaisen kuukauden (=bisnessykli) jälkeen migraatiosta, on erinomaisen tärkeää benchmarkata uuden tietokantaympäristön suorituskyky palvelin-, instanssi- ja tietokantatasolla verrattuna vanhaan ympäristöön. Esimerkiksi SQL Governor-tuotteesta löytyy benchmarking-työkalu, jonka KPI:den ja graafien avulla näkee helposti systemin pullonkaulat sekä edistysaskeleet. Mikäli optimointitarpeita ilmenee, voidaan SQL-alustaa optimoida esimerkiksi pakottamalla tietokantainstanssilla paremmin performoivia execution plänejä Query Storesta käsin, tai jopa ottamaan Legacy Cardinality Estimator käyttöön ongelmatietokantojen osalta. Ei ole myöskään tavatonta, etteikö joskus jouduttaisi kirjoittamaan jotakin T-SQL-koodia hieman uusiksikin tai tunkkaamaan indeksointia, mikäli se on sovellustoimittajan puolelta mahdollista. Nämä ongelmat paljastuvat usein vähitellen jo migroiduissa ympäristöissä, joten joitakin näitä toimenpiteitä, eritoten indeksointiin ja koodioptimointiin liittyen, päästään tekemään vasta migraation jälkeen. SQL Governor tarjoaa hyvän työkalukokoelman myös monien näiden ongelmien selvittämiseen.

Hallinta ja vastuullisuus

Migraation aikana FinOps-tiimi voi laatia käytäntöjä, kuten ohjeita hyväksyttävistä menoista, resurssikulutuksesta ja tietojen poistumisrajoituksista, varmistaakseen kustannusten hallinnan. Edelleen; tarjoamalla reaaliaikaisen näkyvyyden migraatiokustannuksiin FinOps antaa suunnittelutiimeille mahdollisuuden tehdä kustannustietoisia valintoja ja olla vastuussa menoistaan.

Dataohjatut oivallukset ja raportointi

FinOps tarjoaa säännöllisiä raportteja ja dashboardeja, joiden avulla sidosryhmät voivat ymmärtää migraatiokustannuksia, seurata edistymistä suhteessa budjettiin sekä varmistaa organisaation taloudellisen tehokkuuden. Esimerkiksi Azuressa laskutuksen telemetriikkatiedot ja ennusteet olemassaolevan konfiguraation osalta on saatavissa ”out of the box”. Tämä yhdistettynä AI-pohjaisen SQL Governor-tuotteemme kykyyn laskea olemassa olevien tietokantojen, instanssien ja virtuaalikoneiden kapasiteettitarve-ennusteita ja konsolidointimahdollisuuksia eri konfiguraatioilla pitkällä aikavälillä saadaan todella tehokas kombinaatio, jonka pohjalta saadaan optimoitua TCO:ta parhaalla mahdollisella tavalla.

Lift and Shift – myrkkyä TCO:lle

Pieni varoituksen sana ”Lift and Shift”:iin liittyen, se kun ei ole pelkkää ruusuilla tanssimista. Mitä suurempi tietokantaympäristö, sitä enemmän asioita menee tämän ajattelumallin myötä vääjäämättä pieleen: Suuri osa tietokannoista ylimitoittuu tai alimitoittuu: Ylimitoittuneet tietokannat eivät performoi tarpeeksi hyvin, ja näin ollen generoivat epäkäytettävyystilanteita sekä piilokustannuksia. Alimitoitetut tietokannat taasen tulevat suotta kalliiksi varaten ylimääräistä kapasiteettia eritoten Azure VM:issä ja Managed Instansseissa, eikä Azure sql:n Hyperscalekaan ilmaiseksi tule.

Lift and Shiftin idea sinällään on hyvä, että minimoidaan näkyvät migraatiokustannukset ja time-to-solution, mutta se voi aiheuttaa valtavasti päänsärkyä esimerkiksi siirryttäessä julkipilveen kuten Microsoft Azure. Vaikka Azureen meneminen Lift  and Shiftillä voi kuulostaa äkkiseltään helpolta, ei se sitä käytännössä kuitenkaan usein ole: Kun joudutaan vaihtamaan tallennuskapasiteetin service tiereitä, arvuuttelemaan virtuaalikoneen kokoa tai tyyppiä yhdestä toiseen, tai törmätään korkeamman käytettävyyden konfiguraatioon, jota ei voi käytännössä downgreidata jälkikäteen, ollaan ongelmisssa – tämänkin tiedon tulee perustua ennakointikykyiseen telemetriikkatietoon, jotta ratkaisu on kestävällä pohjalla. Pelkkä peräpeiliin tuijottaminen ei riitä.

Lisäksi syntyy epäkäytettävyystilanteita sekä uudelleenoptimoinnin / -konfiguroinnin aiheuttamia käyttökatkoja. Tällöin rahaa ja aikaa palaa samalla, kun palveluiden SLA:t alenevat. Toki palvelimet, instanssit ja tietokannat voidaan myös optimoida migraation jälkeen, mutta tämä prosessi ottaa aikaa aivan yhtälailla kuin ennen migraatiota, jolloin myös investoinnin kokonaiskustannukset ovat iso kysymysmerkki. Palvelun käyttöönoton jälkeen et varmasti halua ylimääräisiä käyttökatkoja bisneskriittisiin järjestelmiisi, etenkään terveydenhuoltoalalla, teollisuuden piirissä, tai muissa aikakriittisissä ympäristöissä.

Vaihtoehto Lift and Shiftille osana vaatimusmäärittelyä

Joskus Lift and Shift on kuitenkin ainoa ratkaisu, koska tähän voi liittyä politiikkaa ja kaupallisia reunaehtoja, sekä ajallisia paineita. Joka tapauksessa, aina tulisi tehdä perusteellinen vaatimusmäärittely datamigraatiohankkeeseen liittyen,ennen kuin lähdetään tekemään siirtoa uuteen ympäristöön. Tässä läpikäydään organisaation tarpeet läpi mukaanlukien bisnesimpaktianalyysi, kohdearkkitehtuuri- ja kapasiteettisuunnitelma, sekä säästölaskelma ja jatkuvasti päivittyvä riskianalyysi, sekä mietitään migraatiopolku eri osakokonaisuuksille, joka tyypillisesti kattaa joukon valmistelevaa performanssioptimointia, right-sizingia sekä työkuormien konsolidointia palvelin-, instanssi- ja tietokantatasolla. Näin osutaan heti maaliin erittäin suurella prosentilla ja Lift and Shift -ongelmilta vältytään.

Yhteenveto

FinOps kehittää datamigraatioihin liittyen vahvaa taloudellista selkärankaa ja pitää budjetin kurissa eritoten julkipilveen kuten Azure siirryttäessä. Palkintona säästetään resursseja, kuten rahaa, energiaa, ympäristöä. Kestävästi, pala kerrallaan. Oletko kiinnostunut SQL Governorista, FinOpsista ja datamigraatioista? Ole hyvä ja ota yhteyttä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

Osana blogisarjaa erilaisista datatiimien rooleista ja toiminnoista käyn tässä blogissa läpi, mikä on datainsinööri -rooli (Data Engineer) ja mitä datainsinöörin työ on käytännössä.

Ensiksi, datainsinööri -rooli ja tehtävän laajuus, kuten muissakin data-alan rooleissa, muokkaantuu usein kehityshankkeen vaiheen ja yrityksen tarpeiden mukaan. Hankkeiden eri vaiheissa tietyt osaamisvaatimukset korostuvat. nämä ovat myös mahtavia osaamisen kehittämisen mahdollisuuksia.

Joissakin tapauksissa datainsinöörin, datatieteilijän ja data-analyytikon roolit risteävät, ja roolien väliset rajat voivat olla epäselvät. Nykyään kuitenkin vaikuttaa siltä, että projekteissa ja tilaajilla on selkeämpi käsitys data-alan vakiintuneista rooleista ja niihin kuuluvista tehtävistä kuin vielä vuosikymmen sitten.

Käyn alla läpi tarkemmin, mitä datainsinöörin työ on käytännössä ja mitkä teknologiat ja taidot datainsinöörin tulee hallita. Mainitsen blogissa joitakin teknologioita. Asioita voi saavuttaa ja toteuttaa myös muillakin kilpailevilla teknologioilla. Me DB Pro Servicellä keskitymme Azure ja AWS -pilvipalveluihin sekä Databricks-, Snowflake-, Synapse- ja Fabric- data-alustoihin. DB Pro Serviceltä löydät seniortason sertifioidut osaajat näihin data- ja analytiikkaratkaisuihin.

Vaikka datainsinöörin osaamislista on pitkä, on hyvä muistaa, että suuremmat hankkeet toteutetaan ja lopputulokset saavutetaan tiiminä, johon teknisten ammattilaisten lisäksi kuuluu myös liiketoiminnan asiantuntijoita. Datatiimin jäsenten taidot täydentävät toisiaan, ja tiimin jäsenet jakavat tietoa tiimin sisällä, jotta kaikki voivat oppia ja kehittyä jatkuvasti.

Datainsinöörin tehtävät ja tärkeät osaamisalueet

Yksinkertaistettuna datainsinöörin tehtävä on tuoda raakadataa eri lähteistä tietoalustalle ja kustannustehokkaasti muuntaa se hyödynnettävään muotoon eri käyttäjille. Datainsinöörit ovat ammattilaisia, joilta tarvittaessa tulee löytyä teknisen osaamisen lisäksi myös liiketoiminnan ymmärrystä ja erinomaiset ongelmanratkaisutaidot. Koska työn ja erikoisalan vaatimukset vaihtelevat, ei ole olemassa tarkkaa listaa taidoista, jotka vaaditaan datainsinööriksi ryhtymiseen. Suurin osa taidoista opitaan käytännössä projekteissa ja itseään kouluttamalla.

Datainsinöörin työssä tarvittavat osaamisalueet ovat monipuolisia ja kattavat sekä teknisiä että analyyttisiä taitoja. Tässä muutamia keskeisiä osa-alueita, joilla datainsinöörin tulisi olla vahva:

• Pilvialustan hallinta ja arkkitehtuuri
• Integraatiot lähdejärjestelmien ja tietoalustan välillä
• Tietoputkien suunnittelu, rakentaminen ja orkestrointi
• Tietoalusta-, tietokanta-arkkitehtuuri ja mallinnus
• Python- ja SQL -ohjelmointitaidot  
• Infrastructure as Code (IaC) -käytännöt
• CI/CD ja DataOps
• Tietoturva- ja tietosuojakäytännöt
• Ratkaisujen dokumentointi ja demoaminen
• Jatkuva oppiminen

Käydään seuraavissa kappaleessa tarkemmin läpi osaa näistä eri osaamisalueita ja niiden sisältöjä.

Pilvialustan hallinta ja arkkitehtuuri

Datainsinöörit osallistuvat pilvialustan hallintaan ja arkkitehtuuriin esimerkiksi suunnittelemalla ja toteuttamalla pilvialustaan tietoalustan eri ympäristöille tarvittavat resurssit, käyttöoikeudet ja datan säilömis- ja tallennusratkaisuja. Tällaisia ovat esimerkiksi Data Lake- tai Event -pohjaiset ratkaisut. Tämän lisäksi voidaan hyödyntää erillistä ratkaisua datan arkistointiin vähän käytettävälle historiadatalle analyyttiseltä tietoalustalta. Datainsinööri hallitsee nämä kokonaisuudet ja ymmärtää, mikä ratkaisu ratkaisee liiketoiminnan tarpeen.

Tietokanta-arkkitehtuuri ja mallinnus

Datainsinöörillä on tärkeä rooli tietokanta-arkkitehtuurin määrittelyssä. Hänen tehtäviinsä kuuluu päättää, miten ja missä muodossa tiedot tuodaan tietoalustaan. Esimerkiksi on arvioitava, kirjoitetaanko tiedot aina uudelleen, vai tallennetaanko vain uudet ja muuttuneet tiedot.

Datainsinööri vastaa myös tietojen mallinnuksesta eri tietovaraston kerroksissa, jotta tieto saadaan optimoitua tehokasta käyttöä varten. Tietovaraston arkkitehtuuri voi olla esimerkiksi jaoteltu kolmeen pääkerrokseen: raakadata, siivottu data ja hyödyntäjäkerros. Näiden kerrosten tehtävät ovat seuraavat:

• Raakadatakerros:
  • Tämä kerros on tietovaraston ensimmäinen vaihe, jossa tiedot tallennetaan alkuperäisessä, käsittelemättömässä muodossaan. Raakadatakerros toimii “totuuden lähteenä,” joka säilyttää alkuperäisen datan eheänä. Datainsinöörin tehtävä on suunnitella, kuinka data tallennetaan ja miten sen eheyden säilyminen varmistetaan, jotta siihen voi aina palata tarvittaessa.
    
• Siivottu ja organisoitu datakerros:
  • Tässä kerroksessa raakadata muokataan ja puhdistetaan analysoitavaa muotoa varten. Datainsinööri käsittelee tässä vaiheessa puhdistus- ja muokkaustoimenpiteitä, kuten tietojen virheiden korjausta, arvojakaumien yhtenäistämistä ja datan yhdistämistä eri lähteistä. Tähän kerrokseen tallennetaan käsitelty versio datasta, joka on valmis analysoitavaksi, mutta ei vielä tietyn käyttäjäryhmän tai liiketoimintatarpeen mukaiseksi.
    
• Hyödyntäjäkerros:
  • Tämä kerros on suunniteltu erityisesti loppukäyttäjien, kuten data-analyytikkojen ja liiketoiminnan asiantuntijoiden, tarpeisiin. Tähän kerrokseen datainsinööri mallintaa tietoa eri käyttötapauksiin soveltuviksi tietorakenteiksi. Esimerkiksi datan aggregointi, dimensioiden lisääminen ja tietojen segmentointi ovat tyypillisiä toimenpiteitä hyödyntäjäkerroksessa, jossa data muokataan helposti käytettäväksi raportoinnissa ja analytiikassa. Hyödyntäjäkerroksen vaatimukset ja malli tulee usein hyödyntäjiltä. Datainsinöörin tehtäväksi tulee ainakin toteuttaa automaatio ja orkestrointi datan siirtämiselle tietomalliin.

Integraatiot ja ETL-prosessit

Datainsinöörin tärkeimpiin tehtäviin kuuluu integraatioiden ja ETL-prosessien suunnittelu ja toteutus. Datan integrointi tarkoittaa datan keräämistä eri lähteistä ja sen yhdistämistä yhtenäiseksi kokonaisuudeksi. Datainsinööri vastaa siitä, että data saadaan tuotua johdonmukaisesti eri järjestelmistä – kuten CRM-, ERP- ja IoT-järjestelmistä – tietovarastoon tai data lakeen.

• Tietolähteiden yhdistäminen:
  • Datan integrointi vaatii osaamista eri lähteiden, kuten SQL-tietokantojen, API-rajapintojen ja ulkoisten datalähteiden, kanssa. Datainsinööri suunnittelee ja rakentaa integraatiot, joiden avulla tieto saadaan siirrettyä keskitetyille alustoille.

Tietoputkien suunnittelu, rakentaminen ja orkestrointi

Tietoputkien suunnittelu määrittää, mistä ja miten dataa kerätään sekä missä muodossa se tallennetaan tietoalustaan. Rakentamisvaiheessa tietoputket toteutetaan teknisesti: Data kerätään, muokataan ja ladataan tietovarastoon.

• ETL-työkalujen hyödyntäminen:
  • Datainsinöörit hyödyntävät erilaisia ETL-työkaluja, jotka helpottavat tietojen siirtoa, muokkausta ja latausta. Tällaisia ovat esimerkiksi Azure Data Factory ja AWS Glue – pilvipohjaiset ETL-työkalut, jotka mahdollistavat datansiirron ja -muokkauksen suoraan pilviympäristössä.

Orkestroinnilla saavutetaan joustavuutta ja tehokkuutta seuraavilla tavoilla:

• Ajastus ja aikataulutus:
  • Orkestrointityökalut, kuten Azure Data Factory ja AWS Step Functions, mahdollistavat  ajoituksen, jolloin tietoputkia voidaan suorittaa automaattisesti tietyin väliajoin (esim. kerran tunnissa tai kerran päivässä) tai tapahtumapohjaisesti. Tämä vähentää manuaalisen työn tarvetta ja takaa datan ajantasaisuuden.
    
• Rinnakkaisuus ja riippuvuudet:
  • Orkestroinnin avulla voidaan määrittää, mitkä tietoputken vaiheet voidaan suorittaa rinnakkain ja mitkä on ajettava peräkkäisn riippuvuuksien vuoksi. Esimerkiksi datan keräys useista lähteistä voidaan tehdä samanaikaisesti, mutta muokkaus- ja puhdistusvaihe alkaa vasta, kun kaikki tarvittavat tiedot on kerätty. Rinnakkaisuus parantaa suorituskykyä ja vähentää tietoputken kokonaisajoaikaa.

Tietoputket voidaan rakentaa myös täysin reaaliaikaisiksi, jolloin data kulkee lähteistä analysoitavaksi tai tallennettavaksi heti sen saapuessa ilman viiveitä. Reaaliaikaiset tietoputket mahdollistavat jatkuvan datavirran, jossa uudet tiedot käsitellään ja siirretään kohdejärjestelmiin heti niiden syntyessä. Tämä on erityisen hyödyllistä sovelluksissa, joissa tarvitaan ajantasaista tietoa, kuten IoT-laitteiden datan seurannassa.

On hyvä muistaa, että reaaliaikainen tiedonsiirto vaatii jatkuvaa laskentakapasiteettia ja suuren määrän resursseja, koska dataa käsitellään ja siirretään jatkuvasti. Tämä lisää pilvipalveluiden ja infrastruktuurin käyttöön liittyviä kustannuksia.

Tietoturva- ja tietosuojakäytännöt

Datainsinöörin tärkeimpiin tietoturva- ja tietosuojakäytäntöihin liittyviin tehtäviin kuuluvat:

• Sensitiivisen datan maskaus ja pseudonymisointi tarvittaessa
• Integraatioiden eri avainten ja käyttöoikeuksien hallinta ja uusiminen
• Palomuurin avausten ja IP-rajauksien määrittely
• Tietoalustan ja käyttöoikeuksien luominen ja hallinta

Projektin vaiheen vaikutus datainsinöörin tehtäviin

Projektin vaihe vaikuttaa merkittävästi datainsinöörin tehtäviin. Projektin alkuvaiheessa tehtävät keskittyvät enemmän suunnitteluun, auditointiin ja erilaisten käytäntöjen, kuten tietoturvan, laatimiseen.

Tämän jälkeen siirrytään kehitysvaiheeseen, jossa tehtävät painottuvat alustan, integraatioiden, tietoputkien ja tietokantojen rakentamiseen sekä testaamiseen. Yleensä suuremmissa hankkeissa kehitysvaihe jatkuu pienemmällä vaihteella ylläpitovaiheen aikana, kun alusta ja tietovarasto ovat saavuttaneet tuotantovaiheen. Tällöin datainsinöörin tehtäviin kuuluu myös tietoalustan, integraatioiden ja tietoputkien monitorointi sekä operatiivinen toiminta, kuten datan laadullisten ongelmien ja epäonnistuneiden ajojen virheiden selvittäminen ja korjaaminen.

Lisäksi datainsinööri optimoi olemassa olevia tietoputkia ja toimintoja, jotta tietoalusta toimii optimaalisella tavalla.

Voisimmeko auttaa tietoalustan rakentamisessa ja kehittämisessä?

DB Pro Services tarjoaa huippuluokan datainsinöörejä Azure- ja AWS-alustoille sekä Databricks-, Snowflake-, Fabric- ja Synapse-tietoalustakokonaisuuksille. Ota yhteyttä, niin autamme sinua ja organisaatiotasi hyödyntämään tietoa tehokkaasti ja menestymään kilpailussa!

Robin Aro

Head of Services | Lead Data Engineer
robin.aro@dbproservices.fi

DB Pro Services Oy

Sinua saattaisi kiinnostaa myös:
Mikä on Data-analyst?
Mikä on DBA (Database Administrator)?

Tiedätkö, mitä DBA, eli tietokannan ylläpitäjä oikeastaan tekee? Käytännössä, nimensä mukaisesti; DBA on ammattilainen, joka vastaa organisaation tietokantojen hallinnasta, ylläpidosta ja suojaamisesta ja siitä, että tietokannat ovat aina käyttäjien saatavilla ja toimivat tehokkaasti.

DBA:n rooli on vaativa ja laaja, ja vain harva DBA osaakin kaikkia tähän kenttään osuvia kompetenssialueita suvereenisti. Tyypillistä onkin niin, että aloittelevat DBA:t keskittyvät enemmän rutiininomaiseen päivittäisoperointiin, kun taas kokeneet DBA:t painivat mm. sellaisten ongelmien, kuten arkkitehtuurin, korkean käytettävyyden, tietokantasuunnittelun, datamigraatioiden sekä suorituskyvyn optimoinnin parissa.

Accidental DBA

Termin ”Accidental DBA” kuulee myös silloin tällöin sellaisen DBA:n suusta, joka on ensin aloittanut esimerkiksi sysadminina, eli vastannut IT-infrasta ja saanut sitten aikanaan laajennetulle vastuulleen myös tietokantaympäristön ylläpitämisen. Tällaiset DBA:t ovat lähes poikkeuksetta eteviä tietokantaarkkitehtuuriin, tietoturvaan, datamigraatioihin sekä korkeaan käytettävyyteen (HA / DR) ja toipumissuunnitelmiin liittyvissä tehtävissä.

Toinen tie ”Accidental DBA”:ksi tulee usein tietokantaläheisen ohjelmoinnin kautta: Tällaisten DBA:iden vahvuuden ovat eritoten juurikin tietokantasuunnittelu, -ohjelmointi sekä performanssioptimointi eli ”tietokantojen tunkkaaminen” (alan slangitermi).

Joskus harvoin DBA on ehtinyt pitkällä urallaan tekemään ”kaikkea raudasta koodiin” ja saavuttaa tietynlaisen ”know it all” -statuksen. Tällöin alakohtaista kokemusta on ehtinyt yleensä kertyä jo yli 20 vuotta.

DBA-kompetenssin eri osa-alueet

• Ohjelmistopäivitykset ja patchays: DBA:t päivittävät ja korjaavat tietokannan hallintaohjelmistoja kuten SQL Server, virheiden korjaamiseksi, suorituskyvyn parantamiseksi sekä turvallisuuden ylläpitämiseksi. Tämä kuuluu usein myös Junior DBA:n tehtäviin.
  
• Varmuuskopiointi ja toipuminen: DBA:t luovat varmuuskopiointistrategioita tietojen suojaamiseksi järjestelmävian tai katastrofin sattuessa ja toteuttavat palautussuunnitelmia tietojen palauttamiseksi tarpeen mukaan. Prosessien automatisoinnin konfigurointi, säännönmukainen seuranta sekä testaaminen palautuksineen ovat hyvin olennainen osa-alue tätä kokonaisuutta. Junior DBA:t aloittavat usein tästä osa-alueesta, mutta vaativissa, korkean käytettävyyden ympäristöissä nämäkin tehtävät kannattaa jättää “mustan vyön” senior DBA:lle.
  
• Tietokantasuunnittelu ja implementaatio: DBA:t suunnittelevat ja koodaavat tietokantarakenteita, jotka vastaavat bisnestarpeita, ottaen huomioon näkökohdat, kuten tietojen tallennus, haku ja skaalautuvuus. Tietokannat voivat olla operatiivisia (OLTP) sekä tietovarastokantoja (DW, datamart). Jotkin DBA:t ovat erikoistuneet vain tähän osa-alueeseen sen vaativuuden takia.
  
• Suorituskyvyn seuranta ja optimointi: DBA:t valvovat tietokannan suorituskykyä ja tekevät muutoksia tietokantakyselyperformanssin, luotettavuuden ja tehokkuuden parantamiseksi. Vaikka tämä kompetenssialue kuulostaakin äkkiseltään vain koodioptimoinnilta, se sisältää parhaimmillaan myös kaikki tasot servereistä ja tallennusjärjestelmistä tietoverkkoihin, virtualisointialustaan, tietokantakonfiguraatioihin sekä indeksointiin ja statistiikkaan. Koska tehtäväkenttä on hyvin laaja ja vaatii usean kokonaisuuden syvällistä hellitsemista, Jotkut DBA:t tekevät vain tätä osa-aluetta.
  
• Tietoturva: Jotkin DBA:t osaavat eritoten panna täytäntöön erilaisia turvatoimenpiteitä arkaluonteisten tietojen suojaamiseksi luvattomalta käytöltä tai kyberuhilta, mukaan lukien salauksen määrittäminen, pääsynhallinta ja tarkastus. Tämäkin on yksistään hyvin laaja-alainen kokonaisuus kattaen organisaation sisäiset tietoturva-auditoinnit ja tietoturvadiagnostiikan, ennaltaehkäisevät toimenpiteet sekä toteutuneiden tietoturvauhkien jälkiselvitystyön (”forensics”), korjaavine toimenpiteineen.
  
• Datamigraatiot ja integraatiot: DBA:t voivat auttaa siirtämään tietoja eri järjestelmien välillä joko päivitysten, fuusioiden tai uusiin ohjelmistoalustoihin tai pilviympäristöihin siirtymisen aikana. Olennaisena osana datamigraatioita voi olla myös arkkitehtuurisuunnittelu, mikäli on tarpeen refaktoroida olemassa olevaa data-arkkitehtuuria esimerkiksi klusteroinnilla, skaalaamalla sitä ulos, konsolidoimalla, tai rakentamalla korkean käytettävyyden ratkaisuja lähdetiedolle. Olennaisena asana datamigraatioita kuuluu myös kapasiteettisuunnittelu: Tämä on yleensä datamigraatiohankkeen vaativin osa-alue, ja tuo laadukkaasti toteutettuna yleensä merkittävimmät säästöt uudelle data-alustalle.
  
• Käyttäjien käyttöoikeudet ja tuki: DBA:tmyöntävät käyttäjille tietokannan käyttöoikeudet ja tarjoavat tukea tietokantoihin liittyvissä ongelmissa, vianmääritysongelmissa sekä varmistavat, että käyttäjien tarpeet on tyydytetty.
  
• Vaatimustenmukaisuus ja auditointi: DBA:t voivat myös varmistaa, että tietokannat noudattavat lakisääteisiä ja sääntelyvaatimuksia (kuten GDPR tai HIPAA), ja suorittavat säännöllisiä tarkastuksia tähän liittyen.

Loppusanat

Tiesitkö, että DB Pro Servicen black belt DBA:t osaavat kaikkia näitä osa-alueita, ja että DBA:illamme on keskimäärin yli 25 vuoden timanttinen kokemus tietokantojen hallinnasta sadoissa eri asiakkuuksissa? Meidän black belt DBA:mme hallitsevat kukin vähintään kaksi edellämainituista kompetenssialueista suvereenisti, jotkut jopa kaikki. Oletko miettinyt jonkin DBA-kompetenssin ulkoistamista sen sijaan, että palkkaisit tähän oman DBA:n, joka ei ole tyypillisesti kustannustehokas ratkaisu?

Ostaessasi konsultointia täsmäongelmaan et maksa ylimääräisestä ja saat parhaan mahdollisen osaamisen juuri sinun ongelmaasi. Otathan yhteyttä, niin jutellaan lisää!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

Sinua saattaisi kiinnostaa myös:
Mikä on datainsinööri
Mikä on data-analyst?

SQL Server Log Shipping on monipuolinen ominaisuus, jota voidaan käyttää useampaan käyttötarkoitukseen. Tämä toiminnallisuus löytyy SQL Server Enterprise-, Standard- sekä Web editioneista.

Yleisiä käyttötarkoituksia, joissa log shippingiä käytetään:

• Disaster recovery -ratkaisu
• Raportointityökuorman siirtäminen toiseen palvelimeen
• Tietokantojen migraatiot

Mitä on SQL Server Log Shipping?

Log shipping mahdollistaa tietokannan kopioinnin eri palvelinten välillä. Operaatiossa hyödynnetään transaktiolokien varmistuksia. Log shipping hoitaa automaattisesti transaktiolokin varmistukset primäärinoodilta, kopioi sekä palauttaa tietokannan varmistuksen toissijaiseen noodin (=palvelimeen).

Varmistus / palautustoimien ajastaminen hoidetaan SQL Server Agentin toimesta muutamalla jobilla, jolloin tietokanta voidaan synkronoida halutun ajankohdan mukaan (voidaan määritellä synkronoinnit tehtäväksi esim. yöaikaan). Log shipping on yksittäisen tietokannan asetus, tällöin se pitää myös konfiguroida tietokannoittain.

Toissijaisen tietokannan lukeminen on myös mahdollista log shippingillä. Palautusprosessissa voidaan määritellä tietokannan operatiivinen tila kahdella erilaisella vaihtoehdolla:

• ”standby mode” on niin sanottu lämmin valmiustila. Tällöin tietokantaa voidaan lukea toissijaiselta palvelimelta aina palautustoimien välissä.
• ”recovery mode” pitää tietokannan tilassa, jolloin tietokantaan ei voida kohdistaa erillisiä kyselyitä.

Kuinka log shipping toimii?

1. Primääri-instanssin tietokannasta otetaan transaktiolokin varmistus
2. Kopioidaan varmuuskopio sekundaariselle palvelimelle
3. Palautetaan tietokanta sekundaariseen instanssiin

Miten tietokannat tulee varmistaa, mikäli log shipping otetaan käyttöön?

Log shipping ottaa vain yksittäisen tietokannan transaktion lokeista varmistuksia. Tällöin tulisi huolehtia, ettei mikään muu rutiininomainen ”varmistusjobi” varmistele samanaikaisesti transaktiolokeja. Mikäli tietokannasta otetaan useampia lokien varmistuksia, tällöin tietokannan palauttamiseen käytettävä lokiketju ”LSN” (Log sequence numbers) katkeaa. Tämä LSN-sarja pitää olla eheä, jotta tietokannan palauttaminen tiettyyn ajankohtaan onnistuisi. Tietokannalle pitää myös luoda log shippingin (lokivarmistusten) lisäksi päivittäiset / viikottaiset rutiininomaiset full- sekä / tai differential-varmistukset, jotta vikatilanteessa päästään palautumaan mahdollisimman tuoreeseen varmistustilanteeseen.

Log shipping voidaan pystyttää joko käyttämällä jo voimassa olevia täysvarmistuksia, tai niin että täysvarmistus otetaan pystytyksen hetkellä.

Vinkki: Muista siis pitää huoli rutiini varmistusjobeista, jottei log shipping sotke lokin palautusketjua.

Milloin Log Shipping -ominaisuutta on hyvä käyttää?

Migraatioissa Log Shipping mahdollistaa tietokannan siirtämisen palvelimelta toiselle hyvinkin pienellä käyttökatkolla, koska suurien tietokantojen varmistuksien kanssa saattaa mennä hyvinkin pitkiä aikoja, ennen kuin tietokanta saadaan siirrettyä käsipelillä (sis. varmistaminen, kopiointi sekä palautustoimet). Log shippingillä pidetään tietokanta suhteellisen ajantasaisena (tietokannan datojen menetys on lokivarmistusten välinen aika). Palvelimen siirto tehdään aina manuaalisesti (tarvitaan siis DBA-toimia). Siirron aikana otetaan vain viimeisimmät loki- sekä lokihännän varmistukset. Tämä mahdollistaa sen, että käyttökatkon pituus pysyy minimaalisena.

Log shippingiä on myös yksinkertaisempi hallita sekä konfiguroida, kuin tietokantataulujen replikointia. Replikointi vaatii myös tietokantamuutoksia tauluihin (primary key). Log shippingillä taasen riittää, että tietokannan recovery model on joko FULL tai BULK-LOGGED -tilassa.

Disaster recovery (DR) -ominaisuutena log shipping on huomattavasti yksinkertaisempi pystyttää, kuin Always On availability group, koska tämä ei tarvitse toimiakseen Windows Failover Cluster -komponentteja tai konfigurointeja. Log Shipping -ominaisuus on toiminut jo vuosia kuin se kuuluisa junan vessa. Tämän tekniikan avulla voidaan käyttää kahta tai useampaa palvelinta.

Log shippingiä voidaan myös ajatella raportointikäyttöön, esimerkiksi mikäli halutaan ohjata raportointikuorma ajettavaksi toissijaisella palvelimella, jolloin primäärillä vapautuu hieman työkuormaa muihin operatiivisiin operaatioihin. Huomiona se, että tietokantaa voidaan lukea palautustoimien välissä.

Mikäli sinulla on tarvetta SQL Server HA / DR-konsultoinnille, otathan minuun yhteyttä. 😊

Mikko Källroos 

Senior DBA & Architect

DB Pro Services Oy

mikko.kallroos@dbproservices.fi

Tämä blogi päättää blogisarjani SQL Server-tietokantojen klassiseen DataOpsiin liittyen. Tässä blogissa keskitytään taulujen (uudelleen-) luomiseen, SQL Server jobien (uudelleen-)luomiseen sekä tietokantatuotteen versiointiin.

Clean install-skriptimoduulit

Tänään läpikäydään seuraavat skriptikokonaisuudet:

• Populate tables -skripti populoi käyttäjätaulujen sisällön.
• Jobs -skripti (uudelleen-)luo kantaratkaisun SQL Server jobit.
• Version -skriptihoitaa lopuksi versiopäivityksen lokitauluun.

Populate tables -skripti

Populate tables -skriptin vaiheet ovat:

• Populoidaan käyttäjätaulut pää- ja viiteavainten mukaisessa parent-child -hierarkiajärjestyksessä.

Ohessa esimerkkkiskripti, jossa lisätään tauluun useampi rivi kerralla. Tämä on eritoten kätevää silloin, kun lisättäviä tietueita on kymmeniä tai vielä paljon enemmän. Vältyt näin turhan koodin kirjoittamiselta. Voit toki myös generoida T-SQL-koodin, joka luo dynaamisesti luontilausekkeet haluttuun muotoon, tai sitten voit käyttää jonkin kolmannen osapuolen koodingenerointityökaluja.

Entä kun haluat lisätä tauluun vain tietyt rivit, mutta joudutkin ajamaan kyseisen skriptin uudelleen? Silloin on näppärä käyttää IF EXISTS-määrettä seuraavalla tavalla:

Jobs -skripti

Jobs -skriptin vaiheet ovat:

• Poistetaan vanhat SQL Server jobit
• (Uudelleen-) Luodaan SQL Server jobit

Esimerkki vanhan SQL Server jobin poistosta scheduleineen. SQL Server jobit löytyvät msdb:n sysjobs_view -näkymästä.

Varsinaisen SQL Server jobin luontiin tarvitset seuraavia system stored procedureja:

• Sp_add_job
• Sp_add_job_server
• Sp_add_job_step
• Sp_add_jobschedule

Esimerkiksi; näin luodaan uusi SQL Server jobi, joka putsaa käyttäjätauluista  vanhentuneita rivejä:

Ensin lisätään jobi ja enabloidaan se. Sitten liitetään jobi serveriin, missä se ajetaan:

Lisätään SQL Server jobille steppi, jossa haluttu rivienpoistoproseduuri suoritetaan:

Lopuksi luodaan ja enabloidaan haluttu schedule jobille, tässä tapauksessa toistuva:

Version -skripti

Version-skriptin tehtävänä on tallentaa tuotteen versiointitiedot kronologisesti tiatokantatauluun. Tämän kautta on sitten helppo seurata, että missä tuoteversiossa mennään milloinkin. Versiotaulun rakenne voi olla yksinkertaisimmillaan esimerkiksi tällainen:

• Versionumerokenttä, esimerkiksi 16100.
• Versionimikenttä, esimerkiksi V16 CU1.
• Asennuspvm -kenttä, esimerkiksi 2024-10-30 15:50:00.000

Hyvänä käytäntönä voidaan pitää sitä, että jokainen yksittäinen asennus jättää tähän tauluun tietueen versiohistoriaan. Tästä on iloa installerille. 😉

Loppusanat

Tämä olikin sitten tämän blogisarjan viimeinen postaus. Nyt sinulla pitäisi olla ihan hyvät perusteet hallussa siitä, kuinka tietokantaskriptejä tehdään tuotekehitysmielessä. Systemaattisuus, modulaarisuus ja toistettavuus on tässä hommassa kaiken A ja O.

Miten voisimme olla avuksi juuri sinun tietokantaongelmissasi?

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

Saatat olla kiinnostunut:

SQL-tietokanta – historia, nykytila ja tulevaisuus: historia

Tässä blogissa käsittelen DataOpsia (Data Operations) yleisellä tasolla, sen eri teemoja ja miksi se on yritykselle tärkeää datan ja kehitysprosessien laadukkaassa hallinnassa. Tulevissa blogeissa käsitellään konkreettisia esimerkkejä siitä, kuinka toteuttaa lähteiden hallinta, jatkuva integrointi, jatkuva käyttöönotto ja yhteistyöhön perustuvat kehitysympäristöt.

DataOps on yhteistyöhön perustuva lähestymistapa datanhallintaan ja kehitysprosesseihin, jonka tavoitteena on parantaa viestintää, integraatiota ja automaatiota organisaation sisällä. DataOps on erityisen hyödyllinen data-alustan kehitystiimin ja datan käyttäjien välisessä tehokkaassa yhteistyössä. DataOpsin päätavoitteena on nopeuttaa arvon tuottamista varmistamalla, että datan, datamallien ja niihin liittyvien prosessien toimitus ja muutokset ovat ennustettavissa ja hallittavissa.

Tämä lähestymistapa hyödyntää teknologiaa datan toimitusprosessien suunnittelun, käyttöönoton ja hallinnan automatisoimiseksi. Samalla DataOps varmistaa, että datanhallintaan liittyvät valvonta- ja ohjauskäytännöt ovat riittävällä tasolla. Lisäksi se käyttää metadataa tehostaakseen datan käytettävyyttä ja lisätäkseen sen arvoa jatkuvasti muuttuvassa ja kehittyvässä ympäristössä.

Miten DataOps eroaa perinteisestä DevOpsista?

Usein kuulee sanottavan, että DataOps on vain uudelleenbrändäys DevOpsista, ja siinä on osittain perää. Perinteinen DevOps soveltaa CI/CD (Continuous Integration / Continuous Deployment) -menetelmiä ohjelmistokehitykseen, kun taas DataOps keskittyy datatuotteiden ja data-alustojen hyödyntäjien ja tuottajien siilojen purkamiseen, hyödyntäen perinteisiä DevOps- ja Data Governance -toimintatapoja.

DataOpsilla ja DevOpsilla on paljon yhteistä, sillä molemmat lähestymistavat ovat syntyneet tarpeesta tehostaa ja automatisoida monimutkaisia prosesseja, jotka vaativat useiden tiimien välistä yhteistyötä. Alla on listattu yleisellä tasolla keskeisiä yhteisiä piirteitä:

• Yhteistyön korostaminen
• Automaatio
• Jatkuva integrointi ja jatkuva toimitus (CI/CD)
• Iteratiivinen ja ketterä kehitys
• Laadunhallinta ja seuranta
• Kulttuurin muutos
• Skaalautuvuus

DataOps ja CI/CD  

CI/CD on keskeinen osa DataOps-toimintoja, ja se tuo mukanaan prosesseja, jotka parantavat datan hallintaa ja analysointia tehokkuuden ja laadun näkökulmasta. Seuraavassa selitän, miten CI/CD toimii DataOpsissa.

Continuous Integration (CI) DataOpsissa

Continuous Integration eli jatkuva integrointi tarkoittaa sitä, että datan, koodin ja mallien muutokset yhdistetään automaattisesti osaksi yhteistä projektia säännöllisin ja tihein väliajoin. DataOpsissa tämä voi tarkoittaa seuraavia toimintoja:

• Datan ja mallien versiohallinta: Kun datamallit tai -putket päivittyvät, ne integroidaan välittömästi yhteiseen koodivarastoon. Tämä varmistaa, että tiimi työskentelee aina uusimman version kanssa ja mahdollistaa muutosten seurannan ja hallinnan.
  
• Automaattinen testaus: Ennen kuin uudet muutokset otetaan käyttöön, ne testataan automaattisesti. Tämä voi sisältää datan laadunvalvontatestejä, mallien tarkkuuden varmistamista ja virheiden tunnistamista. Näin varmistetaan, että muutokset eivät riko olemassa olevia toimintoja.
  
• Yhteistyön tehostaminen: CI mahdollistaa sen, että useat tiimin jäsenet voivat työskennellä samanaikaisesti ja integroida työnsä saumattomasti. Tämä vähentää konflikteja ja nopeuttaa kehitystä.

Continuous Deployment (CD) DataOpsissa

Continuous Deployment eli jatkuva käyttöönotto tarkoittaa, että hyväksytyt ja testatut muutokset otetaan automaattisesti käyttöön tuotantoympäristössä. DataOpsissa tämä voi tarkoittaa seuraavia toimintoja:

• Automaattinen julkaisu: Kun muutos on testattu ja hyväksytty, se siirretään automaattisesti tuotantoon. Tämä voi koskea esimerkiksi uusia datamalleja, ETL-prosesseja (Extract, Transform, Load) tai datan visualisointeja.
  
• Nopea reagointi: CD mahdollistaa sen, että datan ja mallien muutokset voidaan ottaa käyttöön nopeasti ja turvallisesti. Tämä on erityisen tärkeää, kun on tarpeen reagoida nopeasti markkinamuutoksiin tai liiketoiminnan tarpeisiin.
  
• Jatkuva parantaminen: Koska muutokset voidaan ottaa käyttöön nopeasti, tiimit voivat keskittyä jatkuvaan parantamiseen. Tämä johtaa iteratiiviseen kehitykseen, jossa jokainen muutos tuo lisäarvoa.

DataOps ja Data Governance

Data governance, eli datan hallintamalli, on erityisen tärkeä osa DataOps-kokonaisuutta. Data governance viittaa niihin käytäntöihin, prosesseihin ja teknologioihin, joiden avulla organisaatiot varmistavat, että heidän hallussaan oleva data on laadukasta, turvallista, ja käytettävissä oikeaan aikaan ja oikeassa paikassa. DataOpsin kontekstissa data governance liittyy läheisesti CI/CD-prosesseihin ja toimii niiden rinnalla varmistamassa, että kaikki datan käsittelyyn liittyvät toimet ovat hallittuja ja säädeltyjä.

Data governance DataOpsissa

Data governance on olennainen osa DataOpsia, koska se varmistaa, että datan elinkaarta hallitaan tehokkaasti ja turvallisesti. Seuraavassa on muutamia keskeisiä osa-alueita, joissa data governance on erityisen tärkeä:

• Datan laatu: DataOpsin yhteydessä data governance sisältää prosessit, joiden avulla varmistetaan datan tarkkuus, eheys ja ajantasaisuus. CI/CD-prosessit voivat tuoda uutta dataa ja datamalleja tuotantoon nopeasti, mutta ilman tehokasta datan hallintamallia riskinä on, että huonolaatuista dataa päätyy järjestelmiin. Data governance asettaa standardit ja tarkastukset, joilla varmistetaan datan laatu koko sen elinkaaren ajan.
• Tietoturva ja yksityisyys: Data governance vastaa myös siitä, että organisaation dataa käsitellään turvallisesti ja lainsäädännön mukaisesti. Tämä on erityisen tärkeää, kun CI/CD-prosessien kautta tehdään jatkuvia muutoksia ja päivityksiä, sillä niiden täytyy noudattaa tietoturvaa ja yksityisyyttä koskevia vaatimuksia. Data governance varmistaa, että oikeat käyttäjät pääsevät käsiksi vain heille sallittuun dataan ja että kaikki käyttö ja muutokset ovat jäljitettävissä.
• Metadata ja datan jäljitettävyys: Metadata, eli tietoa datasta, on keskeinen osa DataOpsin data governance -prosessia. Metadataa käytetään paitsi datan ymmärtämiseen, myös sen jäljitettävyyden varmistamiseen. Tämä tarkoittaa, että jokainen datan muutos ja sen alkuperä voidaan jäljittää, mikä on tärkeää laadunhallinnan, virheenkorjauksen ja sääntelyn noudattamisen kannalta.
• Compliance ja sääntely: Monet toimialat ovat tiukasti säänneltyjä, ja data governance auttaa organisaatioita varmistamaan, että he noudattavat kaikkia asiaankuuluvia lakeja ja säännöksiä. CI/CD-prosessien avulla tehdyt muutokset on varmistettava niin, että ne ovat sääntöjen mukaisia ja että organisaation data pysyy sääntelyn vaatimusten mukaisena.

Data governance ja CI/CD: Yhteistyö DataOpsissa

Data governance ja CI/CD toimivat yhdessä DataOpsin sisällä varmistaakseen, että dataa käsitellään tehokkaasti ja turvallisesti. CI/CD-prosessit mahdollistavat nopean ja jatkuvan muutoksen, mutta ilman vahvaa data governance -kehystä tämä voisi johtaa kaaokseen ja virheisiin. Data governance tuo järjestystä ja luotettavuutta näihin prosesseihin, varmistaen samalla, että organisaation data on aina laadukasta, turvallista ja käyttökelpoista.

Tällä tavoin DataOps pystyy tukemaan organisaation tavoitteita hyödyntää dataa tehokkaasti ja samalla täyttää kaikki tietoturva- ja sääntelyvaatimukset. Data governance on siis kriittinen osa DataOpsia, ja sen merkitys kasvaa entisestään, kun organisaatiot pyrkivät automatisoimaan ja tehostamaan datan hallintaprosessejaan.

Loppusanat

Tässä blogissa käsittelin DataOpsin keskeisiä periaatteita, erityisesti sen suhdetta CI/CD-prosesseihin ja data governanceen. DataOps tarjoaa organisaatioille tehokkaan tavan hallita dataa ja kehitysprosesseja, tuoden yhteen eri tiimit ja varmistamalla, että dataa käsitellään luotettavasti ja laadukkaasti. Tulevissa blogeissa sukellamme syvemmälle DataOpsin käytäntöihin ja esimerkkeihin siitä, miten tämä lähestymistapa voi auttaa organisaatiotasi hyödyntämään dataa entistä paremmin.

DataOps on ratkaiseva tekijä nykypäivän datalähtöisessä maailmassa, ja sen merkitys tulee vain kasvamaan, kun organisaatiot pyrkivät pysymään kilpailukykyisinä ja reagoimaan nopeasti markkinoiden muutoksiin. Ottamalla DataOpsin osaksi liiketoimintaasi, voit varmistaa, että organisaatiosi data on aina ajan tasalla, luotettavaa ja käyttökelpoista, ja että pystyt hyödyntämään sen täyden potentiaalin.

Kiinnostuitko DataOpsista ja sen eri käytännöistä? Voisimmeko ehkä olla avuksi? Ole hyvä ja ota yhteyttä!

Robin Aro
robin.aro@dbproservices.fi
Lead Data Engineer
DB Pro Services Oy

Tämä blogi jatkaa blogisarjaani SQL Server-tietokantojen klassiseen DataOpsiin liittyen. Tässä blogissa keskitytään ohjelmoitavuuden (uudelleen-) luomiseen.

Clean install-skriptimoduulit

Tänään läpikäydään seuraavat skriptikokonaisuudet:

• Drop programmability
• Table types
• Create programmability

Huom! Skriptit on ajettava juuri tässä järjestyksessä.

Drop programmability -skripti

Drop programmability-skriptin vaiheet ovat:

• Pudotetaan valikoidut käyttäjän määrittelemät proseduurit (usp_)
• Pudotetaan valikoidut käyttäjän määrittelemät funktiot (ufn_)

Käyttäjän määrittelemät proseduurit on hyvä etuliitteistää ”usp_” -alkuisiksi, jotta ne erottuvat systeemin stored proceduresta (sp_). Ohessa skripti, joka automatisoi kaikkien käyttäjän määrittelemien proseduurien poistolausekkeet. Huomaathan, että kyseinen esimerkkiskripti ei itse poista proseduureja, vaan ainoastaan listaa poistolausekkeet. Jää sitten installerin tehtäväksi suorittaa varsinainen poisto-operaatio. Voit halutessasi muuttaa koodia siten, että proseduurien poisto suoritetaan while-slimukassa esimerkiksi exec -komennolla tai sp_execute_sql -systeemiproseduuria käyttäen. Proseduurit löytyvät sys.objects -näkymästä ja niiden tyyppi on ’P’, eli proseduuri.

Käyttäjän määrittelemät funktiot on vastaavasti hyvä etuliitteistää ”ufn_” -alkuisiksi, jotta ne erottuvat systeemifnktioista (fn_). Ohessa vastaavasti skripti, joka automatisoi kaikkien käyttäjän määrittelemien funktioiden poiston luontilauseet. Muutoin samat huomiot kuin proseduurien suhteen.

Funktiot löytyvät sys.objects -näkymästä ja niiden tyyppi on jokin seuraavista:

• TF = SQL table-valued-function (TVF)
• FN = SQL Scalar function
• IF = SQL inline table-valued function (TVF)

Tämän lisäksi on vielä joukko hupomioitavia CLR-funktioita:

• AF = Aggregate function
• FS = Assembly scalar-function
• FT = Assembly table-valued function

Table types -skripti ja TVP:t

Taulutyypit ovat erittäin käteviä monessa tilanteessa. Jos ne eivät ole sinulle ennestään tuttuja, pieni esittely lienee paikallaan: Niin kutsutut TVP:t (”Table-Valued Parameters”) määritetään käyttämällä käyttäjän määrittämiä taulutyyppejä. TVP:iden avulla voit välittää useita tietueita T-SQL-lauseeseen tai rutiiniin, kuten proseduuriin tai funktioon luomatta väliaikaista taulukkoa tai useita parametreja. Käytännössä nämä ovat siis eräänlaisia parametrilistoja. Suorituskykyiseksi tämän tekniikan tekee se, että T-SQL välittää TVP:t rutiineihin viittaamalla, jotta syöttötiedoista ei tehdä erillistä kopiota.

TVP on aina rajattu proseduuriin, funktioon tai dynaamiseen Transact-SQL-tekstiin, aivan kuten muutkin parametrit. Vastaavasti TVP:llä on vaikutusalue kuten millä tahansa muulla paikallisella muuttujalla, joka luodaan käyttämällä DECLARE-lausetta. Voit määritellä TVP:t dynaamisissa T-SQL-lausekkeissa ja välittää nämä muuttujat TVP:nä proseduureihin ja funktioihin.

TVP:t tarjoavat enemmän fleksiä ja joissakin tapauksissa paremman suorituskyvyn kuin temporary tablet tai muut parametriluettelon välittämistavat. Taulukkoarvoiset parametrit tarjoavatkin tietokantakoodarille seuraavia hyötyjä:

• Ne eivät ota lukkoja alkuperäisessä datan populoinnissa clientilta
• Ne tarjoavat yksinkertaisemman ohjelmointimallin
• Voit toteuttaa monimutkaistakin ohjelmalogiikkaa yhdessä rutiinissa
• Vähennät server roundtrippejä
• Voit käsitellä eri kardinaliteetin taulurakenteita
• Rakenteet ovat vahvasti tyypitettyjä
• Voit antaa clientin valita sort orderin ja uniikit avaimet
• TVP:n välimuistikäsittely vastaa proseduureissa temppitauluja

Taulutyypin poisto onnistuu seuraavanlaisesti:

Taulutyyppiä luotaessa sen olemassaolemattomuus varmistetaan sys.types -näkymän kautta esimerkiksi seuraavanlaisesti:

Create programmability -skripti

Tässä skriptissä (uudelleen-) luodaan käyttäjän määrittelemät proseduurit ja funktiot kääntäisessä kutsumajärjestyksessä:

1. Ensin esitellään sellaiset proseduurit ja funktiot, jotka eivät ole riipuvaisia toisista proseduureista ja funktioista.
   
2. Sitten esitellään sellaiset proseduurit ja funktiot, joita kutsutaan muista proseduureista ja funktioista siten, että järjestys on kutsumajärjestyksen suhteen käänteinen: Jos A kutsuu B:tä joka kutsuu C:tä, C esitellään ensin, sitten B, lopuksi A.
   
3. Viimeisimpänä esitellään näinollen sellaiset proseduurit ja funktiot, jotka ovat eniten riippuvaisia muista proseduureista ja funktioista.

Loppusanat

Jälleen kerran voimme todeta, että systeemiolioiden kautta operointi helpottaa merkittävästi rutiinien ohjelmoitavuutta. Tämän lisäksi opimme, että taulutyypit ovat erinomainen lisäkonsti temppitaulujen sekä CTE:iden (Common Table Expressions) lisäksi silloin, kun ohjelmoitavuus kompleksisoituu rutiinien, kuten käyttäjän määritetlemien proseduurien välillä ja välitettävän tiedon määrä on suuri.

Ovatko DBA:si ylityöllistettyjä? Meiltä saat juuri sopivan kaistan black belt -tason DBA-osaamista tukemaan liiketoimintaasi. Pidetään pyörät pyörimässä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

Sinua saattaa kiinnostaa myös:
Master Data ja Master Datan hallinta osana Business Intelligence arkkitehtuuria
SQL-tietokanta – historia, nykytila ja tulevaisuus: historia
Power BI pro ja eri lisensiointimallit
Power BI-raportointi – tasapaino tekniikan ja muotoilun välillä 

Tämä blogi jatkaa blogisarjaani SQL Server-tietokantojen klassiseen DataOpsiin liittyen. Tässä blogissa keskitytään taulujen ja näkymien poistoon sekä (uudelleen-) luontiin.

Yleisesti nimeämiskäytännöistä

Endoton suositus ja paras käytäntö kaikkien tietokantaolioiden määrämuotoiselle nimeämiselle loogisesti oliotyypin ja käyttötarkoituksen mukaan. Vältä ennen kaikkea teknisiä nimiä ja kirjainlyhenteitä niin paljon kuin mahdollista. Tärkeintä on, että koodisi on ymmärrettävää. Intellisense on olemassa pitkiäkin olionimiä varten. Puolipisteen kurinalainen käyttö statementtien lopuksi sekä koodin selkeä indentointi on myös hyvin tärkeää opetella, jotta koodi olisi mahdollisimman luettavaa.

Clean install-skriptimoduulit

Muistathan,että clean install-skriptinkin ajo voi mennä syystä tai toisesta pieleen. Tämän takia, ja jotta seuraavan tuoteversion skriptaaminen ja asentaminen olisi halpompaa, on syytä tehdä kaikista skripteistäsi uudelleenajettavia.

Tänään keskitytään Tables and views -skriptiin.

Skriptin vaiheistus

Tables and views-skriptissä (uudelleen-)luodaan nimensä mukaisesti käyttäjätaulut. Tässä vaiheessa tehdään ainakin seuraavat toimenpiteet siten, että skriptin uudelleenajettavuus on mahdollista:

• Pudotetaan käyttäjätaulujen pää- ja viiteavaimet
• Pudotetaan käyttäjänäkymät
• Pudotetaan käyttäjätaulut
• Luodaan käyttäjätaulut
• Lisätään käyttäjätauluihin constraintit ja defaultit
• Lisätään käyttäjätauluihin viiteavaimet
• Lisätään käyttäjänäkymät
• (Uudelleen-)luodaan muut kuin viiteavainindeksit
• Luodaan viiteavainindeksit
• Otetaan tarvittaessa kompressointi käyttöön

Käyttäjätaulujen pää- ja viiteavainten pudotus

Tämä homma hoituu parhaiten silmukalla. Näin säästyt turhalta koodaamiselta. Koodiesimerkissä tuhotaan 5 avainta kerrallaan niin kauan kuin avaimia riittää, näin toiminto on tehokas ja joustava eritoten, jos avaimia on satoja tai jopa tuhansia kappaleita.

Käyttäjänäkymien pudotus

Tässä ei pitäisi olla mitään sen ihmeellisempää. Käyttäjänäkymät nimetään esim. prefixillä ”v_”. If exists -määre on tietty pakollinen skriptin uudelleenajettavuutta varten ja olioviittaukset kannattaa lähtökohtaisesti kirjoittaa aina unicodena.

Käyttäjänäkymän pudotus.

Käyttäjätaulujen pudotus

Käyttäjätauluihin voi poistettaessa viitata näppärästi suoraan if exists-määreellä, niin kuin itse asiassa näkymiinkin.

Käyttäjätaulun pudotus.

Käyttäjätaulujen luonti

Käyttäjätaulujen osalta rajaan tämän blogin partitioimattomien taulujen käsittelyyn. Voisinkin kirjoittaa partitioitavista tauluista sitten ihan oman blogin, se kun on sen verran laaja kokonaisuus.

Esimerkissä luodaan käyttäjätaulu, jonka olemassaolo tarkistetaan sys.objects -näkymän kautta. Tässä on tärkeää muistaa, että taulun type -kentän tulee olla ”U”, eli käyttäjätaulu. Taulun käyttötarkoitukseen voi käyttää skeemaa tai sitten esimerkiksi kolmikirjainlyhennettä, mikäli skeemalla on esimerkiksi jokin muu käytttötarkoitus.

Taulua luotaessa sille määritellään kentät, joiden tietotyypit ja kenttäpituudet kannattaa miettiä huolella suorituskykynäkökulmasta eritoten silloin, kun taulu voi kasvaa isoksi. Joka tapauksessa kannattaa noudattaa kaikissa tietotyypeissä sekä kenttäpituuksissa johdonmukaisuuden periaatetta. Muista myös määrittää kentälle aina, voiko se saada null-arvon vai ei. Myös taulun pääavain luodaan tässä yhteydessä.

Käyttäjätaulun luonti.

Constrainttien ja default-arvojen lisäys käyttäjätauluihin

Constrainttien ja default-arvojen poistoissa viitataan sys.objects -näkymään type -kentän saadessa arvon ”D”.

Defaultin luonti.

Constraintin luonti.

Viiteavainten lisäys käyttäjätauluihin

Viiteavainta lisättäessä NOT EXISTS -määreelle annetaan referenssi sys.foreign_keys -näkymään, josta haetaan OBJECT_ID -funktiolla viiteavaimen nimi. Tämän lisäksi parent_object_id -kentän tulee viitata käyttäjätauluun itseensä. Mahdollinen cascadointi on myös määriteltävä tässä yhteydessä. CASCADE-määre tulee antaa viiteavaimelle päivittämisen (UPDATE) ja / tai deletoinnin (DELETE) yhteyteen. Kaskasointi tarkoittaa sitä, että mikäli viitatusta päätaulusta poistuu tai siinä päivitetään arvoja, päivitykset heijastuvat myös viittaavaan tauluun. Tässä taulussa sellaista ei ole määritelty.

Viiteavaimen lisäys käyttäjätauluun.

Käyttäjänäkymien lisääminen

Käyttäjänäkymien luonti on SQL Serverissä varsin suoraviivaista. Erikoisuutena voisi mainita SCHEMABINDING -option näkymää luotaessa: Se sitoo luodun näkymän pohjana olevan taulun tai taulujen rakenteeseen. Tämä on näppärää, jos haluat esimerkiksi varmistaa, että näkymät ovat aina ajantasaisia tai haluat lisätä indeksoinnin itse näkymään. Kun SCHEMABINDING on määritetty, perustaulua tai -tauluja ei voi muokata tavalla, joka vaikuttaisi näkymän määritykseen. Itse näkymämääritystä onkin ensin muokattava tai se on poistettava, jotta muokattavan taulun riippuvuudet poistetaan. Edelleen, kun käytät SCHEMABINDING:ia, SELECT:in on sisällettävä viitattujen taulujen, näkymien tai käyttäjän määrittämien funktioiden (UDF) kaksiosaiset nimet (schema.object). Kaikkien viitattujen objektien on myös oltava samassa tietokannassa.

Näkymiä tai tauluja, jotka osallistuvat SCHEMABINDING-lausekkeella luotuun näkymään, ei voi pudottaa, ellei näkymää poisteta tai muuteta niin, että sillä ei enää ole rakenteen sidontaa. Muussa tapauksessa tietokantamoottori aiheuttaa virheen. Myös ALTER TABLE -lausekkeiden suorittaminen tauluissa, jotka osallistuvat näkymiin, joissa on SCHEMABINDING, epäonnistuu, koska nämä lausekkeet vaikuttavat näkymän määritykseen.

Käyttäjänäkymän lisääminen.

Tavallisten indeksien lisäys

Indeksi poistetaan viittaamalla suoraan indeksin nimeen NOT EXISTS -määreellä kyseisessä taulussa. Lisäyksessä on hyvä muistaa, että mm. paksussa indeksissä kenttäjärjestys on B-tree -indeksin fyysinen järjestys ja että on mahdollisesti väliä sillä, kummassa järjestyksessä kunkin kentän indeksi fyysisesti organisoidaan (ASC vs. DESC).

Indeksin täyttöaste (fillfactor) on arvioitava sen muutosherkkyyden perusteella. Muuttumaton data, joka vain kerran kirjoitetaan tauluun ja sitä sitten selectoidaan, voi saada 100% täyttöasteen, mutta muutoin se on tyypillisesti välillä 60-95%. Oikein valittu täyttäaste voi vähentää mahdollisia page splittejä tarjoamalla riittävästi tilaa indeksin laajentamiselle, kun tietoja lisätään tauluun. Kun uusi rivi lisätään täydelle indeksisivulle, tietokantamoottori siirtää noin puolet riveistä uudelle sivulle, jotta tuolle riville jää tilaa. Tätä uudelleenjärjestelyä kutsutaan page splitiksi. Page split tekee tilaa uusille tietueille, mutta sen suorittaminen voi viedä aikaa ja vaatii paljon resursseja. Lisäksi se voi aiheuttaa fragmentaatiota, joka lisää storagen I/O-aktiviteettia. Jos sivujakoja tapahtuu usein, indeksi voidaan muodostaa uudelleen käyttämällä uutta tai aiemmin luotua fillfactor-arvoa tietojen jakamiseksi uudelleen. Esimerkin indeksisivuun kohdistuu kohtalaisesti UPDATE– / DELETE -toimintaa.

Indeksin lisäys.

Viiteavainindeksien lisäys

Viiteavaimia voi olla todella paljon ja kun ne on nimetty systemaattisesti samalla prefixillä, on varsin triviaalia automatisoida viiteavainindeksien lisäys. Esimerkkiskriptissä on tosin vakio täyttöaste indeksille, joten voit halutessasi optimoida skriptiä hieman pidemmälle.

Viiteavainindeksien automaattinen lisäys iteraattorilla.

Kompressoinnin käyttöönotto tietokannassa

Taulukompressointi säästää tilaa helposti tietokannassa jopa 50% ja sen CPU-footprint on 1% luokkaa, joten se kannattaa ottaa ehdottomasti käyttöön. Kompressointia on tarjolla rivitasolla (ROW) ja sivutasolla (PAGE). Yleensä sivutason kompressointi on tehokkaampi, eritoten datamart-tyyppisissä denormalisoiduissa tietokantaskeemoissa. Kompressoinnin hyötyä voi myös arvioida sp_estimate_data_compression_savings –systeemiproseduurilla. Proseduuri on tosin aika hidas isoja tauluja vasten ja jos tauluja on paljon, kannattaa joko automatisoida koko prosessi acceptance test -ympäristössä tai sitten käyttää aina rekursiivisesti PAGE -tason kompressointia, joka kokemukseni mukaan on 90-prosenttisesti oikea vaihtoehto. Kokeiltuasi eri vaihtoehtoja todennäköisesti päädyt seuraavaan ratkaisuun:

Loppusanat

Tietokantaskripteissä on hallinnallisesti neljä dimensiota: Systemaattisuus vs. luovuus ja dynaamisuus vs. staattisuus. Luovuuden ja dynaamisuuden kasvaessa koodin luettavuus ja ylläpidettävyys usein kärsivät, mutta toisaalta selviät paljon vähemmällä koodilla ja voit tehdä automaatioita aivan uudella tavalla. Your choice!

Tarvitseeko tiimisi auttavia, kokeneita DBA-käsipareja? Ole hyvä ja ota meihin yhteyttä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

Tämä blogi jatkaa blogisarjaani SQL Server-tietokantojen klassiseen DataOpsiin liittyen. Tässä blogissa pureudutaan ns. Clean install -skriptin tekoon, eli kun softa asennetaan ensimmäisen kerran hermeettiseen ympäristöön. Kuten edellisessä blogissani aihetta sivusin, on tätä varten viisasta luoda muuttumaton skriptirunko, jossa tietokannan ns. corekomponentit asennetaan ja jäädytetään tähän versioon, jotta uusiin versioihin voidaan tehdä omat erilliset päivitysskriptinsä.

Clean install-skriptimoduulit

Clean install-skriptistä tulee helposti aika iso. Siinä missä pienelle, yksinkertaiselle tietokannalle voi riittää yksi skriptimoduuli ja tuhat koodiriviä, kannattaa hieman kompleksisempi tietokanta purkaa osiin. Tämä takaa ketterän ylläpidettävyyden ja lisää selkeyttä ja rakennetta skripteihisi ja toimii hyvänä pohjana tulevien versioiden ylläpitoskripteille. Tässä vielä kertauksen vuoksi Clean Install -skriptin mahdollinen jako moduuleihin. Moduuleita nimettäessä voi selkeyden vuoksi käyttää ajojärjestykseen liittyvää enumerointia. Tällainen rakenne mahdollistaa jopa kymmenien tuhansien koodirivien modulaarisen toteutuksen. Proseduurit ja funktiot voit pilkkoa kunkin omikse skripteikseen jos ne ovat kompleksisia ja niitä on todella paljon. Tämä lisää kokonaisuuden ylläpidettävyyttä.

Clean Install-skripteissä sinulla olisi hyvä olla vähintään:

• Core-skripti, jossa tietokannan (uudelleen-) luontiskriptit käyttäjyyksineen.
• Tables and views -skriptiin sijoitetaan taulut ja näkymät uudelleenluonteineen.
• Drop procedures -skripti (tai Drop Programmability) tiputtaa kaikki user stored proceduret ja käyttäjäfunktiot tietokannasta.
• Table types -skripti (uudelleen-)luo kaikki taulutyypit.
• Create procedures (tai Create Programmability) -skripti (uudelleen-)luo kaikki user stored procedure ja käyttäjäfunktiot.
• Encrypted procedures -skripti (uudelleen-)luo kaikki kryptatut user stored proceduret.
• Populate tables -skripti truncatoi ja populoi käyttäjätaulujen sisällön (=alustus).
• Jobs -skripti (uudelleen-)luo ratkaisun SQL Server jobit.
• Version -skripti hoitaa lopuksi versiopäivityksen lokitauluun.

SQLCMD -tila

SQL Server Management Studion (SSMS) SQLCMD-tila on erityinen suoritustila, jonka avulla voit suorittaa SQLCMD-komentoja ja T-SQL -kyselyitä SSMS:n Query Analyzerissä. Kun SQLCMD-tila on käytössä, voit sisällyttää komentosarjoihisi SQLCMD-kohtaisia komentoja, mikä mahdollistaa monimutkaisempia ja automatisoidumpia tehtäviä, kuten komentosarjojen suorittamisen useille palvelimille, muuttujien käyttämisen tai ulkoisten komentosarjojen suorittamisen tiedostoista. Edelleen, voit suorittaa näitä komentoja esim. Windows Installerista käsin, jolloin voit syöttää TSQL-asennusskripteillesi ympäristömuuttujien arvoja esimerkiksi promptaamalla, saaden näin skriptit konfiguroitaviksi ja dynaamisiksi.

Voit aktivoida SQLCMD-tilan SSMS:ssä Query-valikosta valitsemalla ”SQLCMD Mode”, mikäli haluat suorittaa tietokantaskriptejäsi ko. tilassa:

Ympäristömuuttujat määritellään “:setvar” -määreellä, esimerkiksi:

:setvar DBFilePrimaryPath “C:\Program Files\MyDB\SQLData\Data”

Edelleen, ympäristömuuttujaan voidaan viitata T-SQL-skriptissä seuraavasti:

$(DBFilePrimaryPath)

Core-skripti

Core-skriptiin on hyvä sijoittaa ainakin:

• Tietokannan (uudelleen-)luonti
• Tietokanta-asetukset
• Loginit
• Käyttäjät
• Roolit
• Käyttöoikeudet
• Kredentiaalit
• Proxyt

SQL Server-tietokannan (uudelleen-)luonti

Ohessa esimerkki käyttäjätietokannan (uudelleen-)luonnista:

Huomaathan, että skriptissä on parametroitu muun muassa tiedostojen saantipolut, oletuskoko sekä kasvuvauhti tietyillä oletusarvoilla. Tällä tavalla käyttäjä voi asennuksen yhteydessä, esimerkiksi Windows installerin kautta vaikuttaa deployattavan tietokannan sijaintiin, kokoon sekä kasvuvauhtiin, jolloin ne saadaan heti konfiguroitua ympäristölle optimaalisiksi.

Koska skripti on uudelleenajettava, seuraavaksi skriptissä poistetaan mahdollisesti jo luotu tietokanta. Sitten luodaan tietokanta. Tämän jälkeen tulee tietokannan varsinainen luontiskripti, jossa on parhaana käytäntönä omat file grouppinsa big datalle, datalle sekä indekseille jaoteltuina kukin neljään datatiedostoon suorituskyvyn takaamiseksi.

Filegroupeista ja niiden luonnista sen verran, että SQL Serverin versiosta 2016 lähtien traceflag 1117:aa tietokantatasolla emuloiva AUTOGROW_ALL_FILES -optio kannattaa laittaa heti alkuun päälle: Tällöin, kun datatiedostoa kasvatetaan, kasvatetaan kaikkia tiedostoja samanaikaisesti, jotta ne pysyvät samankokoisina, mikä vähentää allokaation contentionia. Huom! Kyseisen määrityksen aikana kannassa ei saa olla kiinni muita käyttäjiä, joten sitä ei pysty enää tekemään onlinena, vaan se kannattaa laittaa heti päälle:

ALTER DATABASE [MyDatabase] MODIFY FILEGROUP [BIG_DATA] AUTOGROW_ALL_FILES

Tiedostokoot ja niiden kasvattaminen SQL Server-tietokannassa

Tämän lisäksi keskeisiä seikkoja ovat myös järkevät aloituskoot ja kasvuinkrementit loki- ja datatiedostoille, jotka riippuvat installaation koosta ja tiedostojen kasvuodotuksista. Tästä aiheesta voisikin kirjoittaa oman bloginsa, kuitenkin ohessa muutama keskeinen nosto: Nyrkkisääntö kasvunvaralle on noin 10 – 25% per inkrementti, mutta kuitenkin siten, että määrittellään kasvu magatavuina, ei prosentteina. Näin kasvu ei karkaa lapasesta ajan saatossa. Pienemmillä tietokannoilla voi olla sopivaa 64 – 256 MB kasvuinkrementti, kun taas suuremmilla se voi olla helposti jopa 1, 2, 4 GB tai enemmän.

Vakioitu tiedostokoon kasvu vähentää tiedostojen pirstoutumisen riskiä. Kun datatiedostot kasvavat pienin, tasaisin askelin, käyttöjärjestelmän on helpompi varata yhtenäistä levytilaa, mikä auttaa ylläpitämään hyvää I/O-suorituskykyä. Pirstoutuneet tiedostot voivat lisätä levyn I/O-toimintoja, mikä hidastaa tietokannan suorituskykyä. Tyypillisesti kannattaa myös laittaa instant file initialization -optio päälle (”perform volume maintenance tasks”). Se on SQL Serverin ominaisuus, joka mahdollistaa datatiedostojen merkittävästi nopeamman luomisen ja laajentamisen ohittamalla uuden levytilan nollaamisen. Tämä on erityisen tärkeää siksi, että SQL Server joutuu joka kerta odottamaan, kun sen datatiedosto kasvaa. Jos instant file initialization -optio ei ole päällä, se on SQL Serverin näkövinkkelistä vähän kuin katselisi robotin kävelyä mudassa.

Kun SQL Server luo tapahtumalokitiedoston tai kasvattaa sitä, se jakaa lokitiedoston pienempiin segmentteihin, joita kutsutaan virtuaalisiksi lokitiedostoiksi (vlf). SQL Server hallitsee näitä VLF-tiedostoja sisäisesti mahdollistaen tapahtumalokin tehokkaan käsittelyn. Luotujen VLF-tiedostojen määrä riippuu tapahtumalokitiedoston koosta ja niiden lisäysten koosta, joilla loki kasvaa. Lokitiedostoissa n. 1000 vlf:ää alkaa olla tyypillisesti SQL Serverin toimintaa hidastava määrä. Tämän takia ei kannata antaa lokitiedostolle alun alkaenkaan liian pientä tiedostokokoa.

Näin ollen, kuten arvata saattaa, olisikin suotavaa, että että data- ja lokitiedostojen autogrowtheja yritetään välttää viimeiseen asti. Se on aina hidastava tekijä, vaikka Instant File Initialization -oikeus olisi käytössä. Tiedostot kannattaakin jo alkuun määritellä täyttämään n. 80-prosenttisesti niille suunnitellut ja määritellyt levytilat, mikäli tämä vain suinkin on mahdollista.

Huom! Jos olet tekemässä tietokantaasi muulle kuin fyysiselle tai virtualisoidulle palvelimelle, preferenssit ovat esimerkiksi Azure PaaS-ratkaisussa (Managed Instance, SQL database) kovin erilaiset, eikä yllä oleva skripti ole näihin käyttötapauksiin sinällään käyttökelpoinen. Tässäkin olisi uuden blogin kirjoittamisen paikka.

Pari huomiota tietokantaoptioista

Tietokantaoptioista nostan pari tärkeää optiota ylitse muiden:

• SET AUTO_UPDATE_STATISTICS -optio kannattaa pitää päällä, mikäli haluat, että SQL Server päivittää automaattisesti indeksi- ja taulustatistiikkoja, kun ne happanevat. Prosessi lähtee käyntiin silloin, kun jokin kysely koskee vanhentuneisiin taulu- tai indeksistatistiikkoihin. (~>=20% muuttunutta dataa). Tämä johtaa yleensä tasaisempaan ympärivuorokautiseen suorituskykyyn kuin ilman tätä optiota, koska query optimizer kykenee tekemään järkevämpiä suoritussuunnitelmia. Kuitenkin esimerkiksi ympäristössä, jossa on SQL Serverin standard edition tai muutoin niin laajoja ja hardware-resurssien kannalta raskaita indeksi- ja statistiikkapäivityksiä, että ne halutaan ajoittaa aina palveluajan ulkopuolelle, ei tuolloin tätä optiota kannata pitää päällä laisinkaan.
  
• SET AUTO_UPDATE_STATISTICS_ASYNC -option ollessa päällä SQL Server sallii kyselyn suorittamisen samalla, kun sille tuoreutetaan statistiikkoja, mutta vain, jos myös SET AUTO_UPDATE_STATISTICS -optio on päällä. Tällöin SQL Serverin ei tarvitse odottaa tähän kyselyyn liittyvien statistiikkojen päivitystä, joka voi kestää joskus useita minuutteja, pahimmillaan jopa tunteja, vaan käyttää vanhaa, saatavilla olevaa statistiikkaa kyselyn suorittamiseen. Tätä optiota kannattaa siis soveltaa etenkin silloin, kun sinulla on isoja, herkästi muuttuvia tietokantatauluja, joihin kohdistuvissa kyselyissä on korkea vasteaikavaatimus.

Loppusanat

Muista kuitenkin, että vaikka kuinka yrittäisit ennakoida ja parametroida kaikki mahdolliset ympäristömuuttujat, on huolellinen integraatio- ja hyväksymistestaus kaiken A ja O. Silti, etenkin tuotteen ensimmäisissä versioissa, saattaa herkästi jäädä jotain oleellista tai yllättävää huomioimatta. Rapatessa roiskuu.

Haluatko kysyä jotakin SQL Server DataOpsiin tai tietokantoihin liittyen? Ole hyvä ja ota yhteyttä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy

Microsoft SQL Server-tietokantaskriptien luominen ja skriptien ylläpito ovat oma taiteenlajinsa, josta iso osa on ohjelmistotuotannollisia periaatteita, alan parhaita käytäntöjä, sekä koko joukko erilaisia teknisiä niksejä, jotka helpottavat lähdekoodinhallintaa.

Yleisesti ottaen systeemityössä tietokannan rakennetta (kaikki objektit) kutsutaan englanniksi nimellä schema, joka taasen ei ole sama asia kuin SQL Serverin schema. Edelleen; tietokannan päivitystä uuteen tilaan kutsutaan englanniksi yleensä termillä schema migration, eli skeemamigraatio.

Kaksi pääsuuntausta skeemamigraatioon ovat:

• Migraatioskriptit, jotka ajetaan aina järjestyksessä ja vievät skeeman hallitusti tunnettuun tilaan versiomuutos kerrallaan. Yleissääntönä vain lisätään uusia skriptejä, ei poisteta vanhoja
• Tilaperusteiset (state) strategiat, joissa määritetään tavoitetila ja softatyökalut koettavat päätellä lennossa, miten se saadaan haluttuun tavoitetilaan. Tällaisia työkaluja ovat esimerkiksi Visual Studion SQL Server Data Tools (SQL Server Data Tools | Visual Studio – Visual Studio (microsoft.com) sekä Redgate SQL Compare.

Tässä blogisarjassani käsittelen ensiksimainittua tapaa, joka mahdollistaa mielestäni koodipuolella enemmän asioita, vaikka onkin työläämpää ylläpitää ja kehittää. Blogi SQL Server Data Toolsista ja vastaavista työkaluista saa siis ainakin toistaiseksi vielä odottaa.

Tarkoituksenani on käydä läpi myös hieman tietokantasuunnittelun käytännön filosofiaa sekä toteutustapaa, jossa tietokantaskriptit ovat alun alkaen dynaamisia, eikä sinun tarvitse kyhätä tietokannallesi ylenmäärin luonti- ja ylläpitoskriptejä. Lisäksi käyn läpi perusteita pilkkoa luontiskriptit loogisiin kokonaisuuksiin, jotta tietokantaratkaisusta tulee ohjelmistotuotannollisesti modulaarisempi ja monikäyttöisempi eri päivitysskenaarioihin liittyen. Blogisarjassa sivuutetaan hieman myös lähdekoodinhallintaa.

Oma taustani Microsoft SQL Server-tietokannoissa alkaa vuodesta 1999, josta lähtien olen suunnitellut ja koodannut useita kymmeniä tietokantaratkaisuja, myös kansainvälisiä tietokantatuotteita kuten Wicom Data Universe sekä SQL Governor. Nykyisin johdan SQL Governorin R&D:tä sekä toimin yhtenä teknisistä liideistä dataprojekteissamme DB Pro Servicessä.

Pilko elefantti osiin – SQL-skriptien modularisointi

Kuten sanottua, tietokantaskriptien modulariointi tekee tietokantaratkaisustasi joustavamman eri käyttöskenaarioihin. Tämän lisäksi skriptit säilyvät helpommin ylläpidettävinä ja muodostavat hyvin suunniteltuina selkeitä, loogisia kokonaisuuksia, jotka on helppo vaiheistaa, olipa sitten kysymys clean installista, softapäivityksestä, hotfixistä tai asennuksen poistosta. Sinun kannattaakin kategorioida skriptimoduulisi näiden loogisten kokonaisuuksien pohjalta:

• Clean install = Softan ensimmäinen asennuskerta hermeettiseen ympäristöön. Tätä varten on viisasta luoda muuttumaton skriptirunko, jossa tietokannan ns. corekomponentit asennetaan ja jäädytetään tiettyyn versioon.
• Softapäivitys = Uuden softaversion päivittäminen edellisestä seuraavaan major- tai minor -versioon. Tätä varten tarvitset omat sql-päivitysskriptit eli ns. skeemamigraatioskriptit. Tällä tavalla voit tarvittaessa kelata tuoteversiopäivityksen useita versioita eteenpäin.
• Hotfix = Pikakorjaus, jossa yleensä ajetaan yksittäinen .sql-tiedosto korjaamaan yksittäistä bugia. Hotfixit on aina hyvä koostaa seuraavaan major- tai minor-softapäivitysversioon.
• Asennuksen poiston tulisi jättää ympäristö mahdollisimman lähelle asennusta edeltänyttä tilaa ja siivota vanha softakoodi pois ympäristöstä kokonaisuudessaan. Tätä varten tarvitset yleensä vain yhden tietokantaskriptin.

Clean install -skriptimoduulit

Clean installissa on yleensä eniten skriptimoduuleja, koska se toimii runkona koko tietokantaratkaisullesi. Skriptit kannattaa dynamisoida SQL command-parametreillä, jolloin niitä voi ajaa kätevästi esim. Windows installerista käsin kutsuen. Windows installerin on toki toivuttava kaikista niistä mahdollisista tilanteista, joissa tietokantaskripteissä tulee poikkeuksia. Lisäksi skriptimoduulien tulee olla uudelleen ajettavia (=idempotent), eli kaikkialla tietokantaskripteissä on käytettävä mm. DROP / CREATE- taikka CREATE OR ALTER -määreitä ja tarpeen tullen TRUNCATE TABLE -määrettä.

Tyypilliset clean install-skriptimoduulit ovat:

• Core-skriptiin on hyvä sijoittaa tietokannan (uudelleen-) luontiskriptit käyttäjyyksineen. Ethän käytä default sa-tunnusta, sillä tämä ei ole koskaan tietoturvallinen vaihtoehto SQL Server-ympäristössä.
• Tables and views -skriptiin sijoitetaan taulut ja näkymät uudelleenluonteineen.
• Drop procedures -skripti tiputtaa kaikki user stored proceduret ja käyttäjäfunktiot kannasta.
• Table types -skripti (uudelleen-)luo kaikki taulutyypit.
• Create procedures -skripti (uudelleen-)luo kaikki user stored proceduret ja käyttäjäfunktiot. Jos proseduureja on todella paljon ja ne ovat pitkiä, haluat ehkä modularisoida proseduurit ja funktiot kunkin omikse skripteikseen.
• Encrypted procedures -skripti (uudelleen-)luo kaikki kryptatut user stored proceduret.
• Populate tables -skripti truncatoi ja populoi käyttäjätaulujen sisällön (=alustus).
• Jobs -skripti (uudelleen-)luo ratkaisun SQL Server jobit.
• Version -skripti hoitaa lopuksi versiopäivityksen lokitauluun.

Tulen tässä blogisarjassa kirjoittamaan osasta keskeisimpiä skriptimoduuleja erillisiä blogeja, joissa kuvaan kunkin skriptimoduulin parhaita käytäntöjä hieman tarkemmin koodiesimerkkeineen.

Softapäivitysskriptimoduulit

• Version upgrade -skripti (yksi per versiosiirtymä, yhden major-version inkrementein)
• Version -skripti hoitaa lopuksi major- tai minor -versiopäivityksen lokitauluun.

Hotfix-skriptimoduulit

• Hotfix-skripti sisältää kuvauksen korjatusta ongelmasta sekä itse spesifin korjauksen havaittuun bugiin. Suosituksena on enintään yksi bugikorjaus per yksi tiedosto.
• Version -skripti hoitaa lopuksi hotfix-versiopäivityksen lokitauluun.

Asennuksen poistoskriptimoduulit

• Undeploy-skripti hoitaa koko tietokannan poiston.

Tietokannat kasvavat – ajattele isosti tai Siperia opettaa

Muutama varoituksen sananen agile-kulttuuria vastaan, nimenomaan tietokannoissa kun se tuppaa olemaan joiltan osin haastavaa, tai jopa ei-sovellettavaa: Tietokannat kasvavat ajan saatossa, yhdet lineaarisesti, toiset eksponentiaalisesti. Ohjelmistotuotannollisesti sinun tulisi kyetä edes karkeasti arvioimaan, kuinka suureksi tietokantaratkaisusi voi kasvaa seuraavien 10 vuoden aikana, sillä ei ole lainkaan tavatonta, että tietokantaohjelmistojen elinkaaret ovat jopa kymmeniä vuosia. Esimerkiksi SQL Governor -tietokantaohjelmistomme enimmäinen versio näki päivänvalonsa jo loppuvuodesta 2011. Tätä blogia kirjoittaessani teemme parhaillaan ohjelmistoversiota 16.

On varsin tyypillinen virhe, että tietokantatarpeet alimitoitetaan alussa. Normaali kehityskaari, jonka olen vuosien saatossa nähnyt on, että ensin on tehty jotain XML- tai JSON-pohjaista ja sitten siirrytty partitioimattomaan standalone-OLTP-kantaratkaisuun ja kun tämäkään ei riitä, aletaan kyhäämään taulupartitiointia ja kompressointia sekä viimein erillistä datamarttia, että saadaan operatiivista ja analyyttistä kuormaa jaettua keskenään. Edelleen saatetaan päätyä jopa klusteroituun HA-ratkaisuun. Tällainen kehityskaari on tehoton ja maksaa tietokantakeskeisessä ohjelmistokehityksessä pahimmillaan jopa moninkertaisen euromäärän verrattuna siihen, että alun alkaen mietitään ohjelmiston kasvupotentiaali ja kohdemarkkina siten, että se kestää asiakassegmentin muutoksen isompaan kategoriaan, mahdollisen tietokannanhallintajärjestelmän saatavuusluokituksen nousun sekä siirtymän on premisestä julkipilveen.

Esimerkiksi SQL Governor-tuotteemme tietokannat olivat ohjelmiston alkutaipaleella maksimissaan gigatavun luokkaa. Tänä päivänä ne voivat kasvaa järeimmissä asiakasympäristöissä viidessä vuodessa jopa useiden teratavutasolle, kun lähdetietokantapalvelimia on useita satoja. Onneksi toteutimme tietokantaan lokitaulujen rinnalle jo alun alkaen tähtimallinnetut, conformed data warehouse bus -arkkitehtuurin mukaiset taulut, joka mahdollistaa tehokkaan ja kompaktin historiatietojen tallentamisen ja raportoinnin isoillakin datamäärillä. Suurimmat (~>30M riviä) tietokantataulut tulee partitioida heti alun alkaen. SQL Server -tietokantoihin kun on työlästä ja aikaa vievää sorvata partitiointia jälkikäteen ilman erinäisiä ei-triviaaleja skriptejä ja datamigraatiosta aiheutuvia käyttökatkoja – etenkin jos kyseessä on tuote. Siperia opettaa.

Lähdekoodin hallinnasta

Lähdekoodin hallintaan suosittelen Git:iä, koska se on ilmainen ja integroituu Azure DevOpsiin. Tietokantaskriptien osalta on aivan yhtä keskeistä kuin managed koodissakin, että versioidaan release candidaatteja jo hyvin aikaisessa vaiheessa osana muuta build-toiminnallisuutta.

Loppusanat

Tietokantojen lähdekoodinhallinta on monimutkaista ja pikkutarkkaa puuhaa. Juurikin tietokannoille ominainen datamassojen persistointi tuo enemmän haasteita päivityksiin ja bugikorjauksiin kuin managed-koodissa. Ja vaikka kuinka yrittäisit valmistautua kaikkeen ikävään, migraatioskripteissäkin voi tulla tuotannossa yllätyksiä mm. suurista datamääristä johtuen. Myös erilaiset ympäristötekijät, kuten aikavyhöhykkeet ja kollaatiot voivat hankaloittaa tietokantaskriptien yhteensovittamista. Toimintatapoihin vaikuttavia erityispiirteitä ja haasteita voivat myös olla riippuvuuksien määrä yhdistettynä sekä asiakasympäristöjen monimuotoisuuteen.

On kuitenkin paljon käytäntöjä, joilla helpottaa tätä tuskaa. Juuri näihin kikka-kolmosiin pureudun tässä blogisarjassani.

Kiinnostuitko SQL Server-tietokannoista? Voisimmeko ehkä olla avuksi? Ole hyvä ja ota yhteyttä!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

CEO & Chairman

DB Pro Services Oy