Miten ristiliitokset heikentävät hallintapaneelin suorituskykyä

Analytiikkatiimisi laati raportin. Se toimi hyvin kehitysympäristössä, mutta kun se siirrettiin tuotantoympäristöön, käyttäjät alkoivat valittaa latausajasta. Tiimisi on tarkistanut tietokannan ja käynyt läpi hallintapaneelin asetukset, mutta kukaan ei löydä vian syytä.

On hyvin todennäköistä, että syynä on ristiliitos, ja vieläkin todennäköisempää on, että se suoritetaan väärässä kohdassa.

Mikä on ristiliitos ja miksi se on tärkeää

SQL-liitosten avulla tietokannat yhdistävät useista taulukoista peräisin olevia tietoja. Useimmat liitokset ovat tarkoituksellisia ja rajattuja. Sisäliitos (inner join) palauttaa vain ne rivit, joissa kahden taulukon välillä on vastaavuusehto. Vasen liitos (left join) palauttaa kaikki tiedot yhdestä taulukosta ja vertaa niitä toiseen taulukkoon siinä määrin kuin se on mahdollista. Molemmat tuottavat hallittavia ja ennustettavia tulosjoukkoja.

Ristiliitos toimii eri tavalla. Sen sijaan, että se yhdistäisi rivejä jonkin ehdon perusteella, se yhdistää jokaisen rivin yhdestä taulukosta jokaisen rivin toisesta taulukosta. Kaksi taulukkoa, joissa kummassakin on 1 000 riviä, tuottaa 1 000 000 väliriviä ennen kuin suodatusta edes aloitetaan. Kaksi taulukkoa, joissa kummassakin on 100 000 riviä, tuottaa 10 miljardia väliriviä. Tietokannan on käsiteltävä kaikki nämä tiedot ennen kuin se voi palauttaa tuloksen.

Ristiliitoksilla on perusteltuja käyttötarkoituksia, etenkin tietyntyyppisissä laskelmissa ja tietomallinnustehtävissä. Ongelma syntyy, kun ne ilmestyvät vahingossa, mikä tapahtuu useammin kuin tiimit tajuavat. Väärin määritelty suhde semanttisessa kerroksessa, mukautettu SQL-kysely, josta puuttuu liitosehto, tai mallinnusvirhe dbt:n kaltaisessa tietotyökalussa voivat kaikki aiheuttaa tahattoman ristiliitoksen ilman, että kukaan olisi kirjoittanut sellaista nimenomaisesti. Vaikka kysely näyttää normaalilta, sen käyttäytyminen ei ole sitä.

Se osa, jonka useimmat joukkueet jättävät huomiotta

Kun ristiliitos aiheuttaa suorituskykyongelman, on luonnollista tarkastella ensin tietokantaa tai BI-työkalua. Molemmat ovat yleensä kunnossa. Se tekijä, joka todellisuudessa määrää, kuinka vakavaksi ongelma kehittyy, on se, missä liitos suoritetaan.

BI-ympäristössä kyselyt eivät siirry suoraan työkalusta tietokantaan. Ne kulkevat yhteyskerroksen, eli ohjaimen, kautta, joka hoitaa näiden kahden välinen viestinnän. Ohjain määrittää, kuinka suuri osa kyselylogiikasta lähetetään tietokantaan suoritettavaksi ja kuinka suuri osa käsitellään paikallisesti tietojen hakemisen jälkeen.

Kun ohjelmoija siirtää liitoslogiikan tietokantaan, tietokantamoottori huolehtii sen käsittelystä. Se käyttää kyselysuunnittelijaansa, hakemistojaan ja optimointitoimintojaan suorittaakseen liitoksen mahdollisimman tehokkaasti. Suodatettu ja aggregoitu tulosjoukko palautetaan BI-työkaluun, ja koontinäyttö latautuu nopeasti.

Kun ohjain ei pysty hyödyntämään liitoslogiikkaa täysimääräisesti, se hakee suurempia tietojoukkoja tietokannasta ja käsittelee niitä paikallisesti. Ristiliitoksen tapauksessa tämä tarkoittaa, että koko karteesinen tulo lasketaan tietokannan ulkopuolella ilman tietokannan optimointitoimintoja. Tämä aiheuttaa muun muassa seuraavia ongelmia:

• Muistipiikit

• Käsittelyaika moninkertaistuu

• Kehitysvaiheessa moitteettomasti toiminut hallintapaneeli lakkaa reagoimasta tuotantoympäristössä

Tiimisi kirjoittama SQL-koodi voi olla täysin kunnossa. Syynä voi olla juuri se muuttuja, joka muuttaa hallittavan toiminnon suorituskykyongelmaksi.

Miltä tämä näyttää käytännössä

Tiimisi havaitsema oire on se, että hallintapaneeli latautuu hitaasti tai aikakatkaisu tapahtuu normaalissa käytössä. Samanaikaiset käyttäjät pahentavat tilannetta merkittävästi. Kun useat käyttäjät suorittavat saman kyselyn samanaikaisesti ja jokainen heistä tuottaa asiakaspuolen karteesisen tulon, muistin ja prosessoinnin kuormitus kasvaa nopeasti.

Tämä malli toimii kehitysvaiheessa, mutta pettää tuotantoympäristössä. Kun tilanne pahenee käyttäjämäärän kasvaessa, se on luotettava merkki siitä, että liitoksen suorituspaikkaa kannattaa tutkia. Kysely, jonka analyytikko testasi suoraan tietokannasta, suoritettiin täydellä tietokantaoptimoinnilla. Sama kysely BI-työkalun kautta suoritettiin ajurin kautta, joka ei kyennyt siirtämään operaatiota alaspäin, ja ero tuli näkyviin vasta todellisessa kuormituksessa.

Ratkaisu on kuljettajassa

Tämän ongelman ratkaiseminen ei vaadi SQL-koodin uudelleenkirjoittamista tai BI-työkalujen vaihtamista. Se edellyttää ajuria, joka käsittelee pushdown-toiminnon oikein.

Maailman johtavat dataympäristöt, kuten Google, Microsoft ja Databricks, luottavat insightsoftwaren Simba-ratkaisuun omien datan käyttötuotteidensa toteuttamisessa. Sama standardipohjainen liitettävyys on yritysten tiimien käytettävissä Simban ODBC- ja JDBC-ajurien kautta. Tuetut liitosehdot, suodattimet ja aggregoinnit lähetetään lähdetietokantaan suoritettavaksi. BI-työkaluun palautetaan tulosjoukko, ei raakadataa, jota odotettaisiin käsiteltäväksi muistissa.

Tuloksena on dashboardien suorituskyky, joka kestää todellisia kuormituksia Tableau-, Power BI-, Logi Symphony- ja muissa merkittävissä BI-alustoissa, sillä raskaat laskentatoimet suoritetaan siellä, missä ne on tarkoitettu suoritettaviksi – suoraan tietokannassa.

Jos tiimisi on yrittänyt selvittää suorituskykyongelmaa, jota kukaan ei ole onnistunut paikantamaan, kannattaa tarkastella ajokerroksia tarkemmin.

Haluatko tietää lisää? Lue raporttimme siitä, miten voit nopeuttaa BI-analytiikka- tai tietojen valmistelualustan käyttöönottoa.