Is het mogelijk om de OData-cache in Azure Data Factory te cachen, zodat het aantal API-calls verlaagd kunnen worden?
Dit zal als het goed is de performance verhogen, correct?
Als het mogelijk is, heeft iemand een tutorial over hoe je dit in Azure Data Factory moet doen?
Het lukt niet om de vraag eenduidig te interpreteren.
Is het mogelijk meer context te schetsen en wat het probleem is?
We willen (denk ik) de Verse Duur tijd in Invantive Cloud verlagen (als dit mogelijk is).
In Azure Data Factory merken we ook dat het ophalen van data bij sommige OData endpoints langer zijn dan bij anderen. Zie onderstaand bijvoorbeeld:
Dit willen we graag optimaliseren. Tijdens het Googlen kwam ik het zogenaamde ‘API Caching’ (of OData Data Caching). We spreken namelijk vaker hetzelfde endpoint aan (bij verschillende databases).
Of zit ik helemaal verkeerd te denken en moet ik meer richting metadata-caching denken?
Het lukt niet om te begrijpen wat de context en situatie is.
Is het mogelijk om een uitgebreide situatieschets, probleemomschrijving en gedachte oplossingsrichting te beschrijven?
Ik zal hier later nog op terugkomen. Ik ga wel eerst proberen om het probleem/de context te schetsen.
Ik denk dat ik het probleem kan formuleren:
Tijdens development kan het zijn dat wij op één dag vaker de tabel ExactOnlineREST.Incremental.TransactionLinesIncremental@eol moeten binnenhalen via Azure Data Factory. Deze tabel (ofja, view) is voor veel administraties groot. Iedere keer weer kost dit resources binnen Invantive, als ik het goed heb.
Is het mogelijk om deze tabel op een of andere manier ergens te ‘cachen’, zodat niet alle data/verbindingen bij iedere nieuwe load opnieuw aangevraagd moet worden?
Is dit duidelijker?
Advies is om de standaard caching faciliteiten van PowerBI-platform te gebruiken zoals een shared data set op PowerBI of opslag in een omgeving (bestand, database).
Daarnaast kan het voor development handig zijn om de omvang van de dataset te beperken cq. de frequentie te beperken als een volledig set nodig is.
Tenslotte kan als alternatief een on-premises oplossing gebruikt worden van Invantive.
Hoe groot is de volledige dataset?
De grootte van de totale dataset varieert. Bij sommige administraties zijn het duizenden rijen, bij sommige drie- tot vierhonderdduizend rijen (voor Incremental.TransactionLinesIncremental). Deze worden voornamelijk ook incrementeel in Azure Data Factory ingeladen.
Tijdens het inladen van een nieuwe administratie in Data Factory, wordt bij de eerste load de volledige dataset ingeladen, vervolgens wordt de incrementele datastroom aangezet.
Als op een dag de Incremental.TransactionLinesIncremental tabel vaker moet worden ingeladen, zonder cache, kost dit veel resources. Vandaar de vraag of deze tabel ergens gecacht kan worden, zodat de hoeveelheid resources verlaagd kan worden. 
Hoe werkt een “incrementele datastroom” op Azure Data Factory (URL naar documentatie)? Er zijn meerdere variaties denkbaar.
Binnen Invantive Bridge Online wordt van de *Incremental-tabellen altijd een cache vastgehouden, die in combinatie met gemuteerde rijen leidt tot een nieuwe versie.
Het datavolume kan beperkt worden door aantal kolommen te beperken, en door te zorgen dat compressie aanstaat bij het OData-verzoek (standaard HTTP-compressie scheelt tot factor 10 en OData4-compressie met OmitValues=ODataOmitValues.Nulls zoals beschreven in Vermijd time-out fout bij Power BI OData download scheelt tussen de 15% en 98%).
Dus als ik het goed begrijp kan ik met OData query’s de grootte van een dataset verkleinen door specifieke kolommen op te vragen vanuit Azure Data Factory?
Hoelang wordt de cache van een Incremental-tabel vastgehouden in Invantive?
Ja, de grootte van een dataset (tijdens overdracht) kan beperkt worden door:
De cache van een *Incremental-tabel heeft vanuit de Exact Online-architectuur een levensduur van maximaal een aantal weken.
Top om te lezen!
Minder kolommen en rijen is duidelijk. Wat bedoelen jullie met slimmer transporteren?
“Slimmer transporteren” staat voor reeks van technieken om zonder kwaliteitsverlies of met beperkt kwaliteitsverlies dezelfde informatie van A naar B te krijgen. Bijvoorbeeld JPEG-encoding in plaats van raw voor foto’s of overwegend delta frames in video.
Binnen OData is het laaghangend fruit gebruik van compressie op HTTP en weglaten null values zoals eerder beschreven. Maar ook delta’s kan afhankelijk van de situatie, evenals andere engineering technieken. Op Internet zijn via Google veel voorbeelden te vinden van dergelijke technieken.
Dit topic is 7 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.
