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

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

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

Johdanto

Kuka käyttää tietokantoja? Kaikenlaiset monikansalliset, valtiolliset, kunnalliset, viranomais- sekä kaupalliset tahot kuin myös yhdistykset tarvitsevat toimintaansa tietokantoja. Tietokannat voivat sijaita pilvipalveluiden takana sekä ylipäätään erilaisissa laitteissa, kuten palvelimissa, pöytätietokoneissa, kännyköissä, tai sulautetuissa järjestelmissä. SQL-tietokannat ovatkin hallinneet maailmaa jo useiden vuosikymmenien ajan, ja ovat tänä päivänä yhä eniten käytetyin tietokantojen ilmenemismuoto. Pienemmissä yrityksissä voi olla vain kourallinen yksittäisiä tietokantoja, kun taas suuressa monikansallisessa yhtiössä tai softatalossa niitä voi olla jopa miljoonittain. Jokaista tietokantaa tulee hoitaa eri tavoin. SQL-tietokannat eivät pysy ajan saatossa toimintakuntoisina huoltamattomina. Tämä blogini tekee katsauksen tietokannanhallinnan eri aspekteihin juuri tästä näkökulmasta: Mitä tulisi valvoa, jotta vältytään tietokanta-alustojen erilaisilta vaaratilanteilta?

Mietitäänpä ensin, mitä tietokannat sisältävät. SQL-tietokantoihin tallennetaan sekä yrityksen transaktionaalinen data (OLTP), että niistä summattu ja jalostettu historiatieto (datamart, Data Warehouse). Transaktionaalisia SQL-tietokantoja ovat tyypillisesti erilaiset SCM-tietokannat sekä ERP-tietokannat, talousohjelmistojen tietokannat, CRM-tietokannat sekä muut sisällönhallinnalliset tietokannat ja rekisterit ja erilaiset tietovarastot. Yleisesti ottaen tietokantoja tarvitaan miltei poikkeuksetta sellaisissa sovelluksissa ja järjestelmissä, jotka keräävät paljon dataa, ovat reaaliaikaisia tai historioivat dataa päätöksenteon tueksi. Toisin sanoen, SQL-tietokanta sisältää liiketoiminnan kannalta keskeistä, kriittistä tietoa. Ilman tätä tietoa monet yritykset, yhteisöt ja laitteet eivät yksinkertaisesti pysty toimimaan.

Kun tietokantasi sanoo poks

Mitä tapahtuu, jos tietokantaa pyörittävä fyysinen alusta tai jokin softakonfiguraatio hajoaa niin, että tulee käyttökatko? Miten tästä toivutaan? Kuinka monta päivää, tuntia, minuuttia tai jopa sekuntia kyetään toimimaan ilman toimivaa tietokanta-alustaa ja miten paljon dataa ollaan valmiita käyttökatkon takia menettämään? Entä kuinka tällaisista kriisitilanteista toivutaan mahdollisimman luotettavasti, nopeasti ja tehokkaasti? Kaikkeen tähän vastauksena on DBA (Database Administrator), siis henkilö, joka pitää huolta tietokannoista teknisesti. Minun mielestäni jokaisella softatalolla, keskisuurella sekä suuryrityksellä tulisi olla vähintään yksi DBA, joskus jopa tiimi, jonka lisäksi yrityksen on hyvä käyttää ulkoisia, erityisluontoisia DBA-palveluita kokeneelta ulkoiselta toimijalta. Tämä siksi, että tuskin kukaan DBA hallitsee kaikkia tietokannanhallinnan osa-alueita täydellisesti ja ulkoiset toimijat ovatkin hyvin usein erikoistuneet joihinkin tiettyihin vaativiin DBA-toimintoihin. Tällöin omalle DBA:lle ja / tai konesalipalveluntarjoajan DBA-tiimille säästyy paremmin resursseja yrityksen SQL-tietokantojen ydintoiminnoista huolehtimiseen ja luonteeltaan usein väliaikaiset mutta vaativat spesialistien tehtävät voidaan jättää kolmansille osapuolille. Näin saadaan laadukkain ja kustannustehokkain kokonaisratkaisu.

Seuraavissa kappaleissa käyn läpi keskeisiä näkökulmia tietokantojen ylläpitämisen suhteen: Mikä voi mennä pieleen. Vastaamme on tullut DB Pro:n ja DB Pro Services:in toimintavuosien varrella useita satoja erilaisia Microsoft SQL Servereiden ongelmakohtia, jotka olemme, uskallan sanoa, yli 99-prosenttisesti, kyenneet tehokkaasti ratkaisemaan!

Saatavuus

Tietokantojen saatavuus on kaiken A ja O. Jos esimerkiksi yhteys liiketoimintakriittiseen tietokantaan lakkaa, peli on menetetty ja aletaan laskea vahinkojen määrää. Suuremmissa yrityksissä vahingot ovat tällöin tyypillisesti kymmenistä tuhansista euroista miljooniin euroihin päivässä. Mitä sitten pitäisi tehdä, jotta tällaiselta vältyttäisiin?

SQL-tietokantapalveluiden saatavuuden osalta seurattaviin kohteisiin kuuluvat mm. erilaiset julkiset tietokantapalvelut (IaaS, PaaS, SaaS), data centerit,  verkko, tallennuskapasiteetti sekä fyysiset palvelimet. Ohjelmistoteknisiä osa-alueita ovat mm. virtualisointi ja hyperkonvergenssi kuten Nutanix ja VMware, erilaiset korkean käytettävyyden (HA) ratkaisut sekä käyttöjärjestelmät, SQL-tietokannanhallintajärjestelmät ja tietokannat itsessään varmuuskopioineen.

Kokemukseni mukaan tyypillisimmät virheet ovat vastoin parhaita käytäntöjä tehdyt laite- ja tietokantakonfiguraatiot, alimitoitettu kapasiteetti sekä inhimilliset erehdykset. Yleisiä syitä tietokantojen saatavuusongelmiin ovat mm. ennakoimattomat työkuormahuiput, standalone-palvelimen vikaantuminen, jolloin tietokannatkin lakkaavat toimimasta, tai HA-ratkaisussa tietokannanhallintajärjestelmän palvelinnoodien vikautunut yliheitto, kun  työkuormaa ei saada onnistuneesti siirrettyä vikaantuneelta palvelimelta toiselle, sekä riittämätön kapasiteetti kun yhden tai useamman vikaantuneen palvelininstanssin työkuormaa uudelleenohjataan yliheitettyyn palvelimeen. Muita hyvin tyypillisiä tapauksia ovat tietokantojen datatiedostojen epäoptimaaliset konfiguraatiot tallennusjärjestelmää vasten, korruptoituneet tietokannat sekä toimimattomat tietokantapalautukset sekä vakavat lukkotilanteet (deadlock) operatiivisissa tietokannoissa, pintaa raapaistaakseni.

Näiden ehkäisemiseksi voidaan auditoida tietokanta-alustan konfiguraatiot sekä toteuttaa ne parhaiden käytäntöjen mukaan. Täytyy myös muistaa, että jokaisella rauta- ja softatoimittajalla on useimmiten omat suosituksensa. Myöskään tietokantabackupeilla ei tee mitään ilman säännönmukaisia palautustestauksia ja operatiivisella tietokannalla voi joutua äkkiä heittämään vesilintua, ellei indeksien ja statistiikkojen huoltoajot ole konfiguroitu tietokantaympäristölle optimaalisella tavalla ja niin edelleen.

Suorituskyky

Huonontunut SQL-tietokannan suorituskyky voi pahimmillaan aiheuttaa saatavuusongelman. Heikko SQL-tietokannan suorituskyky voi tuottaa erittäin huonon käyttäjäkokemuksen ja näin nakertaa käyttäjien työmotivaatiota sekä ennen kaikkea hidastaa organisaation normiprosesseja ja sitoa ylimääräisiä henkilöstöresursseja merkittävästi käyttäjäkunnan osalta, joskus jopa useita kymmeniä prosentteja. Tälle hintalapun laskeminen voi olla jopa hieman pelottavaa. Esimerkiksi softataloille tämä on todella kriittistä: Tietokannan on toimittava mahdollisimman tehokkaasti, koska jokainen uusi softan käyttäjä on kertoimena X tietokantaratkaisun kustannusrakenteelle: Ohjelmointivirheiden vaikutukset kumuloituvat ja onnistunut käyttäjäkokemus on keskeinen imagoasia.

Tyypillisiä SQL Server -tietokantojen suorituskyvyn pullonkauloja löytyy mm. käyttöjärjestelmäasetuksista, tietokantainstanssien konfiguraatioista, tietokantojen asetuksista ja kompressoinnista, tietokantataulujen partitioinnista, indeksoinnista, -statistiikasta ja niiden huoltoajoista sekä eritoten T-SQL-koodista. Kokemukseni mukaan 70% performanssiongelmista johtuukin huonosta T-SQL-koodista ja epäoptimaalisista asetuksista, loput 30% laiteongelmista ja eritoten kapasiteettivajeesta.

Performanssiongelmia voidaan ehkäistä diagnosoimalla huonosti toimivat tietokantapalvelimet ja tietokannat, tyypillisesti käyttämällä jotain ulkoista ohjelmistoa kuten SQL Governor-ohjelmistomme, jolloin saadaan sekä kokonaiskuva, että detaljitason löydökset kaivettua systeemistä nopeasti esille kokeneen DBA:n avustamana ja kohdennettua korjaavat toimenpiteet priorisoidussa järjestyksessä oikeisiin kohteisiin.

Kapasiteetti

Kun palvelinalustan fyysinen kapasiteetti ei riitä, palvelin alkaa hidastua ja pahimmillaan aiheuttaa epäkäytettävyystilanteen. Juuri siksi SQL-tietokantojen huolellinen kapasiteettisuunnittelu on tärkeää. Fyysisessä kapasiteetissa tyypillisimmät rajat SQL-tietokannoilla tulevat vastaan tallennuskapasiteetissa (IOPS / throughput, levylatenssi) sekä prosessorikapasiteetissa ja muistissa, joskus myös verkossa. Esimerkiksi prosessorin ylikuormittuminen on usein kriittinen ongelma OLTP-tyyppisessä tietokantapalvelimessa: Suoritettavia tehtäviä on prosessorilla enemmän kuin se ehtii parhaimmillaankaan hoitaa.

Paras keino välttää SQL-tietokantojen kapasiteettivaje suunniteltaessa uutta ympäristöä on pitkälliseen historia- ja trenditelemetriikkaan perustuva analyysi, jossa pyritään ottamaan huomioon mm. palvelinkapasiteetin peruskuorma eli baseline, sen kausivaihtelut, kuormapiikit, sekä palvelukatkosten ja patchayksen aiheuttamat anomaliat palvelin- instanssi- sekä tietokanta- ja aina datafile-tasolla saakka. Tällä tavalla pystytään ennakoimaan ja tarkasti laskemaan nykyhetken ja tulevaisuuden kapasiteettitarpeet. SQL Governor-ohjelmistossamme on useita kansainvälisiä patentteja sisältävät laskentamoduulit, joilla voidaan tarkasti määrittää tämänhetkinen sekä tulevaisuuden kapasiteettitarve palvelin-, instanssi- ja kanta sekä datafile-kohtaisesti sekä laskemaan auki erilaiset HA- ja migraatio ja konsolidointiskenaariot esimerkiksi on premisestä pilvialustaan tai toisinpäin. Olemme käyttäneet SQL Governor-ohjelmistoamme menestyksellisesti lukemattomissa migraatioissa ja pilvitransitioissa vuosien varrella.

Tietoturva

Tietoturvaa ei ole kenelläkään vara lakaista maton alle, etenkään näinä aikoina. Tässä ennaltaehkäisevä toiminta on kaiken keskiössä. SQL-tietokantaympäristöissä on lukuisia asetuksia, jotka tulee ottaa huomioon mahdollisimman tietoturvallisessa ratkaisussa. Täytyy varautua myös siihen, että tietokannat joutuisivat joka tapauksessa vääriin käsiin. Tällöin on syytä kryptata kaikki liiketoimintakriittinen tieto, ja jo mieluiten tänä päivänä symmetrisillä, kvanttiturvallisilla tiedonsalausalgoritmeillä.

Tietoturvaan liittyy paljon vastuuta ja vaaranpaikkoja. Blackbelt DBA-tiimimme tarjontaan kuuluvat myös SQL Server -ympäristöjen tietoturva-auditoinnit. Auditoinnin lopputuloksena saat hyvän käsityksen tietokanta-alustasi turvallisuudesta sekä mahdollisista haavoittuvuuksista, sekä ohjeet haavoittuvuuksien korjaamiseksi.

Avain hyvinvoivaan SQL-tietokanta-alustaan on jatkuva seuranta

SQL-tietokanta on kuin viritetty kilpa-auto: Se vaatii määräaikaishuoltoja sekä jatkuvaa seurantaa. Kokenut DBA kykenee usein ennakoimaan epäkäytettävyystilanteita ja muita vaaran paikkoja seuraamalla esimerkiksi tietokantojen lukkotilanteita, raudan resource spillejä, wait statistiikan trendejä, kyselysuunnitelmien resurssikulutuksen kausiluontoisuutta ja kehitystä sekä indeksoinnin kokonaistehokkuutta.

Vanha kansanviisaus kuuluu; ”hätä ei tule kello kaulassa”. Näin tekoälyn aikakaudella uskallan kuitenkin haastaa tätä viisautta. Ennakoivaa analytiikkaa hyödyntävä SQL Governor-tuotteemme tarjoaa tähän kaikkeen tehokkaan, monella tapaa ennaltaehkäisevän työkalupaletin, jolla saat kattavan kokonaiskuvan SQL-tietokantaympäristöstäsi 24 / 7 / 365 ja pystyt usein ennakoimaan poikkeustilanteita, jolloin DBA:lle jää enemmän aikaa reagoida sekä näin keskittyä sinne missä apua tarvitaan. Blackbelt DBA:mme yhdessä SQL Governorin kanssa voi olla juuri sinun SQL-tietokantaympäristösi ”tapaturmavakuutus”.

Kiinnostuitko? Ota yhteyttä niin keskustellaan lisää!

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy


Sinua saattaa kiinnostaa myös:
SQL tietokanta-historia
Ennakoiva analytiikka
Power BI pro ja eri lisensiointimallit

Blogisarjassani käsittelen tietokantojen kehittymistä 1960-luvulta tähän päivään sekä tulevaisuuden skenaarioihin. Tämä blogisarjan kolmas ja viimeinen osa hahmottelee sitä, millaisia haasteita tietokantojen nyyteknologioissa näen nyt ja tulevaisuudessa, sekä millaisia tietokantateknologioita tulevaisuus voisi tuoda tullessaan.

Esipuhe

Tulevaisuus. Mitä se on? Loppujen lopuksi tulevaisuus teknologian saralla on erilaisten resessiivisten ja näkyvien prosessien jatkumo, joka joskus ilmenee uusina innovaatioina ja yliopistollisen perustutkimuksen sekä soveltavista teknologioista tunnettujen puutteiden parannusinkrementteinä. Kaikki merkittävät uudistukset lähtevät ennakkoluulottomasta mitä jos -ajattelusta sekä naiivista unelmoinnista: ”Voisiko ehkä ollakin näin tai näin?” Tärkeintä on, että antaa tässä assosiatiivisessa horisontissa itselleen täyden vapauden ideoida, vaikka se onkin yleensä vain 2% koko aivotyöstä – ja loput 98% sitten sitä raakaa duunia.

SQL-tietokannat – mihin koskee?

Moderneissakin tietokannanhallintajärjestelmissä ajaudutaan melko usein erilaisiin suorituskyvyllisiin ongelmiin. Pullonkaulat voivat ilmetä esimerkiksi verkossa, tallennuskapasiteetissa, muistissa, prosessorikuormissa, tietokantataulujen lukituksissa, asetuksissa, indeksoinnissa ja statistiikassa – käytännössä miltei missä vaan. Kuitenkin, erinäisten tutkimusten sekä  kokemusperäisen tietoni pohjalta viimeisten 25 vuoden ajalta voin karkeasti arvioida, että keskimäärin 70% kaikista tietokantojen performanssiongelmista johtuu huonosta koodista ja 30% infra- sekä kapasiteettiongelmista.

Miksi sitten näin on? Syy on yhtälailla yksinkertainen kuin monimutkainenkin: Tietokannanhallintajärjestelmät ovat yksinkertaisesti kompleksisia kokonaisuuksia.

Data explosionin, tekoälyn ja julkipilvistymisen myötä tietokannanhallintajärjestelmille on syntynyt joukko uusia haasteita: Samalla kun kaikki pitää pakata pienempään, pitää pystyä yhtälailla lisäämään datan prosessointinopeutta sekä säilömään lähtökohtaisesti yhä toisarvoisemmalta tuntuvampi data talteen mahdollisia myöhempiä tietotarpeita varten: Juuri mitään dataa ei enää uskalleta heittää menemään – eikä toisaalta tarvitsekaan. Lisäksi kyberuhat ovat kasvaneet vihamielisten tahojen nostaessaan päätään maailmanpoliittisessa myllerryksessä – tiedon pitää olla samaan aikaan ”kaikkien ulottuvilla eikä kenenkään saatavilla”.

Tekoäly – sinne missä kipu on

Eräs kehityssuunta, johon olen itsekin kantanut korteni kekoon jo vuodesta 2011 lähtien kun ryhdyin yrittäjäksi, on tekoälyn nousu ja ylipäätään ihmisälyn kaltainen automaatio. Tästä on nähtävissä useita hyviä esimerkkejä esimerkiksi Microsoft-tietokantamaailmassa: SQL Server osaa ehdottaa käyttöstatistiikan perusteella sopivia tai ainakin osa-optimaalisia indeksejä, kyselyiden suoritussuunnitelmat vaihtelevat suotuisasti käyttötapauksista riippuen ja niihin voidaan tarpeen tullen vaikuttaa sekä edelleen konfiguroitaessa SQL-palvelininstanssia tietyt instanssikohtaiset asetukset sekä väliaikaistietokannan (tempdb) datatiedostomäärä optimoidaan automaattisesti installerin toimesta riippuen prosessoriytimistä jne jne.

Kuitenkin, hyvästä yrityksestä huolimatta, suurin osa aivotyöstä ja performanssiongelmien selvittelystä jää edelleen DBA: n ja tietokantakehittäjän päänvaivaksi. Miksei voisi esimerkiksi olla niin, että tietokanta osaisi edes raportoida siitä, että indeksistatistiikka ei ole kunnossa jonka seurauksena SQL Server arpoo sattumanvaraisesti erittäin hitaita suoritussuunnitelmia, välillä taas kunnollisia? Miksei tietokannanhallintajärjestelmä voisi itse havaita epäoptimaalisia konfiguraatioita ja tilastollisen päättelyn sekä anonyymin, telemetriikkapohjaisen parviälyn perusteella korjata, tai edes ehdottaa optimaalisempaa konfiguraatiota? Onko vika sitten liian modulaarisessa ajattelussa, kun tuhannet ja tuhannet sovelluskehittäjät koodaavat siiloissaan satoja uusia ominaisuuksia kuhunkin vallitsevaan tietokantateknologiaan joka vuosi? Onko visionäärisyys unohdettu? Minä ainakin tietokantaihmisenä olisin paljon tyytyväisempi kun nämä asiat olisivat kunnossa. Paljolti onkin keksintöjä kiittäminen tyytymättömyydestä: Eikö tätä voisi tehdä jotenkin järkevämmin?

Automaatio yleistyy – DBA-rooli polarisoituu

Eräs hallitsevien tietokannanhallintajärjestelmien automaatiota jarruttava osa-alue ovat pienemmät tietokantaohjelmistotalot, jotka ovat rakentaneet omaa IPR:ää tuotteidensa ympärille ja näin hidastaneet isoja softataloja tekemästä samankaltaisia automaatioita ja älykkäitä toiminnallisuuksia omiin tuotteisiinsa. DBA:t ottavat mielellään käyttöön juuri tällaisia työkaluja, jotka mahdollistavat tehokkaamman tietokannanhallinnan kokonaisuudessaan.

Kasvavan automaation seurauksena perinteinen tietokantojen hallinta tulee jäämään yhä vähemmälle tarpeelle: Oikeilla tietokantateknologioilla yksi DBA tekee viiden DBA:n duunit. Tämänsuuntaisesta teknologisesta kehityskulusta on erinomaisena esimerkkinä mm. Nutanixin NDB-tietokantatuote, joka abstrahoi monimutkaisen, eri tietokannanhallintajärjestelmien välillä erilaisen tavan tehdä versiopäivitykset, kloonaus, backupit sekä devops: Olkoon sitten tietokantasi SQL Server, Oracle, PostgreSQL tai vaikkapa MySql niin yhden helppokäyttöisen käyttöliittymän kautta voit hallinnoida kaikkia tietokantojasi samanmuotoisesti ja tehokkaasti. Tällöin aikaasi säästyy vaativammille tietokannanhallintatehtäville enemmän, kuten auditoinneille, kapasiteettisuunnittelulle, datamigraatioille ja performanssioptimoinnille. Toisaalta, näihinkin osa-alueisiin tulee koko ajan lisää automatisoivia tuotteita ja teknologioita, kuten open source-pohjainen, powershell-kirjastoihin perustuva dbatools sekä jo aiemmin mainitsemani SQL Governor-tuote.

Tämän kehityksen myötä DBA:n pitää ottaa haltuun yhä enemmän monimutkaisia asioita. Sellaisia asioista, joita on haastavaa tai miltei mahdotonta täysin automatisoida. Näitä ovat usein erilaiset DR-tilanteet, data-arkkitehtuurisuunnittelu, tietoturva ja tietomallinnus sekä monimutkaiset tietokantadiagnostiikat.

Uskallankin väittää, että jo tänä päivänä perinteinen DBA-rooli on polarisoitunut kahteen eri ryhmittymään: Lähempänä infraa olevat tietokannanhallintatehtäviin keskittyvät DBA:t, jotka käyttävät vahvasti eri automatisoinnin työkaluja, sekä data-arkkitehtuureihin, HA/DR:ään ja diagnostiikkaan keskittyvät DBA:t, jotka ovat toimineet alalla jo hyvin pitkään.

Kvanttitietokoneet tulevat – onko vahvasti salattu tietokantasi turvassa?

Suurin osa tietokannoistamme sisältää bisneskriittistä tietoa ja sen tulisi näin ollen olla salattua. Tähän on esimerkiksi SQL Serverissä ollut tarjolla vahvaa data- ja lokitiedostojen kryptausta (TDE) sisäänrakennettuna ominaisuutena jo pitkän aikaa. Kryptograafikkona eräs huolenaiheeni onkin ollut viime vuosina kvanttiteknologian sisäinen kilpajuoksu: Mustahatut vastaan valkohatut, eli kumpi on vallalla ensin – kvanttiturvallinen kryptaus vai perinteisen tiedonsalauksen potentiaalisesti hetkessä murtava kvanttilaskenta? Toisin kuin symmetrinen kryptaus kuten AES ja TDES riittävällä avainkoolla , asymmetrinen kryptaus on haavoittuvainen kvanttitietokoneiden laskentatehon edessä: Kvanttitekniikassa Shorin algoritmi voi kertoa suuria lukuja eksponentiaalisesti paljon nopeammin kuin klassiset tietokoneet. Koska epäsymmetriset algoritmit luottavat täysin siihen, että tavalliset tietokoneet eivät löydä alkutekijöitä nopeasti, ne ovat pysyneet turvassa. Valitettavasti monet epäsymmetriset salausalgoritmit on jo matemaattisesti todistettu rikottavaksi kvanttitietokoneilla käyttämällä Shorin algoritmia mukaan lukien RSA, Diffie-Hellman ja ECC. Onneksi kuitenkin SQL Serverin TDE on toteutettu AES / TDES:llä. Monet isot IT-talot kuten IBM onkin valmistautunut kvanttiaikakauteen kehittämällä kvanttiturvallisen teknologiaratkaisun: Quantum Safe | IBM Quantum Computing

Yhteenveto

Uudet teknologiat kuten tekoäly, koneoppiminen ja kvanttilaskenta avaavat uusia sfäärejä valtavien datamassojen tehokkaalle käsittelylle ja sovellusalueille: Ihminen tulee pääsemään lähemmäksi Laplacen demonia, jonka kaltaisen tietoteorian itsekin tietämättäni joskus parikymppisenä kehitin: 1800-luvun alussa mekanistisen luonnonfilosofian mukaan maailmaa voitiin tarkastella deterministisenä koneistona, jonka kaikkien osasten tarkat paikat ja nopeudet voitiin täsmällisesti tietää ja määritellä. Teoksessaan ”Taivaan mekaniikka”, aika pelottavan osuvasti, ranskalainen matemaatikko ja tähtitieteilijä Pierre-Simon de Laplace (1749–1827)  lausui seuraavaa: ”Jos älylle, joka pystyy hallitsemaan kaikkia luonnossa vaikuttavia voimia ja joka on niin suuri, että se voi analysoida kaiken, annettaisiin tiedot maailmankaikkeuden suurimpien kappaleiden liikkeistä ja keveimpien atomien käyttäytymisestä, se järjestäisi ne yhdeksi liikelaiksi; mikään ei olisi epävarmaa, niin tulevaisuus kuin menneisyyskin olisivat nykyisyyttä sen silmien edessä.” Väitänkin, että tekoälyn kehittymisen myötä ajaudumme vääjäämättömästi lähemmäs maailmankuvaa, jossa ihmisistä tulee älyllisesti laiskoja, mutta tiedollisesti kaikkivoipia: Keskimääräinen älykkyys laskee, väestö polarisoituu.

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

CEO & Chairman

DB Pro Services Oy

Tutustu myös näihin blogeihimme:
Ennakoiva analytiikka,
Power BI pro ja eri lisensointimallit
SQL-tietokanta: Nykytila

Tässä blogisarjassani käsittelen tietokantojen kehittymistä 1960-luvulta tähän päivään sekä pyrin hahmottelemaan tulevaisuutta. Tämä blogisarjan toinen osa kertoo ymmärrettävästi siitä, millaisia tietokantateknologioita nykyisin (2024) käytetään.

Aikaisempi blogi: SQL-tietokanta -historia

Taustaa

Tietokannanhallintajärjestelmät (DBMS) ovat olleet keskeisiä tietojen tallennuksen, haun ja hallinnan alalla vuosikymmeniä. DBMS:n kehitystä on ohjannut tarve käsitellä kasvavia tietomääriä, varmistaa turvallisuus sekä tarjota korkean käytettävyyden ja suorituskyvyn ratkaisuja, jotka voivat täyttää modernien sovellusten vaatimukset. Nykyaikaiset  DBMS:t heijastavat merkittäviä edistysaskelia ja innovaatioita, jotka vastaavat nykypäivän haasteisiin eri toimialoilla.

SQL-tietokantojen evoluutio historiasta nykypäivään

Tietokantaympäristöt ovat kehittyneet yksinkertaisista tiedostojärjestelmistä monimutkaisiin järjestelmiin, jotka on suunniteltu hallitsemaan suuria, hajautettuja kokonaisuuksia vaihtelevine ​​tietotyyppeineen. Perinteiset relaatiotietokannanhallintajärjestelmät (RDBMS) kuten Oracle, MySQL ja SQL Server, ovat pitkään hallinneet markkinoita. Nämä järjestelmät järjestävät tiedot tauluiksi ja käyttävät Structured Query Language (SQL) -kieltä tietojen määrittelyyn ja käsittelyyn.

Viime vuosina NoSQL-tietokantojen, kuten MongoDB, Cassandra ja Redis, suosio on kasvanut. Nämä järjestelmät on suunniteltu käsittelemään strukturoimatonta dataa tarjoamalla joustavia skeemoja ja tukemaan horisontaalista skaalausta. NoSQL-tietokannat ovat erityisen suosittuja big data -sovelluksissa, reaaliaikaisissa verkkosovelluksissa ja hajautetuissa arkkitehtuureissa.

Lisäksi on kehitetty NewSQL-tietokantoja, kuten Google Spanner ja CockroachDB, jotka yhdistävät perinteisen RDBMS:n ACID-ajattelun (Atomicity, Consistency, Isolation, Durability) NoSQL-järjestelmien skaalautuvuuteen. Nämä hybridiratkaisut pyrkivät tarjoamaan molempien maailmojen parhaat puolet varmistaen tietojen eheyden ja korkean käytettävyyden.

SQL-tietokannat pilvessä

DBMS:n integrointi pilvilaskentaan on mullistanut tavan, jolla tietokannat otetaan käyttöön, hallitaan ja skaalataan. Pilvipohjaiset tietokantajärjestelmät, kuten Amazon RDS, Microsoft Azure SQL Database ja Google Cloud SQL, tarjoavat hallittuja palveluita, jotka vähentävät organisaatioiden hallinnollista taakkaa. Nämä alustat tarjoavat automaattisia varmuuskopioita, korjauksia, skaalauksia ja korkean käytettävyyden, minkä ansiosta yritykset voivat keskittyä sovellusten kehittämiseen ja innovaatioihin runsaan ylläpitotyön sijaan.

Palvelimettomat tietokannat, kuten Amazon Aurora Serverless ja Azure Cosmos DB, lisäävät entisestään joustavuutta sallimalla resurssien automaattisen skaalauksen kysynnän mukaan. Tämä pay-as-you-go-malli varmistaa kustannustehokkuuden ja suorituskyvyn optimoinnin ilman manuaalisia toimenpiteitä.

SQL-tietokantojen suorituskyky ja skaalautuvuus

Nykyaikaiset DBMS-järjestelmät on suunniteltu käsittelemään nykyaikaisten sovellusten tuottamaa valtavaa datamassaa, jopa petatavuja ja enemmän. Tekniikoita, kuten sharding, partitiointi ja muistinvaraiset tietokannat (esim. Redis ja SAP HANA), on kehitetty suorituskyvyn parantamiseksi ja nopean tiedonsaannin varmistamiseksi.

Muistinvaraisettietokannat tallentavat tiedot järjestelmän käyttömuistiin levyn sijaan, mikä vähentää merkittävästi luku- / kirjoituslatensseja. Tämä on ratkaisevan tärkeää sovelluksille, jotka vaativat reaaliaikaista tietojenkäsittelyä ja analytiikkaa, kuten rahoituskaupan alustoilla ja IoT-järjestelmillä.

SQL-tietokantojen tietoturva ja komplianssi

Tietosuojan ja tietoturvan merkityksen kasvaessa nykyaikaisissa tietokannanhallintajärjestelmissä on vankat suojausominaisuudet. Staattinen salaus ja siirronaikainen salaus, edistyneet todennusmekanismit ja hienorakenteiset pääsynhallintalaitteet ovat vakiovarusteita. Myös GDPR:n, HIPAA:n ja CCPA:n kaltaisten säädösten noudattaminen on nykyisin ensisijaista – modernit tietokantaratkaisut tarjoavat työkaluja data governanceen ja audit trailien hallinnointiin.

Edistynyt analytiikka ja tekoälyn integraatio SQL-tietokannoissa

Kehittyneen analytiikan ja tekoälyn (AI) integrointi tietokantaan on avannut uusia mahdollisuuksia tiedon hyödyntämiseen. Nykyaikaiset tietokannat tukevat monimutkaisia ​​kyselyitä, tietovarastointia ja reaaliaikaista analytiikkaa, minkä ansiosta yritykset voivat saada käyttökelpoisia oivalluksia tiedoistaan – jopa kilpailueduksi tai innovaatioksi saakka.

Tekoälyllä toimivat ominaisuudet, kuten SQL Governor-tuotteen koneoppiva kapasiteettisuunnittelu ja ennakoivat hälytykset, taikka automatisoitu indeksointi, kyselyoptimointi ja poikkeamien havaitseminen parantavat modernien tietokannanhallintajärjestelmien  tehokkuutta ja luotettavuutta. Myös Oraclen Autonomous Database käyttää koneoppimista automatisoidakseen rutiininomaisia ​​tietokannan hallintatehtäviä, mikä parantaa suorituskykyä ja vähentää inhimillisiä virheitä.

Yhteenveto

Nykyaikaisten tietokannanhallintajärjestelmien tilaa leimaa monipuolisuus, suorituskyky ja jonkin sorttinen älykkyys. Erilaisten tietokannanhallintajärjestelmätyyppien monimuotoisuus perinteisistä RDBMS-järjestelmistä NoSQL:ään ja NewSQL:ään vastaa moderneihin tietotarpeisiin ja käyttötapauksiin. Pilvi-integraatio, muistinvarainen käsittely, vankka tietoturva ja tekoälyyn perustuvat toiminnot heijastavat tietokantojen jatkuvaa kehitystä ja mukauttamista vastaamaan digitaaliajan vaatimuksiin. Tietomäärän ja monimutkaisuuden kasvaessa jatkuvasti tietokantateknologioiden innovaatioilla on ratkaiseva rooli tiedonhallinnan tulevaisuuden muovaamisessa. Millainen tämä tulevaisuus sitten on? Kerron siitä lisää blogisarjani seuraavassa osassa.

Jani K. Savolainen

jani.savolainen@dbproservices.fi

0440353637

VP & Chairman

DB Pro Services Oy