Grote performancewinst bij real-time queries op gefilterde views met tabelfuncties

Go to English version

Invantive SQL biedt real-time toegang tot data uit ongeveer 80 platformen. Sommige platformen hebben views op basis van tabelfuncties voor gebruik met Power BI, Qlik en/of Tableau. Voor verbeterde prestaties past het nu filters op rapportageviews ook binnen de view toe, wat resulteert in aanzienlijke snelheidswinst. Dit geldt met name voor Easyflex, Loket.nl, Minox, Nmbrs, Teamleader en Visma.net Financials.

Real-time Rapportageviews voor Tabelfuncties

Invantive SQL biedt real-time toegang tot gegevens in circa 80 platformen. Veel gebruikers verwerken de data in Power BI, Qlik of Tableau-rapporten. Een deel van de platformen is historisch door de desbetreffende leveranciers gebaseerd op API’s die parameter(s) vereisen. Invantive SQL biedt hiervoor zogenaamde “tabelfuncties”. Tabelfuncties zijn niet te benaderen via Invantive Bridge Online. Invantive SQL biedt daarom voor gebruikers van Power BI, Qlik en Tableau vele voorgedefinieerde “Views” in het schema “Views”; deze zijn vergelijkbaar met uw eigen database views zoals beschreven in Eigen database-views gebruiken voor SQL en BI-tools.

Performance-optimalisatie

Veel van deze rapportageviews halen eerst een lijst op uit een tabel met de mogelijke waardes, zoals “Loonjaren” en vragen dan via een aparte API-call per regel uit de lijsttabel de bijbehorende gegevens op.

Vaak is niet alle data nodig en wordt een filter toegepast, dat bijvoorbeeld via query-folding bij Invantive SQL binnenkomt. Filters op een rapportageview worden echter pas toegepast nadat voor alle rijen uit de lijst de bijbehorende gegevens opgehaald zijn. Hierdoor hebben filters geen invloed op aantal API-calls van de view en beperken ze enkel het resulterend datavolume.

Een nieuwe performance-optimalisatie past filters op een rapportageview ook toe binnen de view. Hierdoor stijgen de prestaties vaak met een orde van grootte of nog meer, terwijl het aantal API-calls op het platform met een vergelijkbare hoeveelheid beperkt wordt.

Voorbeeld

Een voorbeeld van een dergelijke view is Uren op Easyflex met als definitie:

select ljr.jaar Jaar
,      clr.month_number Maand
,      uur.*
from   DataService.Werkmaatschappij.Loonjaren ljr
join   CALENDAR@DataDictionary clr
on     clr.YEAR_NUMBER = ljr.jaar
and    clr.day_in_month = 1
join   DataService.Relatie.Uren(ljr.jaar, clr.month_number) uur

Deze view Uren zal in voorgaande softwareversies eerst alle rijen uitrekenen door voor alle periodes in alle loonjaren de uren op te vragen bij Easyflex. Dit veroorzaakt voor vijf loonjaren tenminste 5*12=60 API-calls, plus 1 voor de loonjaren, uitgaande dat elke periode maar 5.000 uurregistraties bevat. De te verwachten looptijd is dan bijvoorbeeld (60+1) * 5 seconden = 305 seconden voor maximaal 300.000 urenregistraties.

Als een rapport enkel de uren van januari 2023 nodig heeft, dan levert dit een SQL-query op zoals:

select *
from   Uren
where  Jaar = 2023
and    Maand = 1

Het aantal rijen is dan bijvoorbeeld 5.000, maar de looptijd blijft pakweg 305 seconden. Alle uren worden tenslotte eerst volledig berekend en daarna pas gefilterd.

Dankzij de nieuwe performance-optimalisatie verandert dit dramatisch. Een filter op een view wordt doorgezet binnen de view waar mogelijk, waardoor de view in dit voorbeeld de volgende logica bevat:

select ljr.jaar Jaar
,      clr.month_number Maand
,      uur.*
from   DataService.Werkmaatschappij.Loonjaren ljr
join   CALENDAR@DataDictionary clr
on     clr.YEAR_NUMBER = ljr.jaar
and    clr.day_in_month = 1
join   DataService.Relatie.Uren(ljr.jaar, clr.month_number) uur
where  ljr.Jaar = 2023
and    clr.month_number = 1

Uitgaande van dezelfde kengetallen duurt deze real-time query maar 10 seconden en voert maar 2 API-calls uit. De prestatiewinst is in dit voorbeeld een factor 30!

Platformen

Op de volgende platformen zal deze snelheidswinst bij het toevoegen van filters het meest opvallen:

Views die gebruikers zelf ontwikkelen en toepassen, bijvoorbeeld vanuit de startup-SQL van een Invantive Cloud-database, profiteren ook van de snelheidswinst.

Er zijn geen veranderingen nodig aan views om van de snelheidswinst te profiteren zolang het filter op een view 1-op-1 vertaald wordt op een kolom van een snelle lijsttabel die gebruikt wordt als input voor een tabelfunctie.

Beschikbaarheid

De performanceverbeteringen zijn beschikbaar in de BETA-releases vanaf 22.1.272 en op Invantive Cloud vanaf 25 augustus 2023 via Bridge Online (BETA) en App Online (BETA). De verbeteringen komen niet beschikbaar in release 22.0.