最佳化應用程式效能
應用程式效能可以透過縮減應用程式大小、簡化資料模型以及策略性地使用集合分析來改善。本區段將指出可能影響效能的區域,以及如何評估和監控應用程式效能,協助您避免效能問題。
您可以使用效能評估工具來監控應用程式的效能,也可以透過手動指派較大的引擎,測試其在不同引擎大小上的效能。如需詳細資訊,請參閱 應用程式效能評估 和 指派引擎以改善應用程式效能。
應用程式複雜度
這些是可協助診斷問題的寬鬆類別。 最複雜的應用程式效能最低。
簡單的應用程式:
- 不包含複雜的集合分析或 If() 陳述式。
- 不包含大型表格。
- 具有簡單的資料模型。
- 包含簡單的計算。
- 可能有龐大的資料量。
中等的應用程式:
- 具有包含許多表格的資料模型,但遵循最佳實務。
- 使用集合分析和數個 If() 陳述式。
- 在工作表上有大型或寬型表格 (15 個欄或以上)。
複雜的應用程式:
-
具有非常複雜的資料模型。
- 連線至龐大的資料量。
- 包含複雜的計算、圖和表格。
龐大的資料量
當您連線至龐大的資料量時,可以採用這些架構策略。
分段
您可以依據時間範圍、區域或彙總層級等維度來分段 QVDs。例如,您可以有:
- 包含最近兩年資料的 QVD。
- 包含超過兩年歷史資料的 QVD。
-
包含在較高層級彙總之所有資料的 QVD。例如,依月份而非日期,或依國家/地區而非個別客戶。
- 一個包含所有資料的大型 QVD,僅供一小部分使用者使用。
您可以採用類似的方式將應用程式分段。較小的應用程式將可滿足大多數使用者的分析需求。這可節省記憶體。
您也可以有多個專注於不同區域的應用程式。這樣一來,使用者就不會開啟包含他們不感興趣或無權存取之資料的應用程式。無法透過區段存取存取的資料仍會影響記憶體。
隨選應用程式產生 (ODAG)
Qlik Sense 隨選應用程式可為使用者提供巨量資料儲存的彙總檢視。他們可以識別並載入相關的資料子集以進行詳細分析。
從使用者的角度來看,有兩個應用程式:
- 包含彙總資料的購物車。
- 用於顯示詳細資料的空白範本應用程式。
使用者在購物車應用程式中進行選取。一旦達到閾值,就會建立自訂的 LOAD 指令碼,將要求的詳細資料填入範本應用程式中。 如需詳細資訊,請參閱 使用隨選應用程式管理巨量資料。
應用程式鏈結
應用程式鏈結 (在 QlikView 中稱為文件鏈結) 表示有一個使用者經常使用的彙總應用程式。 如果使用者需要更多詳細資料,可以將選取項目從彙總應用程式傳遞到詳細資料應用程式,以便他們檢視較低層級的細微度。這可節省記憶體,因為使用者不會載入不必要的詳細資料。可以透過將按鈕物件新增至工作表來執行應用程式鏈結。 如需詳細資訊,請參閱 應用程式鏈結。
應用程式鏈結也透過 APIs 支援。例如,您可以使用 應用程式整合 API 建立自訂的應用程式鏈結。如需詳細資訊,請參閱 應用程式整合 API (僅提供英文版)。
動態檢視
動態檢視可為高資料量或快速變更的資料情境提供最新的視覺化。使用動態檢視時,請考慮以下事項:
-
當您更新動態檢視時,會直接載入資料來源。更新效能會受到基礎資料來源效能的影響。
-
動態檢視範本應用程式可協助您建立動態圖。
如需有關使用動態檢視的詳細資訊,請參閱 透過動態檢視管理資料。
Direct Query
雖然建議使用記憶體內應用程式,但 Direct Query 允許您將資料保留在其原始來源中。請考慮以下事項以最佳化您的 Direct Query 使用:
-
Direct Query 的效能深受基礎資料來源效能的影響。
-
盡可能保持您的 Direct Query 資料模型簡單,因為複雜的查詢可能會導致效能問題。
如需有關 Direct Query 的詳細資訊,請參閱 使用 Direct Query 直接存取雲端資料庫。
資料模型效能
以下是可影響資料模型效能的指標。每一項是改善應用程式可用性的最佳做法。
| 動作 | 描述 |
|---|---|
|
移除合成鍵 |
若兩個或更多資料表格共同擁有兩個或更多欄位,則 Qlik Sense 會建立合成鍵。這可能表示指令碼或資料模型中發生錯誤。若要診斷合成鍵,請參閱 合成鍵。 |
|
從資料模型中移除循環參照 |
若兩個欄位具有多個關聯,就會發生循環參照。Qlik Sense 將嘗試變更與其中一個表格的連線,以解決這些事項。然而,所有循環參照警告都應解決,請參閱 瞭解和解決循環參照。 |
|
適當的資料精細度 |
您只能載入必要資料。例如:使用者群組只需要依週、月和年分割的資料。您可以在彙總資料中載入,或在載入指令碼內彙總資料以節省記憶體。若使用者的確需要以較低的精細度視覺化資料,可以使用 ODAG 或文件鏈結。 |
|
在可行情況下使用的 QVDs |
QVD 是包含從 Qlik Sense 所匯出之資料表格的檔案。從指令碼讀取資料時,此檔案格式的速度已經過最佳化處理,但是仍然十分精簡。從 QVD 檔案讀取資料通常比從其他資料來源讀取資料快 10-100 倍。如需詳細資訊,請參閱 使用 QVD 檔案。 |
|
在載入時最佳化的 QVD 檔案 |
可用兩種模式讀取 QVD 檔案:標準 (快速) 與最佳化 (更快速)。指令碼引擎會自動決定選取的模式。 關於最佳化載入有一些限制。可以重新命名欄位,但這些操作都會造成標準載入:
|
|
運用累加載入 |
如果您的應用程式連線至大量來自持續更新的資料庫的資料,載入整個資料集會相當耗時。您應改用累加載入,以從資料庫中擷取新記錄或變更的記錄。如需詳細資訊,請參閱 使用累加載入載入新的和更新的記錄。 |
|
合併 Snowflake 模型 |
若您有 Snowflake 資料模型,可以使用 Join 前置詞或其他對應聯結其中某些內容,以減少資料表格數量。這對於大型事實資料表特別重要。良好的縮圖規則是只有一個大型表格。如需更多資訊,請參閱是否合併。 |
|
將具有較少欄位數的表格去正常化 |
若您有兩個含有少數欄位的表格,合併它們可改善效能。如需詳細資訊,請參閱 使用 Join 與 Keep 來合併表格。 |
|
具有對應載入的去正常化查閱 (分葉) 表格 |
若您只需要將一個欄位從某個表格新增至另一個表格,則不應使用 Join 前置詞。您應使用 ApplyMap 查閱函數,請參閱請勿合併 - 使用 ApplyMap。 |
|
將時間戳記移除或從日期欄位解耦 |
若時間戳記存在,則日期欄位可以空白,因為字串表示較大,且相異值數量較大。若精確性對於分析沒有必要,可以將時間戳記四捨五入,例如使用 Timestamp(Floor(YourTimestamp,1/24)) 四捨五入為最近的小時,或使用 Date(Floor(YourTimestamp)) 完全移除時間元件。 若您想要時間戳記,可以從日期本身解耦。您可以使用相同的 Floor() 函數,然後沿用以下文字行,透過擷取的時間建立新欄位:Time(Frac(YourTimestamp))。 |
|
從資料模型中移除不必要的欄位 |
您只能在資料模型中載入必要欄位。避免使用 Load * 和 SELECT。確認您保留:
|
|
在處理大量資料時避免連結表格 |
您應在可行情況下使用連結表格。不過,若您處理大量資料,串連表格會超過連結表格的效能。 |
|
串連維度分為新的欄位 |
您應將串連維度分為獨立的欄位。這可減少欄位中值的唯一發生次數。這與最佳化時間戳記的方式類似。 |
|
在可行情況下使用的 AutoNumber |
您可以先從 QVD 檔案載入資料,以建立最佳載入,然後使用 AutoNumber 陳述式以將值轉換為符號鍵。如需詳細資訊,請參閱 AutoNumber。 |
|
避免資料島 |
資料島很實用,但通常會影響效能。若您正在建立用於選項值的島,請使用變數。 |
|
QVD 根據累加時間範圍來儲存。 |
您應以區段儲存 QVD,例如每月。然後這些較小的每月 QVD 可支援許多可能不需要所有資料的不同應用程式。 |
工作表效能
這些是可改善工作表和視覺化效能的最佳實務。
| 動作 | 說明 |
|---|---|
|
盡可能避免使用 If() 函數 |
如果在彙總函數內部使用 If() 函數,它將在記錄層級運作並被評估多次。 例如,如果您在彙總中有 1000 筆記錄,則 If() 條件將被評估 1000 次。如果您巢狀陳述式,這可能會迅速串聯。您應該改用集合分析。集合分析篩選條件會在彙總之前套用,從而產生更快的反應。這些反應也可以透過集合分析快取,而 If() 則無法。 您也可以考慮其他函數和對資料模型的修改。 |
| 盡可能避免在彙總表格內部使用來自不同表格的欄位。 |
評估彙總時,計算會執行兩個步驟:
單執行緒部分會大幅影響效能。 一個例子是如果您在彙總內部有多個欄位,例如 Sum(Quantity*ListPrice)。如果 Quantity 位於事實資料表中,而 ListPrice 位於主產品表格中,引擎首先需要聯結這兩個表格以尋找組合,然後才能開始加總乘積。聯結是單執行緒部分,而加總是多執行緒的。 如果兩個欄位都在同一個表格中找到,則不需要聯結,且彙總的評估速度會快得多。 |
|
盡量減少使用 Aggr() 和巢狀 Aggr() 函數 |
Aggr() 函數會大幅影響效能。不正確的使用可能會產生不準確的結果。例如,在一個表格中,其維度與 Aggr() 函數內的維度不同。如需詳細資訊,請參閱 When should AGGR not be used? |
|
盡可能使用集合分析 |
您可以使用集合分析來定義一組與目前選取項目所定義之一般集合不同的資料值。如需詳細資訊,請參閱 集合分析。 |
|
盡可能避免字串比較 |
字串比較不如集合分析有效率。例如,您應該避免使用 Match()、MixMatch()、WildMatch() 和 Pick()。在指令碼中建立旗標或改用集合分析。 如需詳細資訊,請參閱 條件函數 和 Performance of conditional aggregations。 |
|
在包含密集計算的物件上使用計算條件 |
當沒有選取項目時,您可能會有包含許多記錄的視覺化。作為最佳實務,請將計算條件新增至物件,以便它們僅在進行特定選取後才轉譯。這可停止建立非常大的超立方體。例如:GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1。在此情境中,除非使用者選取單一國家/地區,或進行其他僅可能出現單一國家/地區的選取,否則視覺化將不會轉譯。 |
|
盡可能在指令碼中預先計算量值 |
任何位於資料模型最低細微度層級的量值都應在指令碼中計算。例如,如果在表格的同一筆記錄中,您有 Sales 和 Cost,您可以透過計算 Sales - Cost AS Margin 來推導出利潤。如果您知道其他值不會根據選取項目而變化,或者它們綁定到不同的細微度層級,您也可以預先彙總這些值。 |
|
表格少於 15 個欄並具有計算條件 |
包含 15 個欄的表格可被視為寬型表格。如果您的表格包含許多記錄,您應該在表格物件上使用計算條件,以便它僅在滿足特定選取或準則後才轉譯。如果您的表格非常寬,請考慮:
|
|
工作表沒有過多的物件 |
當使用者導覽至工作表時,會計算物件。每次使用者在該工作表上進行選取時,如果快取中不存在該目前狀態,則會重新計算每個物件。如果您有一個包含許多圖的工作表,使用者將必須在幾乎每次選取時等待每個物件進行計算。這會對引擎造成重大負載。作為最佳實務,請遵循 Dashboard/Analysis/Reporting (DAR) 概念來開發乾淨且極簡的應用程式。如需詳細資訊,請參閱 DAR methodology。 |
|
在指令碼中利用數值旗標以用於集合分析 |
使用旗標的集合分析可能比使用字串比較或乘法更有效率。 |
| 主項目可啟用受治理指標的拖放,並保證運算式將被快取。例如,Sum(Sales) 與 SUM(Sales) 不同。運算式會根據拼字和大小寫進行快取,並且需要逐字相符才能重複使用。 |
資料載入效能
最佳化資料載入對於在 Qlik Cloud 中使用應用程式時獲得順暢且回應的體驗非常重要。本區段強調影響效能的因素,並提供有關如何預防效能問題的指引。
Qlik 資料閘道 - 直接存取
當您使用 Qlik 資料閘道 - 直接存取 將資料重新載入至您的應用程式時,以下因素會影響效能:
-
代管 Data Gateway 的機器與資料庫之間的連線速度和延遲。
-
代管 Data Gateway 的機器與您的 Qlik Cloud 租用戶之間的連線速度和延遲。理想情況下,將 Data Gateway 代管在與您的 Qlik Cloud 租用戶相同的區域中,以改善效能。
資料庫儲存
緩慢的儲存連線可能會增加重新載入時間。對於代管在地端或雲端中的資料庫,請考慮以下事項:
-
地端:如果您的資料庫位於地端,並與其他應用程式共用伺服器,其效能可能會受到這些其他應用程式活動的影響。
-
雲端:當大小調整正確時,雲端資料庫通常提供比地端資料庫更好的效能。為獲得最佳結果,請為您的雲端儲存選擇一個靠近您 Qlik Cloud 租用戶的區域。