Ottimizzazione delle prestazioni dell'applicazione
Le prestazioni dell'Applicazione possono essere migliorate riducendo le dimensioni dell'applicazione, semplificando i modelli dati e utilizzando in modo strategico la set analysis. Questa sezione aiuterà a evitare problemi di prestazioni indicando le aree in cui le prestazioni possono essere compromesse e come valutare e monitorare le prestazioni dell'applicazione.
È possibile monitorare le prestazioni dell'applicazione utilizzando lo strumento di valutazione delle prestazioni e testarne il funzionamento su motori di dimensioni diverse assegnando manualmente motori più grandi. Per ulteriori dettagli, vedere Valutazione delle prestazioni dell'applicazione e Assegnazione di motori per migliorare le prestazioni dell'applicazione.
Complessità dell'applicazione
Queste sono categorie generiche che possono aiutare a diagnosticare i problemi. Le applicazioni più complesse hanno le prestazioni più basse.
Applicazioni semplici:
- Non includono set analysis complesse o istruzioni If().
- Non includono tabelle di grandi dimensioni.
- Hanno un modello dati semplice.
- Contengono calcoli semplici.
- Possono avere grandi volumi di dati.
Applicazioni moderate:
- Hanno un modello dati con molte tabelle, ma seguono le best practice.
- Utilizzano la set analysis e diverse istruzioni If().
- Hanno tabelle grandi o larghe sui fogli (15 colonne o più).
Applicazioni complesse:
-
Hanno un modello dati molto complesso.
- Si connettono a grandi volumi di dati.
- Contengono calcoli, grafici e tabelle complessi.
Grandi volumi di dati
È possibile impiegare queste strategie di architettura quando ci si connette a grandi volumi di dati.
Segmentazione
È possibile segmentare i QVDs per dimensioni come l'intervallo di tempo, la regione o il livello di aggregazione. Ad esempio, è possibile avere:
- Un QVD che contiene i dati degli ultimi due anni.
- Un QVD che contiene dati storici di oltre due anni fa.
-
Un QVD che contiene tutti i dati aggregati a un livello superiore. Ad esempio, per mese invece che per data, o per paese invece che per singoli clienti.
- Un grande QVD con tutti i dati, utilizzato solo da un piccolo sottoinsieme di utenti.
È possibile segmentare le applicazioni in modo simile. Le applicazioni più piccole soddisferanno le esigenze analitiche della maggior parte degli utenti. Questo consente di risparmiare memoria.
È inoltre possibile avere più applicazioni incentrate su regioni diverse. In questo modo, gli utenti non apriranno un'applicazione con dati a cui non sono interessati o a cui non hanno i diritti di accesso. I dati non accessibili tramite section access influiscono comunque sulla memoria.
Generazione di applicazioni on-demand (ODAG)
Le applicazioni on-demand di Qlik Sense offrono agli utenti viste aggregate di archivi di big data. Possono identificare e caricare sottoinsiemi rilevanti dei dati per un'analisi dettagliata.
Dal punto di vista dell'utente, ci sono due applicazioni:
- Un carrello acquisti con dati aggregati.
- Un'applicazione modello vuota utilizzata per visualizzare i dettagli.
L'utente effettua le selezioni nell'applicazione del carrello acquisti. Una volta raggiunta una soglia, viene creato uno script LOAD personalizzato che popola l'applicazione modello con i dettagli richiesti. Per ulteriori informazioni, vedere Gestione dei big data con applicazioni on-demand.
Concatenamento di applicazioni
Il concatenamento di applicazioni (noto come concatenamento di documenti in QlikView) significa che esiste un'applicazione aggregata, che gli utenti consumano regolarmente. Se un utente ha bisogno di maggiori dettagli, le selezioni possono essere passate dall'applicazione aggregata a un'applicazione di dettaglio, in modo che possa visualizzare un livello di granularità inferiore. Questo consente di risparmiare memoria, poiché 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 utilizzare API di integrazione app per creare un concatenamento di applicazioni personalizzato. Per ulteriori informazioni, vedere API di integrazione app (solo in lingua inglese).
Viste dinamiche
Le viste dinamiche consentono visualizzazioni aggiornate per scenari con volumi di dati elevati o dati in rapida evoluzione. Considerare quanto segue quando si lavora con le viste dinamiche:
-
Quando si aggiornano le viste dinamiche, la sorgente dati viene caricata direttamente. Le prestazioni di aggiornamento sono influenzate dalle prestazioni della sorgente dati sottostante.
-
Le applicazioni modello di viste dinamiche possono aiutare a creare grafici dinamici.
Per ulteriori informazioni sull'utilizzo delle viste dinamiche, vedere Gestione dei dati con viste dinamiche.
Direct Query
Sebbene siano consigliate le applicazioni in-memory, Direct Query consente di mantenere i dati nella loro sorgente originale. Considerare quanto segue per ottimizzare l'utilizzo di Direct Query:
-
Le prestazioni di Direct Query sono fortemente influenzate dalle prestazioni della sorgente dati sottostante.
-
Mantenere il modello dati di Direct Query il più semplice possibile, poiché query complesse potrebbero causare problemi di prestazioni.
Per ulteriori informazioni su Direct Query, vedere Accesso diretto ai database cloud 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à dell'applicazione.
| 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, tutti gli avvisi di riferimento circolare devono essere risolti; 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, ma è 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 l'applicazione si connette a una grande quantità di dati da database che vengono continuamente aggiornati, il ricaricamento dell'intero set di dati può richiedere molto 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() e quindi 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. Questi QVD mensili più piccoli possono quindi supportare molte applicazioni diverse che potrebbero non aver bisogno di tutti i dati. |
Prestazioni del foglio
Queste sono le best practice che miglioreranno le prestazioni dei fogli e delle visualizzazioni.
| Azione | Descrizione |
|---|---|
|
La funzione If() viene evitata ove 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 hanno 1000 record in un'aggregazione, una condizione If() verrà valutata 1000 volte. Questo potrebbe avere un effetto a cascata rapido se si annidano le istruzioni. Si dovrebbe invece utilizzare la set analysis. Un filtro di set analysis viene applicato prima dell'aggregazione, risultando in una risposta più rapida. Queste risposte possono anche essere memorizzate nella cache tramite la set analysis, cosa che non è possibile con If(). Si potrebbero anche considerare altre funzioni e modifiche al modello dati. |
| I campi provenienti da tabelle diverse all'interno di una tabella di aggregazione vengono evitati ove possibile. |
Quando viene valutata un'aggregazione, il calcolo passa attraverso due fasi:
La parte a thread singolo può influire notevolmente sulle prestazioni. Un esempio è se si hanno più campi all'interno dell'aggregazione, ad esempio Sum(Quantity*ListPrice). Se Quantity si trova nella tabella dei fatti e ListPrice si trova nella tabella dei prodotti master, il motore deve prima unire le due tabelle per trovare le combinazioni prima di poter iniziare a sommare il prodotto. L'unione è la parte a thread singolo e la somma è multi-thread. Se entrambi i campi si trovano nella stessa tabella, non è necessaria alcuna unione e l'aggregazione viene valutata molto più velocemente. |
|
La funzione Aggr() e le funzioni Aggr() annidate vengono utilizzate in minima parte |
La funzione Aggr() influisce notevolmente sulle prestazioni. Un uso scorretto può fornire risultati imprecisi. Ad esempio, in una tabella con dimensioni che variano rispetto alle dimensioni all'interno della funzione Aggr(). Per ulteriori informazioni, vedere When should AGGR not be used? |
|
La set analysis viene utilizzata ove possibile |
È possibile utilizzare la set analysis per definire un set di valori di dati diverso dal set normale definito dalle selezioni correnti. Per ulteriori informazioni, vedere Analisi di gruppo. |
|
I confronti di stringhe vengono evitati ove possibile |
I confronti di stringhe non sono efficienti quanto la set analysis. Ad esempio, si dovrebbero evitare Match(), MixMatch(), WildMatch() e Pick(). Creare flag nello script o utilizzare invece la set analysis. Per ulteriori informazioni, vedere Funzioni condizionali e Performance of conditional aggregations. |
|
Le condizioni di calcolo vengono utilizzate su oggetti che contengono calcoli intensivi |
Si potrebbero avere visualizzazioni con molti record quando non ci sono selezioni. Come best practice, aggiungere condizioni di calcolo agli oggetti in modo che vengano renderizzati solo dopo che sono state effettuate determinate selezioni. Questo impedisce la creazione di ipercubi molto grandi. Ad esempio: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. In questo scenario, la visualizzazione non verrà renderizzata a meno che l'utente non selezioni un singolo paese o effettui altre selezioni in cui è possibile un solo paese. |
|
Le misure vengono precalcolate nello script ove possibile |
Qualsiasi misura che si trovi al livello più basso di granularità del modello dati dovrebbe essere calcolata nello script. Ad esempio, se nello stesso record in una tabella si hanno Sales e Cost, si potrebbe derivare il margine calcolando Sales - Cost AS Margin. È inoltre possibile aggregare altri valori in anticipo se si sa che non varieranno in base alla selezione o che sono legati a un diverso livello di granularità. |
|
Le tabelle hanno meno di 15 colonne e presentano condizioni di calcolo |
Una tabella con 15 colonne potrebbe essere considerata larga. Se le tabelle sono costituite da molti record, si dovrebbero utilizzare condizioni calcolate sull'oggetto tabella in modo che venga renderizzato solo dopo che sono state soddisfatte determinate selezioni o criteri. Se la tabella è molto larga, considerare di:
|
|
I fogli non hanno un numero eccessivo di oggetti |
Gli oggetti vengono calcolati quando l'utente naviga verso il foglio. Ogni volta che un utente effettua una selezione su quel foglio, ogni oggetto verrà ricalcolato se quello stato corrente non esiste nella cache. Se si ha un foglio con molti grafici, l'utente dovrà attendere il calcolo di ogni oggetto per quasi ogni selezione. Questo pone un carico significativo sul motore. Come best practice, segui il concetto Dashboard/Analysis/Reporting (DAR) per sviluppare un'applicazione pulita e minimale. Per ulteriori informazioni, vedere DAR methodology. |
|
I flag numerici vengono sfruttati nello script per l'utilizzo nella set analysis |
La set analysis con i flag può essere più efficiente rispetto all'utilizzo di confronti di stringhe o moltiplicazioni. |
| Le voci principali consentono il trascinamento di metriche governate e garantiscono che le espressioni vengano memorizzate nella cache. Ad esempio, Sum(Sales) è diverso da SUM(Sales). Le espressioni vengono memorizzate nella cache in base all'ortografia e alle maiuscole/minuscole e devono corrispondere testualmente per poter essere riutilizzate. |
Prestazioni di caricamento dei dati
L'ottimizzazione del caricamento dei dati è importante per un'esperienza fluida e reattiva quando si lavora con le applicazioni in Qlik Cloud. Questa sezione evidenzia i fattori che influiscono sulle prestazioni e fornisce indicazioni su come prevenire i problemi di prestazioni.
Qlik Data Gateway - Accesso diretto
Quando si utilizza Qlik Data Gateway - Accesso diretto per ricaricare i dati nell'applicazione, i seguenti fattori influiscono sulle prestazioni:
-
Velocità di connessione e latenza tra la macchina che ospita il Data Gateway e il database.
-
Velocità di connessione e latenza tra la macchina che ospita il Data Gateway e il tenant di Qlik Cloud. Idealmente, ospitare il Data Gateway nella stessa regione del tenant di Qlik Cloud per migliorare le prestazioni.
Archiviazione del database
Connessioni di archiviazione lente possono aumentare i tempi di ricaricamento. Considerare quanto segue per i database ospitati in locale o nel cloud:
-
In locale: se il database è in locale e condivide un server con altre applicazioni, le sue prestazioni potrebbero essere influenzate dalle attività di queste altre applicazioni.
-
Cloud: se dimensionati correttamente, i database cloud offrono in genere prestazioni migliori rispetto ai database in locale. Per risultati ottimali, scegliere una regione per l'archiviazione cloud vicina al tenant di Qlik Cloud.