App-prestaties optimaliseren
App-prestaties kunnen worden verbeterd door een verminderde app-grootte, vereenvoudigde gegevensmodellen en strategisch gebruik van set-analyses. In deze sectie wordt aangeduid welke factoren invloed hebben op prestaties om u te helpen prestatieproblemen te voorkomen en u in staat te stellen de app-prestaties te evalueren en bewaken.
U kunt zien hoe uw app presteert met behulp van de tool voor prestatie-evaluatie. Ga voor meer informatie naar Evaluatie van de app-prestaties.
Complexiteit van app
Dit zijn losse categorieën die kunnen helpen om problemen vast te stellen. De meest complexe apps hebben de laagste prestaties.
Eenvoudige apps:
- Bevatten geen complexe set-analyse of If()-statements.
- Bevatten geen grote tabellen.
- Hebben een simpel gegevensmodel.
- Bevatten eenvoudige berekeningen.
- Kunnen een grote hoeveelheid gegevens bevatten.
Gemiddelde apps:
- Bevatten een gegevensmodel met veel tabellen, maar de beste praktijken zijn in acht genomen.
- Maken gebruik van set-analyses en verschillende If()-statements.
- Bevatten grote of brede tabellen op werkbladen (15 kolommen of meer).
Complexe apps:
-
Bevatten een zeer complex gegevensmodel.
- Zijn gekoppeld met een grote hoeveelheid gegevens.
- Bevatten complexe berekeningen, diagrammen en tabellen.
Grote hoeveelheid gegevens.
U kunt deze strategieën voor de architectuur toepassen wanneer u een grote hoeveelheid gegevens koppelt.
Segmentatie
U kunt QVDs op dimensies segmenteren, zoals tijdsbestek, regio of aggregatieniveau. U hebt bijvoorbeeld de volgende elementen:
- Een QVD die gegevens bevat van de afgelopen twee jaar.
- Een QVD die historische gegevens bevat die ouder zijn dan twee jaar.
Een QVD die alle gegevens bevat die op een hoger niveau zijn geaggregeerd. Bijvoorbeeld per maand in plaats van per datum, of per land in plaats van afzonderlijke klanten.
- Eén grote QVD met alle gegevens, die alleen wordt gebruikt door een kleine subset gebruikers.
U kunt de apps op een soortgelijke manier segmenteren. Kleinere apps zijn geschikt voor de analytische behoeften van de meeste gebruikers. Dit bespaart geheugen.
U kunt ook meerdere apps hebben die gericht zijn op verschillende regio's. Op deze manier openen gebruikers niet een app met gegevens waarin ze niet zijn geïnteresseerd of waartoe ze geen toegangsrechten hebben. Gegevens die niet toegankelijk zijn via sectietoegang hebben toch invloed op het geheugen.
Generatie van een on-demand-app (ODAG)
Qlik Sense on-demand-apps bieden gebruikers samengevoegde weergaven van archieven voor big data. Ze kunnen relevante subsets van de gegevens identificeren en laden voor een uitgebreide analyse.
Vanuit het oogpunt van de gebruiker zijn er twee apps:
- Een winkelmandje met geaggregeerde gegevens.
- Een lege sjabloon-app om details weer te geven.
De gebruiker maakt selecties in de app voor het winkelmandje. Zodra een grens is bereikt, wordt een aangepast LOAD-script gemaakt die de sjabloon-app invult met de aangevraagde details. Ga voor meer informatie naar Big data beheren met On-demand-apps.
Applicaties koppelen
Applicaties koppelen (wordt document koppelen genoemd in QlikView 12) betekent dat er een geaggregeerde app is die gebruikers regelmatig gebruiken. Als een gebruiker meer details nodig heeft, kunnen selecties van de geaggregeerde app aan een detail-app worden doorgegeven, zodat hij een lager niveau van gedetailleerdheid kan bekijken. Dit bespaart geheugen, omdat gebruikers niet onnodige details laden. Het koppelen van applicaties kan worden uitgevoerd door knopobjecten toe te voegen aan een werkblad.Ga voor meer informatie naar . For more information, see Knop.Applicaties koppelen
Het koppelen van applicaties wordt ook ondersteund door APIs. U kunt bijvoorbeeld de App Integration API gebruiken om applicaties aangepast te koppelen. Ga voor meer informatie naar App Integration API (alleen in het Engels).
Dynamische weergaven
Dynamische weergaven tonen actuele visualisaties in scenario's met veel of snel veranderende gegevens. Houd rekening met het volgende als u werkt met dynamische weergaven:
Als u dynamische weergaven bijwerkt, wordt de gegevensbron direct geladen. De prestaties van het bijwerken worden beïnvloed door de prestaties van de onderliggende gegevensbron.
Sjabloon-apps voor dynamische weergaven helpen bij het maken van dynamische diagrammen.
Voor informatie over het gebruik van dynamische weergaven, gaat u naar Gegevens beheren met dynamische weergaven.
Direct Query
In-geheugen apps worden aangeraden, maar met Direct Query kunt u gegevens in de oorspronkelijke bron bewaren. Houd rekening met het volgende om uw gebruik van Direct Query te optimaliseren:
De prestaties van Direct Query worden sterk beïnvloed door de prestaties van de onderliggende gegevensbron.
Houd uw Direct Query-gegevensmodel zo eenvoudig mogelijk, omdat complexe query's mogelijk prestatieproblemen veroorzaken.
Ga voor meer informatie over Direct Query naar Clouddatabases direct openen met Direct Query.
Prestaties van een gegevensmodel
Dit zijn indicatoren die van invloed kunnen zijn op de prestaties van een gegevensmodel. Elke indicator zal de bruikbaarheid van de app verbeteren.
| Actie | Beschrijving |
|---|---|
Synthetische sleutels zijn verwijderd | Qlik Sense maakt synthetische sleutels als in twee of meer gegevenstabellen twee of meer velden gelijk zijn. Dit betekent dat er in het script of het gegevensmodel een fout aanwezig is. Zie Synthetische sleutels voor meer informatie over de diagnose van synthetische sleutels. |
Cirkelreferenties die uit een gegevensmodel zijn verwijderd | Cirkelreferenties ontstaan wanneer twee velden over meer dan één koppeling beschikken. Qlik Sense probeert dit op te lossen door de koppeling met een van de tabellen te wijzigen. Alle cirkelreferenties moeten echter worden opgelost, zie Cirkelreferenties begrijpen en oplossen. |
Juiste gedetailleerdheid van gegevens | U moet alleen noodzakelijke gegevens laden. Bijvoorbeeld: voor een groep gebruikers hoeven gegevens alleen te worden gesorteerd op week, maand en jaar. U kunt de geaggregeerde gegevens inladen of de gegevens binnen het load-script aggregeren om geheugen te besparen. Als een gebruiker gegevens met minder gedetailleerdheid wil visualiseren, kunt u ODAG of documentkoppeling gebruiken. |
Gebruik indien mogelijk QVDs | Een QVD is een bestand dat een tabel bevat met gegevens die vanuit Qlik Sense zijn geëxporteerd. De bestandsindeling is geoptimaliseerd om snel gegevens in een script te kunnen lezen, maar is toch zeer compact. Gegevens uit een QVD-bestand worden 10-100 keer sneller gelezen dan gegevens uit een andere gegevensbron. Ga voor meer informatie naar: Werken met QVD-bestanden. |
Optimaliseer QVD-bestanden voor laden | QVD-bestanden kunnen in twee modi worden gelezen: standaard (snel) en geoptimaliseerd (sneller). De geselecteerde modus wordt automatisch bepaald door de script-engine. Geoptimaliseerd laden heeft enkele beperkingen. Het is mogelijk om de naam van velden te wijzigen, maar deze bewerkingen resulteren in standaard laden:
|
Incrementeel laden toepassen | Als uw app is gekoppeld aan een grote hoeveelheid gegevens uit databasebronnen die continu worden bijgewerkt, kan het opnieuw laden van de gehele gegevensverzameling veel tijd kosten. Gebruik in plaats daarvan incrementeel laden om nieuwe of gewijzigde records op te halen uit de database. Ga voor meer informatie naar Nieuwe en bijgewerkte records laden via incrementeel laden. |
Snowflake -model wordt geconsolideerd | Als u een Snowflake-gegevensmodel hebt, kunt het aantal gegevenstabellen verminderen door enkele ervan samen te voegen met het prefix Join of andere toewijzingsvormen. Dit komt met name van pas bij grote feitentabellen. Een goede vuistregel is om gebruik te maken van één grote tabel. Ga voor meer informatie naar Wel of niet samenvoegen. |
Tabellen met een klein aantal velden worden gedenormaliseerd | Als u twee tabellen met enkele velden hebt, kunt u deze samenvoegen om de prestaties te verbeteren. Ga voor meer informatie naar Tabellen samenvoegen met Join en Keep. |
Gedenormaliseerde opzoektabellen met toegewezen ladingen | Gebruik het Join -prefix niet als u slechts één veld van een tabel aan een andere tabel wilt toevoegen. Gebruik de ApplyMap-opzoekfunctie, zie Niet samenvoegen - gebruik ApplyMap. |
Tijdstempels die zijn verwijderd of ontkoppeld van een datumveld | Gegevensvelden kunnen ruimte innemen als er gebruik wordt gemaakt van een tijdstempel. De tekenreeks en het aantal afzonderlijke waarden zijn dan groter. Als nauwkeurigheid niet geboden is voor uw analyse, kunt u het tijdstempel bijvoorbeeld naar boven afronden op het hele uur met behulp van Timestamp(Floor(YourTimestamp,1/24)) of het tijdelement volledig verwijderen met behulp van Date(Floor(YourTimestamp)). Als u gebruik wilt maken van de tijdstempel, kunt u deze van de datum loskoppelen. U kunt dezelfde Floor()-functie gebruiken en vervolgens een nieuw veld met de geëxtraheerde tijd maken door bijvoorbeeld het volgende toe te passen: Time(Frac(YourTimestamp)). |
Niet-noodzakelijke velden uit gegevensmodel verwijderen | Laad alleen noodzakelijke velden in uw gegevensmodel. Vermijd het gebruik van Load * en SELECT. Behoud de volgende elementen:
|
Vermijd koppelingstabellen in het geval van grote hoeveelheden gegevens | Gebruik indien mogelijk koppelingstabellen. Als u echter te maken hebt met grote hoeveelheden gegevens, kunnen samengevoegde tabellen beter presteren dan koppelingstabellen. |
Samengevoegde dimensies opdelen in nieuwe velden | U moet samengevoegde dimensies opdelen in afzonderlijke velden. Dit vermindert het aantal unieke waarden in uw velden. Dit is vergelijkbaar met de manier waarop tijdstempels kunnen worden geoptimaliseerd. |
Gebruik indien mogelijk AutoNummering | U kunt een geoptimaliseerde lading maken door de gegevens eerst op te halen vanuit een QVD-bestand. Vervolgens kunt u de instructie AutoNummering gebruiken om de waarden naar symboolsleutels te converteren. Ga voor meer informatie naar AutoNumber. |
Vermijd gegevenseilanden | Gegevenseilanden kunnen nuttig zijn, maar ze hebben meestal een negatieve invloed op de prestaties. Als u eilanden maakt voor selectiewaarden, gebruik dan variabelen. |
QVD's worden opgeslagen op basis van incrementele tijdsperioden | U moet QVD in segmenten opslaan, zoals maandelijks. Deze kleinere maandelijkse QVD kan vervolgens veel verschillende apps ondersteunen die mogelijk niet alle gegevens nodig hebben. |
Prestaties van werkbladen
Dit zijn de beste praktijken waarmee de prestaties van werkbladen en visualisaties worden verbeterd.
| Actie | Beschrijving |
|---|---|
Vermijd indien mogelijk de If()-functie | Als de If()-functie wordt gebruikt binnen een aggregatiefunctie, wordt deze op recordniveau uitgevoerd en meerdere keren geëvalueerd. Als u bijvoorbeeld een aggregatie met 1000 records hebt, wordt een If()-voorwaarde 1000 keer geëvalueerd. Dit kan snel uit de hand lopen bij het nesten van instructies. Gebruik in plaats daarvan een set-analyse. Voorafgaand aan de aggregatie wordt een filter voor de set-analyse toegepast, dit zorgt voor snellere reacties. Deze reacties kunnen ook via een set-analyse worden gecachet, dit is niet mogelijk met de If()-functie. U kunt ook overwegen andere functies te gebruiken of het gegevensmodel aan te passen. |
| Vermijd indien mogelijk velden van andere tabellen in een aggregatietabel. | Als een aggregatie wordt geëvalueerd, wordt de berekening in twee stappen uitgevoerd:
Het gedeelte met enkele threads kan een aanzienlijke invloed hebben op de prestaties. Zo kunt u meerdere velden in een aggregatie hebben, zoals Sum(Quantity*ListPrice). Als Quantity zich in de feitentabel bevindt en ListPrice zich in de hoofdproductentabel bevindt, moet de engine de twee tabellen eerst samenvoegen om de combinaties te vinden voordat de som het product kan worden berekend. Het samenvoegen vindt enkel-threaded plaats en de som berekenen vindt multi-threaded plaats. Als beide velden zich in dezelfde tabel bevinden is het samenvoegen niet nodig en wordt de aggregatie aanzienlijk sneller geëvalueerd. |
Aggr() en geneste Aggr()-functies worden zo min mogelijk gebruikt | De Aggr()-functie heeft aanzienlijk veel invloed op prestaties. Incorrect gebruik kan leiden tot onnauwkeurige resultaten. Bijvoorbeeld in een tabel waarbij de dimensies afwijken van de dimensies binnen de Aggr()-functie. Ga voor meer informatie naar Wanneer moet ik AGGR niet gebruiken? |
Gebruik indien mogelijk set-analyse | U kunt set-analyse gebruiken om een set van gegevenswaarden te definiëren die verschilt van de normale set die wordt gedefinieerd door de huidige selecties. Ga voor meer informatie naar Set-analyse. |
Vermijd indien mogelijk tekenreeksvergelijkingen | Tekenreeksvergelijkingen zijn minder efficiënt dan set-analyses. Vermijd bijvoorbeeld Match(), MixMatch(), WildMatch() en Pick(). Gebruik in plaats daarvan markeringen in het script of gebruik de set-analyse. Ga voor meer informatie naar Voorwaardenfuncties en Prestaties van conditionele aggregaties. |
Berekeningsvoorwaarden worden gebruikt voor objecten die uitgebreide berekeningen bevatten | Visualisaties kunnen veel records bevatten als er geen selecties gemaakt zijn. U kunt dan het beste berekeningsvoorwaarden toevoegen aan objecten zodat ze alleen worden gegenereerd nadat bepaalde selecties zijn gemaakt. Hierdoor worden geen zeer grote hyperkubussen gemaakt. Bijvoorbeeld: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. In dit scenario zal de visualisatie niet worden gegenereerd tenzij de gebruiker één land selecteert of andere selecties maakt waarbij één land mogelijk is. |
Metingen worden indien mogelijk vooraf berekend in het script | Elke meting met de laagste gedetailleerdheid binnen het gegevensmodel moet worden berekend in het script. Als u bijvoorbeeld in hetzelfde record in een tabel Sales en Cost hebt, kunt u de marge afleiden door Sales - Cost AS Margin te berekenen. U kunt ook vooraf andere waarden aggregeren als u weet dat ze op basis van een selectie niet zullen variëren of als ze aan een ander niveau van gedetailleerdheid zijn gekoppeld. |
Tabellen bevatten minder dan 15 kolommen en bevatten berekeningsvoorwaarden | Een tabel met 15 kolommen kan als breed beschouwd worden. Als uw tabellen veel records bevatten, moet u berekende voorwaarden op het tabelobject gebruiken zodat deze alleen wordt gegenereerd nadat er aan bepaalde selecties of voorwaarden is voldaan. Overweeg het volgende als uw tabel zeer breed is:
|
Werkbladen bevatten geen overmatige hoeveelheid objecten | Objecten worden berekend als de gebruiker naar het werkblad navigeert. Elke keer dat een gebruiker een selectie in het werkblad maakt, wordt elk object opnieuw berekend als de huidige status niet bestaat in de cache. Als u een werkblad hebt dat veel diagrammen bevat, moet de gebruiker bij elk object wachten totdat vrijwel elke selectie is berekend. Hierdoor wordt de engine aanzienlijk belast. U kunt het beste het Dashboard/Analysis/Reporting (DAR) -concept volgen om een opgeschoonde en minimale app te ontwikkelen. Ga voor meer informatie naar DAR-methodologie. |
Numerieke markeringen worden toegepast in het script voor gebruik in set-analyses | Set-analyses met markeringen kunnen efficiënter zijn dan wanneer u tekenreeksvergelijkingen of vermenigvuldigingen gebruikt. |
Masteritems of variabelen die worden gebruikt voor uitdrukkingen | Met masteritems kunt u beheerde metrische gegevens slepen en neerzetten en wordt gegarandeerd dat uitdrukkingen in de cache worden geplaatst. Sum(Sales) is bijvoorbeeld anders dan SUM(Sales). Uitdrukkingen worden in de cache geplaatst op basis van spelling en ze zijn hoofdlettergevoelig. Ze moeten woord voor woord overeenkomen om opnieuw gebruikt te kunnen worden. |
Prestaties van gegevensladingen
Het optimaliseren van de gegevenslading is belangrijk voor een naadloze en responsieve ervaring bij het werken met apps in Qlik Cloud. In deze sectie wordt dieper ingegaan op factoren die de prestaties beïnvloeden en biedt richtlijnen om prestatieproblemen te voorkomen.
Qlik Gegevensgateway - Directe toegang
Als u Qlik Gegevensgateway - Directe toegang gebruikt om gegevens te laden in uw app, hebben de volgende factoren invloed op de prestaties:
De verbindingssnelheid en latentie tussen de machine die de gegevensgateway host en de database.
De verbindingssnelheid en latentie tussen de machine die de gegevensgateway host en uw Qlik Cloud-tenant. Het beste is om de gegevensgateway te hosten in dezelfde regio als uw Qlik Cloud-tenant voor verbeterde prestaties.
Databaseopslag
Door langzame opslagverbindingen kunnen de laadtijden toenemen. Houd rekening met het volgende bij databases die on-premises of in de cloud worden gehost:
On-premises: Als uw database zich on-premises bevindt en een server deelt met andere applicaties, worden de prestaties mogelijk beïnvloed door de activiteiten van deze andere applicaties.
Cloud: Als clouddatabases de juiste omvang hebben, dan presteren ze doorgaans beter dan on-premises databases. Voor optimale resultaten kiest u een regio voor cloudopslag die zich in de buurt van de Qlik Cloud-tenant bevindt.