SQL Serveristä julkaistaan tuotapikaa uusi versio, SQL Server 2016. Hurraa. Ajattelin vetäistä BI-lasit päähän ja katsella joitain uusia ominaisuuksia tietovarastoinnin näkökulmasta.
Stretch database on yksi kuumimmista uusista ominaisuuksista. Idea on, että tietokantaa voi helposti laajentaa Azure:n puolelle. Kuulostaa otsikkotasolla hienolta. Valitettavasti totuus ei ole aivan niin ruusuinen, kuin ominaisuuden nimestä voisi päätellä.
Ensinnäkin, Stretch-ominaisuus on määriteltävä jokaiselle taululle erikseen. On kirjoitettava funktio, joka määrittelee, mitä dataa Azure:en kirjoitetaan (tai annettava SQL Serverin päättää, mitä dataa Azureen kirjoitetaan). Esimerkiksi nyt vaikka tapahtumalajin perusteella voidaan määrittää, että harvemmin tarvittavat tapahtumat tallennetaan Azureen. Toiminnallisuuden nimestä voisi äkkinäinen päätellä, että ominaisuuden saisi päälle esim. filegroup-perusteisesti – mutta ei.
Toinen ongelma on, että tauluun, jolle Stretch on määritelty, ei pysty kirjoittamaan UPDATE tai DELETE-komentoja. On myös paljon muita rajoitteita, jotka on otettava taulun rakenteessa huomioon.
https://msdn.microsoft.com/en-us/library/mt605114.aspx
Ja kun kaivelemme toiminnallisuutta hieman syvemmälle, huomataan että kyseessä onkin itse asiassa SQL Server Linked Server, joka luodaan tätä toiminnallisuutta varten. Ja taustalla luodaan tietokanta luonnollisesti Azureen.
https://msdn.microsoft.com/en-us/library/mt163698.aspx
SQL Server kirjoittaa sitten tehtyjen määrittelyiden mukaisesti dataa LinkedServerin kautta Azureen.
Julkaistavaan versioon ei ole tullut juuri mitään uutta tämän suhteen sitten viime syksyn. Siksi en ala tekemään step-by-step-ohjeita aiheesta, niitä on netti pullollaan, vaikkapa tässä: http://sqlperformance.com/2015/08/sql-server-2016/intro-stretch-database
No mitä hyötyä tästä sitten on? No, tietovarastomaailmassa ei juuri mitään! On itse asiassa yksinkertaisempaa, joustavampaa ja suorituskykyisempää esimerkiksi
– Kirjoittaa ETL:ssä historiadata Azureen perustuen päivämääriin (tai vaikka niihin tapahtumalajeihin). Eli toteuttaa Azure:en kirjoituslogiikka ETL:ssä.
– Tai siirtää historiaa aika ajoin Azureen automatisoidusti lokaaleista tapahtumatauluista
– Ja tarvittaessa luoda LinkedServer lokaaliin SQL Serveriin ja yhdistää Azure- ja lokaali data näkymässä
Tällöin selvitään käytännössä ilman niitä rajoitteita, joita Stretch Database-ominaisuudella on… Kaiken lisäksi edellä kuvattu on ollut mahdollista jo edellisilläkin SQL Server-versioilla. Toisaalta Stretch helpottaa Azuren käyttöönottoa ja laskutus perustuu blob-storageen, jonka pitäisi olla halpa, mutta mielestäni nuo preview-hinnatkaan eivät ole kovin edullisia. Taitaa omissa BI-projekteissani jäädä toistaiseksi Stretch käytämättä.
https://azure.microsoft.com/en-us/pricing/details/sql-server-stretch-database/
