最佳化應用程式效能
應用程式效能可以透過縮小應用程式大小、簡化資料模型以及策略性地使用集合分析來改善。本區段將指出可能影響效能的區域,以及您如何評估和監控應用程式效能,從而協助您避免效能問題。
您可以使用效能評估工具來監控應用程式的效能,也可以透過手動指派較大的引擎來測試其在不同引擎大小下的效能。如需詳細資訊,請參閱 應用程式效能評估 和 指派引擎以改善應用程式效能。
應用程式複雜度
這些是粗略的類別,可協助診斷問題。最複雜的應用程式效能最低。
簡單的應用程式:
- 不包含複雜的集合分析或 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() 函數內部的維度不同的資料表中。如需詳細資訊,請參閱 何時不應使用 AGGR? |
|
盡可能使用集合分析 |
您可以使用集合分析來定義一組與目前選取內容所定義之正常集合不同的資料值。如需詳細資訊,請參閱 集合分析。 |
|
盡可能避免字串比較 |
字串比較不如集合分析有效率。例如,您應該避免使用 Match()、MixMatch()、WildMatch() 和 Pick()。請改為在指令碼中建立旗標或使用集合分析。 如需詳細資訊,請參閱 條件函數 和 條件式彙總的效能。 |
|
在包含密集計算的物件上使用計算條件 |
在沒有進行選取時,您可能會有包含許多記錄的視覺化。最佳實務是,將計算條件新增至物件,以便它們僅在進行特定選取後才進行轉譯。這可以阻止建立非常大的超立方體。例如:GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1。在此情境中,除非使用者選取單一國家/地區,或進行僅可能有一個國家/地區的其他選取,否則視覺化將不會進行轉譯。 |
|
盡可能在指令碼中預先計算量值 |
任何處於資料模型最低資料粒度層級的量值都應該在指令碼中進行計算。例如,如果在資料表的同一筆記錄中您有 Sales 和 Cost,您可以透過計算 Sales - Cost AS Margin 來衍生利潤。如果您知道其他值不會根據選取內容而變化,或者它們繫結至不同的資料粒度層級,您也可以提前彙總這些值。 |
|
資料表包含少於 15 欄並具有計算條件 |
包含 15 欄的資料表可以被視為寬資料表。如果您的資料表由許多記錄組成,您應該在資料表物件上使用計算條件,以便它僅在滿足特定選取內容或準則後才進行轉譯。如果您的資料表非常寬,請考慮:
|
|
工作表不包含過多數量的物件 |
當使用者導覽至工作表時,會計算物件。每次使用者在該工作表上進行選取時,如果快取中不存在該目前狀態,則會重新計算每個物件。如果您的工作表包含許多圖,則使用者幾乎在每次選取時都必須等待每個物件進行計算。這會給引擎帶來顯著的負載。最佳實務是,遵循 Dashboard/Analysis/Reporting (DAR) 概念來開發乾淨且極簡的應用程式。如需詳細資訊,請參閱 DAR 方法論。 |
|
在指令碼中利用數值旗標以用於集合分析 |
使用旗標的集合分析比使用字串比較或乘法更有效率。 |
| 主項目可實現受控指標的拖放,並保證運算式將被快取。例如,Sum(Sales) 與 SUM(Sales) 不同。運算式會根據拼字和大小寫進行快取,並且需要逐字比對才能重複使用。 |
資料載入效能
在 Qlik Cloud 中使用應用程式時,最佳化資料載入對於無縫且回應迅速的體驗至關重要。本區段重點介紹了影響效能的因素,並提供了如何防止效能問題的指引。
Qlik 資料閘道 - 直接存取
當您使用 Qlik 資料閘道 - 直接存取 將資料重新載入至應用程式時,以下因素會影響效能:
-
託管 Data Gateway 的機器與資料庫之間的連線速度和延遲。
-
託管 Data Gateway 的機器與您的 Qlik Cloud 租用戶之間的連線速度和延遲。理想情況下,將 Data Gateway 託管在與您的 Qlik Cloud 租用戶相同的區域中,以提高效能。
資料庫儲存空間
慢速儲存連線可能會增加重新載入時間。對於託管在內部部署或雲端中的資料庫,請考慮以下事項:
-
內部部署:如果您的資料庫位於內部部署且與其他應用程式共用伺服器,其效能可能會受到這些其他應用程式活動的影響。
-
雲端:當大小調整正確時,雲端資料庫通常比內部部署資料庫提供更好的效能。為了獲得最佳結果,請為您的雲端儲存空間選擇靠近您的 Qlik Cloud 租用戶的區域。