Optimera appens prestanda
Du kan förbättra appens prestanda genom att minska dess storlek, använda enklare datamodeller och genom strategisk användning av set-analys. I det här avsnittet beskrivs vilka områden som kan påverka prestandan så att du kan undvika prestandaproblem, och hur du kan utvärdera och övervaka appens prestanda.
Du kan se appens prestanda med verktyget för prestandautvärdering. Mer information finns i Prestandautvärdering för appar.
Appens komplexitet
Här följer några kategorier som kan hjälpa dig att diagnostisera problem. De mest komplexa apparna har sämst prestanda.
Enkla appar:
- innehåller inte komplexa set-analys- eller If()-satser
- innehåller inte stora tabeller
- har en enkel datamodell
- innehåller enkla beräkningar
- kan använda stora datavolymer.
Medelkomplexa appar:
- har en datamodell med många tabeller, men är uppbyggda enligt bästa praxis
- använder set-analys och flera If()-satser
- har stora och breda tabeller på ark (15 kolumner och uppåt).
Komplexa appar:
-
har en mycket komplex datamodell
- kopplar till stora datavolymer
- innehåller komplexa beräkningar, diagram och tabeller.
Stora datavolymer
Följande arkitekturstrategier kan du använda när du kopplar till stora datavolymer.
Segmentering
Du kan segmentera QVDs efter dimensioner som tidsram, region eller aggregeringsnivå. Du kan till exempel ha
- en QVD som innehåller data från de två senaste åren
- en QVD som innehåller historiska data från mer än två år tillbaka
en QVD som innehåller alla data som har aggregerats på en högre nivå. Till exempel per månad istället för datum, eller per land istället för individuella kunder.
- en stor QVD med alla data, som bara används av en liten grupp av användarna.
Du kan segmentera apparna på ett liknande sätt. För de flesta användare kan en mindre app tillgodose analysbehoven. Detta sparar minne.
Du kan även ha flera appar som fokuserar på olika regioner. På så sätt kommer inte användarna att öppna appar med data de inte är intresserade av eller inte har åtkomst till. Även data som inte är tillgängliga via section access påverkar minnesanvändningen.
Generera on-demand-appar (ODAG)
On-demand-appar i Qlik Sense ger användare aggregerade vyer av stora databaser. De kan identifiera och ladda relevanta underuppsättningar av data för analys på detaljnivå.
Ur användarens perspektiv finns det två appar:
- en varukorg med aggregerade data
- en tom mallapp som används för att visa information på detaljnivå.
Användaren gör urval i varukorgsappen. När en tröskel nås, skapas ett anpassat LOAD-skript som fyller mallappen med den begärda informationen. Mer information finns i Hantera stora datamängder med on-demand-appar.
Programkedja
Programkedjor (kallat dokumentkedjor i QlikView) innebär att det finns en aggregerad app som används ofta av användarna. Om en användare behöver mer detaljerad information kan urval överföras från den aggregerade appen till en detaljapp, där fler detaljer kan visas. Detta sparar minne eftersom användarna inte laddar information de inte behöver. Programkedjor kan utföras genom att lägga till knappobjekt i ett ark. Mer information finns i Programkedja.
Programkedjor stöd också via APIs. Du kan till exempel använda App Integration API för att skapa anpassade programkedjor. Mer information finns i App Integration API (endast på engelska).
Dynamiska vyer
Med dynamiska vyer kan aktuella datavisualiseringar för stora datavolymer eller datascenarier som ändras snabbt. Beakta följande när du arbetar med dynamiska vyer:
När du uppdaterar dynamiska vyer laddas datakällan direkt. Uppdateringsprestandan påverkas av den underliggande datakällans prestanda.
Mallappar för dynamiska vyer kan hjälpa dig att skapa dynamiska diagram.
Mer information om hur du använda dynamiska vyer finns i Hantera data med dynamiska vyer.
Direct Query
Appar i minnet rekommenderas, men med Direct Query kan du även behålla data i dess ursprungliga källa. Beakta följande för att optimera din användning av Direct Query:
Direct Querys prestanda påverkas av den underliggande datakällans prestanda.
Håll din Direct Query-datamodell så enkel som möjligt, eftersom komplexa frågor kan leda till prestandaproblem.
Mer information om Direct Query finns i Åtkomst till molndatabaser direkt med Direct Query.
Datamodellens prestanda
Följande är faktorer som kan påverka datamodellens prestanda. De är alla rekommenderade metoder som gör appen mer användbar.
| Åtgärd | Beskrivning |
|---|---|
Ta bort syntetiska nycklar | Qlik Sense skapar syntetiska nycklar när minst två datatabeller har minst två gemensamma fält. Detta kan betyda att skriptet eller datamodellen innehåller ett fel. Om du vill läsa mer om att diagnostisera syntetiska nycklar, se Syntetiska nycklar. |
Ta bort cirkelreferenser från datamodellen | Cirkelreferenser uppstår när två fält har fler än en association. Qlik Sense försöker lösa dessa genom att ändra kopplingen till en av tabellerna. Alla varningar om cirkelreferenser bör dock åtgärdas, se Förstå och lösa cirkelreferenser. |
Lämplig detaljnivå för data | Du ska bara ladda nödvändiga data. Exempel: en grupp användare som bara behöver data indelade efter vecka, månad och år. Du kan antingen ladda aggregerade data, eller aggregera data inom laddningsskriptet för att spara minne. Om en användare behöver visa mer detaljerade data kan du använda ODAG eller dokumentkedjor. |
Använd QVDs när detta är möjligt | En QVD-fil är en fil som innehåller en tabell med data som har exporterats från Qlik Sense. Detta filformat är optimerat för snabb datainläsning från ett skript, men det är ändå mycket kompakt. Datainläsning från en QVD-fil är vanligtvis 10–100 gånger snabbare än inläsning från andra datakällor. Mer information finns i Arbeta med QVD-filer. |
QVD-filer optimeras vid laddning | QVD-filer kan läsas i två olika lägen: standard (snabbt) och optimerat (snabbare). Vilket läge som används bestäms automatiskt av skriptmotorn. Det finns vissa begränsningar för optimerade laddningar. Det går att byta namn på fält, men alla följande operationer resulterar i en standardladdning:
|
Utnyttja inkrementell laddning | Om appen ansluter till stora datamängder från databaser som uppdateras fortlöpande kan det ta lång tid att ladda hela datauppsättningen. Du bör istället hämta nya eller ändrade poster från databasen med inkrementell inläsning. Mer information finns i Ladda nya och uppdaterade poster med inkrementell laddning. |
Snowflake -modell konsolideras | Om du har en Snowflake-datamodell kan du i vissa fall minska antalet datatabeller genom att slå ihop vissa av dem med prefixet Join eller en annan mappning. Detta är särskilt viktigt för stora faktatabeller. En tumregel är att bara ha en stor tabell. Mer information finns i To Join or Not to Join (Använda länkning eller inte). |
Denormalisera tabeller som har få fält | Om du har två tabeller med få fält kan du få bättre prestanda genom att länka dem. Mer information finns här: Kombinera tabeller med Join och Keep. |
Denormalisera leaf-tabeller med mappade laddningar | Du bör inte använda prefixet Join om du bara behöver lägga till ett fält från en tabell i en annan tabell. Du bör använda uppslagsfunktionen ApplyMap, se Don't join - use ApplyMap (Länka inte – använd ApplyMap). |
Ta bort eller frikoppla tidsmarkörer från datumfält | Datumfält kan ta mycket plats om tidsmarkören ingår, eftersom strängen blir längre och antalet distinkta värden är högre. Om inte precisionen är nödvändig för analysen kan du avrunda tidsmarkören till t.ex. den närmaste timmen genom att använda Timestamp(Floor(YourTimestamp,1/24)) eller ta bort tidskomponenten helt med Date(Floor(YourTimestamp)). Om du behöver tidsmarkören kan du frikoppla den från själva datumet. Du kan använda samma Floor()-funktion och sedan skapa ett nytt fält med den extraherade tiden genom att skriva ungefär så här: Time(Frac(YourTimestamp)). |
Ta bort fält som inte behövs från datamodellen | Du bör bara ladda nödvändiga fält i din datamodell. Undvik att använda Load * och SELECT. Se till att behålla:
|
Undvik länktabeller när du arbetar med stora datavolymer | Du bör använda länktabeller när detta är möjligt. Konkatenerade tabeller kan dock vara mer effektiva än länktabeller när du arbetar med stora datavolymer. |
Dela upp konkatenerade dimensioner i nya fält | Du bör dela upp konkatenerade dimensioner i olika fält. Då minskar antalet unika instanser av värden i fälten. Detta fungerar på ungefär samma sätt som hur tidsmarkörer kan optimeras. |
Använd AutoNumber när detta är möjligt | Du kan skapa en optimerad laddning genom att ladda data från en QVD-fil först och sedan använda AutoNumber-påståendet för att konvertera värden till symbolnycklar. Mer information finns här: AutoNumber. |
Undvik dataöar | Dataöar kan vara användbara men för det mesta medför de sämre prestanda. Använd variabler om du skapar öar för urvalsvärden. |
Lagra QVD:er enligt inkrementella tidsramar | Du bör lagra QVD:er i steg, till exempel varje månad. De mindre QVD:erna från varje månad kan sedan användas av många olika appar som kanske inte behöver alla data. |
Arkens prestanda
Här följer metodtips som ger bättre prestanda för ark och visualiseringar.
| Åtgärd | Beskrivning |
|---|---|
Undvik funktionen If() när detta är möjligt | Om funktionen If() används inuti en aggregeringsfunktion fungerar den på postnivå och utvärderas många gånger. Om du till exempel har en aggregering med 1 000 poster utvärderas ett If()-villkor 1 000 gånger. Om du använder nästlade satser kan detta öka mycket snabbt. Du bör använda set-analys istället. Ett set-analys-filter används före aggregeringen, vilket ger snabbare svar. Svaren kan även cachelagras med set-analys, vilket inte är möjligt med If(). Det finns även andra funktioner och ändringar av datamodellen du kan överväga. |
| Undvik, om möjligt, att använda fält från olika tabeller inuti en aggregeringstabell. | När en aggregering utvärderas körs beräkningen i två steg:
Den enkeltrådiga delen kan ha stor inverkan på prestandan. Ett exempel är om du har flera fält inne i aggregeringen, till exempel Sum(Quantity*ListPrice). Om Quantity ligger i faktatabellen och ListPrice ligger i huvudprodukttabellen, måste motorn först länka de två tabellerna för att hitta kombinationerna innan den kan börja summera produkten. Länkningen är den enkeltrådiga delen och summeringen är flertrådig. Om båda fälten ligger i samma tabell behövs ingen länk, och aggregeringen utvärderas mycket snabbare. |
Undvik Aggr() och nästlade Aggr()-funktioner när detta är möjligt | Funktionen Aggr() har stor påverkan på prestanda. Felaktig användning kan ge felaktiga resultat. Till exempel i en tabell med dimensioner som skiljer sig från dimensionerna i Aggr()-funktionen. Mer information finns i When should AGGR not be used? (När ska AGGR undvikas?). |
Använd set-analys när detta är möjligt | Set-analys gör det möjligt att definiera en uppsättning (eller en grupp) av datavärden som är olik den normala uppsättning som definieras av aktuella urval. Mer information finns i Set-analys. |
Undvik strängjämförelser när detta är möjligt | Strängjämförelser är inte lika effektiva som set-analys. Du ska till exempel undvika Match(), MixMatch(), WildMatch() och Pick(). Skapa flaggor i skriptkoden eller använd set-analys istället. Mer information finns i Villkorsfunktioner och Performance of conditional aggregations (Prestanda hos villkorsstyrda aggregeringar). |
Använd beräkningsvillkor för objekt som innehåller stora beräkningar | Du kanske har visualiseringar som innehåller många poster när inga urval har gjorts. Bästa praxis är då att lägga till beräkningsvillkor för objekt så att de bara renderas efter att vissa urval har gjorts. På så sätt undviker du att mycket stora hyperkuber skapas. Till exempel: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. I det här scenariot renderas visualiseringen bara om användaren väljer ett enstaka land, eller gör andra urval om det inte går att välja ett enstaka land. |
Förberäkna mått i skriptet när så är möjligt | Alla mått på den mest detaljerade nivån i datamodellen bör beräknas i skriptet. Om du till exempel har Sales och Cost i samma post i en tabell, kan du ta fram marginalen genom att beräkna Sales - Cost AS Margin. Du kan också aggregera andra värden i förväg om du vet att de inte kommer att variera baserat på urval, eller är bundna till en annan detaljnivå. |
Tabeller har färre än 15 kolumner och har beräkningsvillkor | En tabell med 15 kolumner kan anses vara bred. Om dina tabeller består av många poster bör du använda beräknade villkor för tabellobjektet, så att det bara renderas efter att vissa urval har gjorts eller kriterier har uppfyllts. Om tabellen är mycket bred bör du överväga att:
|
Ark bör inte ha överdrivet många objekt | Objekt beräknas när användaren navigerar till arket. Varje gång en användare gör ett urval på arket beräknas varje objekt igen, om inte det aktuella tillståndet finns i cacheminnet. Om du har ett ark med många diagram måste användaren vänta medan alla objekt beräknas för nästan alla urval. Detta belastar motorn avsevärt. En bra metod för att utveckla en ren och minimal app är att följa konceptet Dashboard/Analysis/Reporting (DAR) . Mer information finns i DAR methodology (DAR-metodik). |
Utnyttja numeriska flaggor i skriptet för användning i set-analys | Set-analys med flaggor kan vara mer effektivt än att använda strängjämförelser eller multiplikation. |
| Med originalobjekt kan du dra och släppa styrda mätetal, och de garanterar att uttryck cachelagras. Till exempel skiljer sig Sum(Sales) från SUM(Sales). Uttryck cachelagras baserat på stavning och gemener/versaler, och återanvänds bara om de matchar exakt. |
Dataladdningens prestanda
Att optimera dataladdningen är viktigt för att arbetet med appar i Qlik Cloud ska fungera sömlöst och responsivt. I det här delavsnittet fokuserar vi på faktorer som påverkar prestanda och ger vägledning om hur prestandaproblem förhindras.
Qlik Data Gateway – direktåtkomst
När du använder Qlik Data Gateway – direktåtkomst för att ladda data i din app påverkas prestandan av följande faktorer:
Anslutningshastigheten och latensen mellan maskinen där datagatewayen är installerad och databasen.
Anslutningshastigheten och latensen mellan maskinen där datagatewayen är installerad och din Qlik Cloud-klientorganisation. I idealfallet är datagatewayen installerad i samma region som din Qlik Cloud-klientorganisation för bättre prestanda.
Databaslagring
Långsamma lagringskopplingar kan medföra längre laddningstider. Beakta följande för databaser som är installerade lokalt eller i molnet:
På plats: Om din databas är installerad lokalt och delar en server med andra applikationer kan dess prestanda påverkas av aktiviteterna på de här andra applikationerna.
Moln: Om storleken är optimal erbjuder molndatabaserna normalt bättre prestanda än lokalt installerade databaser. Välj en region för din molnlagring som ligger nära din Qlik Cloud-klientorganisation för optimala resultat.