Optimizing app performance
Le prestazioni delle app possono essere migliorate riducendone le dimensioni, semplificando i modelli dati e mediante l'uso strategico di Set Analysis. Questa sezione contribuisce a evitare problemi di prestazioni indicando aree con un potenziale impatto sulle prestazioni e segnalando come valutare e monitorare le prestazioni delle app.
È possibile analizzare il funzionamento della propria app mediante lo strumento di valutazione prestazioni. Per ulteriori informazioni, vedere Valutazione prestazioni app.
Complessità delle app
Di seguito sono riportate le categorie isolate che possono contribuire a diagnosticare problemi. Le app più complesse forniscono prestazioni inferiori.
App semplici:
- Non includono Set Analysis complesse o istruzioni If().
- Non includono tabelle di grandi dimensioni.
- Utilizzano un modello dati semplice.
- Includono calcoli semplici.
- Possono presentare grandi volumi di dati.
App medie:
- Presentano un modello dati con molte tabelle, ma seguono le procedure consigliate.
- Utilizzano Set Analysis e svariate istruzioni If().
- Presentano tabelle grandi o ampie sui fogli (almeno 15 colonne).
App complesse:
-
Presentano un modello dati molto complesso.
- Si connettono a grandi volumi di dati.
- Contengono calcoli, grafici e tabelle complessi.
Grandi volumi di dati
Tali strategie di architettura possono essere impiegate al momento di connettersi a grandi volumi di dati.
Segmentazione
È possibile segmentare QVDs in base alle dimensioni, come un intervallo di tempo, una regione o un livello di aggregazione. Ad esempio, è possibile avere:
- Un QVD contenente dati relativi ai due anni più recenti.
- Un QVD contenente dati cronologici che si spingono oltre quei due anni.
Un QVD contenente tutti i dati aggregati su un livello superiore. Ad esempio, per mese invece della data o per paese invece di singoli clienti.
- Un QVD di grandi dimensioni con tutti i dati, utilizzato solo da un piccolo sottogruppo di utenti.
È possibile segmentare le app in un modo simile. Le app più piccole risponderanno alle esigenze analitiche di gran parte degli utenti. Ciò consente di risparmiare memoria.
È inoltre possibile avere più app focalizzate su regioni diverse. In questo modo, gli utenti non apriranno un'app con dati a cui non sono interessati o per i quali non dispongono dei diritti di accesso. I dati non accessibili tramite Section Access hanno comunque un impatto sulla memoria.
Generazione di app on-demandODAG
Le app on-demand di Qlik Sense forniscono agli utenti viste aggregate degli archivi di big data. Possono identificare e caricare sottogruppi rilevanti di dati per svolgere analisi dettagliate.
Dalla prospettiva di un utente, sono presenti due app:
- Un carrello con dati aggregati.
- Un'app modello vuota utilizzata per visualizzare i dettagli.
L'utente effettua selezioni nell'app del carrello. Una volta raggiunta una soglia, viene creato uno script LOAD personalizzato che popola l'app modello con i dettagli richiesti. Per ulteriori informazioni, vedere Gestione dei big data con le app on demand.
Concatenamento di applicazioni
Il concatenamento di applicazioni (noto come concatenamento di documenti in QlikView) prevede la presenza di un'app aggregata, che gli utenti utilizzano regolarmente. Se un utente richiede maggiori dettagli, è possibile inoltrare le selezioni dall'app aggregata a un'app dettagliata, in modo da consentire la visualizzazione di un livello inferiore di granularità. Ciò consente di risparmiare memoria, dato che gli utenti non caricano dettagli non necessari. Il concatenamento di applicazioni può essere eseguito aggiungendo oggetti pulsante a un foglio. Per ulteriori informazioni, vedere Concatenamento di applicazioni.
Il concatenamento di applicazioni è supportato anche tramite APIs. Ad esempio, è possibile usare le App Integration API per creare un concatenamento di app personalizzato. Per ulteriori informazioni, vedere App Integration API (solo in lingua inglese).
Viste dinamiche
Le viste dinamiche consentono visualizzazioni aggiornate per volumi elevati di dati o scenari di dati in rapida evoluzione. Quando si utilizzano le viste dinamiche, tenere presente quanto segue:
Quando si aggiornano le viste dinamiche, la sorgente dati viene caricata direttamente. Le prestazioni di aggiornamento sono condizionate dalla sorgente dati sottostante.
Le app modello delle viste dinamiche consentono agli utenti di creare grafici dinamici.
Per maggiori informazioni sull'utilizzo delle viste dinamiche, vedere Gestione dei dati con viste dinamiche.
Direct Query
Sebbene si consigli l'utilizzo di app in memoria, Direct Query consente di mantenere i dati nella sorgente originale. Per ottimizzare l'utilizzo di Direct Query, tenere presente quanto segue:
Le prestazioni di Direct Query sono fortemente condizionate dalla sorgente dati sottostante.
Mantenere il modello dati di Direct Query il più semplice possibile, poiché le query complesse possono causare problemi alle prestazioni.
Per maggiori informazioni su Direct Query, vedere Accesso ai database cloud direttamente con Direct Query.
Prestazioni del modello dati
Gli indicatori riportati di seguito possono avere un impatto sulle prestazioni del modello dati. Ciascuno rappresenta una procedura consigliata che migliorerà l'usabilità delle app.
| Azione | Descrizione |
|---|---|
Rimozione delle chiavi sintetiche | Qlik Sense crea chiavi sintetiche quando due o più tabelle di dati hanno due o più campi in comune. Ciò può significare che è presente un errore nello script o nel modello dati. Per sottoporre a diagnosi le chiavi sintetiche, vedere Chiavi sintetiche. |
Rimozione dei riferimenti circolari dal modello dati | I riferimenti circolari si verificano quando due campi presentano più di un'associazione. Qlik Sense cercherà di risolverli modificando la connessione a una delle tabelle. Tuttavia, è consigliabile risolvere tutti gli avvisi relativi a riferimenti circolari, vedere Comprensione e risoluzione dei riferimenti circolari. |
Granularità appropriata dei dati | Si consiglia di caricare soltanto i dati necessari. Ad esempio: un gruppo di utenti necessita soltanto di dati divisi per settimana, mese e anno. È possibile caricare i dati aggregati o aggregare i dati all'interno dello script di caricamento per risparmiare memoria. Se un utente necessita di visualizzare i dati a un livello di granularità inferiore, è possibile utilizzare ODAG o il concatenamento dei documenti. |
Utilizzo dei QVDs laddove possibile | Un QVD è un file contenente una tabella di dati esportati da Qlik Sense. Questo formato di file è ottimizzato per la velocità di lettura dei dati da uno script, rimanendo comunque molto compatto. La lettura di dati da un file QVD è in genere 10-100 volte più veloce rispetto alla lettura da altre sorgenti dati. Per ulteriori informazioni, vedere Utilizzo dei file QVD. |
Ottimizzazione dei file QVD al caricamento | I file QVD possono essere letti in due modalità: standard (veloce) e ottimizzata (più veloce). La modalità selezionata viene determinata automaticamente dal motore degli script. Vi sono alcune limitazioni riguardo ai caricamenti ottimizzati. È possibile rinominare i campi, tuttavia ognuna di queste operazioni comporterà un caricamento standard:
|
Utilizzo di carichi incrementali | Se la propria app si connette a un numero elevato di dati provenienti da database in costante aggiornamento, il ricaricamento dell'intera serie di dati può richiedere diverso tempo. È invece consigliabile utilizzare il carico incrementale per recuperare record nuovi o modificati dal database. Per ulteriori informazioni, vedere Caricamento di record nuovi e aggiornati mediante il carico incrementale. |
Consolidamento del modello Snowflake | Se si dispone di un modello dati snowflake, potrebbe essere necessario ridurre il numero di tabelle dati unendone alcune mediante il prefisso Join o un'altra mappatura. Ciò risulta particolarmente importante per le grandi tabelle dei fatti. In genere è preferibile avere solo una grande tabella. Per ulteriori informazioni vedere Unire o non unire. |
Denormalizzazione delle tabelle con un numero ridotto di campi | Se si dispone di due tabelle con pochi campi, la loro unione potrebbe migliorare le prestazioni. Per ulteriori informazioni, vedere Combinazione di tabelle con Join e Keep. |
Denormalizzazione delle tabelle di ricerca (foglia) con carichi di mappatura | È consigliabile non utilizzare il prefisso Join se è necessario aggiungere un solo campo da una tabella a un'altra. Si consiglia invece di utilizzare la funzione di ricerca ApplyMap , vedere Non unire - utilizzare ApplyMap. |
Rimozione o disaccoppiamento delle indicazioni di data/ora dal campo data | I campi data possono riempire lo spazio in presenza di un'indicazione di data/ora, dato che la rappresentazione stringa è più grande, così come il numero di valori distinti. Se la precisione non è necessaria per la propria analisi, è possibile arrotondare l'indicazione di data/ora, p. es. all'ora più vicina, usando Timestamp(Floor(YourTimestamp,1/24)) oppure rimuovendo completamente il componente ora usando Date(Floor(YourTimestamp)). Se non si desidera l'indicazione di data/ora, è possibile disaccoppiarla dalla data stessa. È possibile utilizzare la stessa funzione Floor(), dopodiché creare un nuovo campo con l'ora estratta usando qualcosa di simile a: Time(Frac(YourTimestamp)). |
Rimozione di campi non necessari dal modello di dati | Si consiglia di caricare soltanto i campi necessari nel proprio modello di dati. Evitare l'utilizzo di Load * e SELECT. Assicurarsi di mantenere:
|
Esclusione delle tabelle dei collegamenti al momento di occuparsi di grandi volumi di dati | Laddove possibile, utilizzare le tabelle dei collegamenti. Tuttavia, se ci si sta occupando di grandi volumi di dati, le tabelle concatenate possono fornire prestazioni migliori rispetto alle tabelle dei collegamenti. |
Scomposizione delle dimensioni concatenate in nuovi campi | Si consiglia di scomporre le dimensioni concatenate in campi separati. Tale operazione riduce il numero di occorrenze univoche dei valori nei propri campi. Ciò risulta simile al modo in cui è possibile ottimizzare le indicazioni di data e ora. |
Utilizzo di AutoNumber laddove possibile | È possibile creare un caricamento ottimizzato caricando prima i dati da un file QVD e poi utilizzando l'istruzione AutoNumber per convertire i valori in chiavi di simboli. Per ulteriori informazioni, vedere AutoNumber. |
Esclusione delle isole di dati | Le isole di dati possono risultare utili, ma in genere influiscono negativamente sulle prestazioni. Se si stanno creando isole per i valori di selezione, utilizzare le variabili. |
Archiviazione di QVD in base a intervalli di tempo incrementali | Si consiglia di archiviare i QVD in segmenti, ad esempio mensili. I QVD mensili, di dimensioni ridotte, possono quindi supportare più app diverse che potrebbero non necessitare di tutti i dati. |
Prestazioni dei fogli
Di seguito vengono riportate procedure consigliate che miglioreranno le prestazioni di fogli e visualizzazioni.
| Azione | Descrizione |
|---|---|
Esclusione della funzione If() laddove possibile | Se la funzione If() viene utilizzata all'interno di una funzione di aggregazione, opererà a livello di record e verrà valutata molte volte. Ad esempio, se si dispone di 1000 record in un'aggregazione, una condizione If() verrà valutata 1000 volte. Tale situazione potrebbe incrementare rapidamente in presenza di istruzioni nidificate. Si consiglia invece l'utilizzo di Set Analysis. L'applicazione di un filtro Set Analysis avviene prima dell'aggregazione, comportando una risposta più rapida. Tali risposte possono anche essere memorizzate nella cache mediante Set Analysis, a differenza di If(). È inoltre possibile considerare altre funzioni e modifiche al modello dati. |
| I campi da tabelle diverse all'interno di una tabella di aggregazione vengono evitati ove possibile. | Quando viene valutata un'aggregazione, il calcolo attraversa due passaggi:
La parte a thread singolo può influire considerevolmente sulle prestazioni. Un esempio riguarda la presenza di più campi all'interno dell'aggregazione, ad esempio Sum(Quantity*ListPrice). Se Quantity si trova nella tabella dei fatti, e ListPrice è contenuto nella tabella dei prodotti principali, per prima cosa l'engine ha bisogno di unire le due tabelle per trovare le combinazioni prima che possa iniziare a sommare il prodotto. L'unione è la parte a thread singolo, mentre la somma è a thread multiplo. Se entrambi i campi si trovano nella stessa tabella, non è necessaria alcuna unione, e l'aggregazione è valutata in modo considerevolmente più rapido. |
Utilizzo minimo delle funzioni Aggr() e Aggr() nidificate | La funzione Aggr() influisce enormemente sulle prestazioni. Un utilizzo errato può fornire risultati imprecisi. Ad esempio, in una tabella con dimensioni diverse rispetto alle dimensioni all'interno della funzione Aggr(). Per ulteriori informazioni, vedere Quando non dovrebbe essere utilizzata la funzione AGGR? |
Utilizzo di Set Analysis laddove possibile | È possibile utilizzare Set Analysis per definire una serie di valori di dati diversa dalla serie standard definita dalle selezioni correnti. Per ulteriori informazioni, vedere Analisi di gruppo. |
Esclusione dei confronti tra stringhe laddove possibile | I confronti tra le stringhe non sono efficaci tanto quanto Set Analysis. Ad esempio, è consigliabile evitare Match(), MixMatch(), WildMatch() e Pick(). Creare contrassegni nello script oppure utilizzare Set Analysis. Per ulteriori informazioni, vedere Funzioni condizionali e Prestazioni delle aggregazioni condizionali. |
Utilizzo delle condizioni di calcolo sugli oggetti contenenti calcoli intensivi | È possibile disporre di visualizzazioni con molti record in assenza di selezioni. Come procedura consigliata, aggiungere condizioni di calcolo agli oggetti, in modo che il loro rendering possa avvenire solo dopo aver effettuato determinate selezioni. Ciò impedisce la creazione di ipercubi di dimensioni molto elevate. Ad esempio: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. In questo scenario, la visualizzazione non presenterà un rendering a meno che l'utente non selezioni un singolo paese, oppure effettui altre selezioni in cui è possibile un solo paese. |
Precalcolo delle misure nello script laddove possibile | Nello script si consiglia di calcolare qualsiasi misura che si trova al livello inferiore di granularità del modello dati. Ad esempio, se nello stesso record in una tabella si dispone di Sales e Cost, è possibile derivare il margine calcolando il Sales - Cost AS Margin. È anche possibile aggregare altri valori in anticipo se non varieranno in base alla selezione, oppure valori vincolati a un livello diverso di granularità. |
Tabelle con meno di 15 colonne e condizioni di calcolo | Una tabella con 15 colonne può essere considerata ampia. Se le proprie tabelle sono composte da molti record, è consigliabile utilizzare le condizioni calcolate su tale oggetto di tabella in modo che il rendering avvenga solo dopo aver soddisfatto determinate selezioni o criteri. Se la propria tabella è molto ampia, considerare quanto segue:
|
Fogli che non presentano un numero eccessivo di oggetti | Gli oggetti vengono calcolati quando l'utente naviga nel foglio. Ogni volta che un utente effettua una selezione in tale foglio, se tale stato corrente non esiste nella cache, ciascun oggetto verrà ricalcolato. Se si dispone di un foglio con molti grafici, l'utente dovrà attendere che venga calcolato ogni oggetto in quasi ogni selezione Ciò comporta un carico significativo sul motore. Come procedura consigliata, seguire il concept Dashboard/Analysis/Reporting (DAR) per sviluppare un'app pulita e minimale. Per ulteriori informazioni, vedere Metodologia DAR. |
Sfruttamento dei contrassegni numerici nello script per l'uso in Set Analysis | Set Analysis può risultare più efficiente con dei contrassegni rispetto all'utilizzo di confronti o della moltiplicazione di stringhe. |
| Le voci principali consentono il trascinamento delle metriche governate e garantiscono la memorizzazione nella cache delle espressioni. Ad esempio, Sum(Sales) risulta diverso da SUM(Sales). Le espressioni vengono memorizzate nella cache mantenendo ortografia e uso di maiuscole e minuscole, pertanto devono corrispondere esattamente per poter essere riutilizzate. |
Prestazioni di caricamento dati
L'ottimizzazione del caricamento dati è importante per un'esperienza fluida e reattiva quando si utilizzano app in Qlik Cloud. In questa sezione vengono illustrati i fattori che influenzano le prestazioni e viene fornita una guida su come evitare i relativi problemi.
Qlik Data Gateway - Direct Access
Quando si utilizza Qlik Data Gateway - Direct Access per ricaricare i dati nella propria app, i seguenti fattori possono influenzare le prestazioni:
La velocità e la latenza della connessione tra il computer che ospita il gateway dati e il database.
La velocità e la latenza della connessione tra il computer che ospita il gateway dati ed il tenant Qlik Cloud. Per un utilizzo ideale e prestazioni ottimizzate, ospitare il gateway dati nella stessa area geografica del tenant Qlik Cloud.
Archiviazione del database
Le connessioni di archiviazione lente possono aumentare i tempi di ricaricamento. Per i database ospitati in loco o sul cloud, tenere presente quanto segue:
In loco: se si dispone di un database in loco che condivide un server con altre applicazioni, le relative prestazioni possono essere influenzate dalle attività di tali applicazioni.
Cloud: quando sono dimensionati correttamente, i database cloud di norma forniscono migliori prestazioni rispetto a quelli in loco. Per risultati ottimali, scegliere una regione per l'archiviazione che sia vicina al tenant Qlik Cloud.