存儲引擎——它在 LuckyTemplates 中優化 DAX 查詢中的作用

在本教程中，我們將了解分析服務中的第二個引擎——存儲引擎。

我們在過去的教程中討論了頂級引擎，公式引擎。當用戶了解這兩個引擎的工作原理時，就可以更輕鬆地優化和提高 DAX 查詢的性能。

存儲引擎的主要目的是直接與數據庫一起工作。

公式引擎無法直接訪問數據庫，因此通常會通過存儲引擎來實現此目的。

存儲引擎有兩種類型——導入模式和 DirectQuery。您可以在同一數據模型中混合和匹配這兩種類型以創建複合模型。

目錄

• 在存儲引擎中使用導入模式
• 在存儲引擎中使用 DirectQuery
• 使用複合模型
• 關於存儲引擎的其他關鍵點
• 處理複雜的查詢
• 結論

在存儲引擎中使用導入模式

首先，讓我們談談導入模式。這也更常見地稱為 Vertipaq，但它也稱為 xVelocity 或 In Memory Columnar Database。

關於導入模式的工作原理，有四個關鍵點需要了解。

首先，Vertipaq 直接從數據源創建數據副本，並以壓縮格式將其存儲在 RAM 中。

其次，導入方式處理的數據是基於上次刷新操作的。這意味著，如果您上週最後一次刷新數據，那麼您正在處理的數據仍然是上週的相同數據。如果您使用的是一個表處於導入模式而另一個表處於 DirectQuery 模式的複合設置，這一點尤其重要。

假設您有 Products 表，該表在導入模式下於上週刷新。至於 Sales 表，由於其大小，您決定通過 DirectQuery 處理它。我們還假設您正在根據兩個表創建報告，您在其中引入品牌列並在同一個銷售表上創建總銷售額度量。您還想可視化基於品牌的銷售額。

您必須首先刷新來自導入模式的數據，因為您最終可能會得到來自 DirectQuery 的新鮮和更新數據，以及來自 Vertipaq 的過時數據。這將在您的矩陣和可視化上留下一些空白行。

關於 Vertipaq，您需要了解的下一件事是，只有、、、或等基本操作是本機可用的。這意味著如果查詢計劃中包含其他更複雜的操作，存儲引擎將不得不調用公式引擎來解析這部分代碼。

最後，由於 Vertipaq 的列式結構，存儲引擎是一個高度優化的數據庫。這意味著所有數據都是逐列存儲的，而不是逐行存儲的。由於這種結構，即使您在關係數據模型中創建索引，Vertipaq 也始終比 DirectQuery 連接更快。

在存儲引擎中使用 DirectQuery

LuckyTemplates 分析服務中的下一個選項是 DirectQuery。如果您使用 DirectQuery 連接，分析服務僅作為公式引擎發送的查詢的傳遞。

假設您編寫了一個查詢。公式引擎將生成一個查詢計劃。然後它將查詢轉發給存儲引擎，已經翻譯成數據庫的本地語言。大多數時候，這些查詢來自 SQL。

如果查詢使用 DirectQuery，則期望它始終是最新的。無需擔心上次刷新數據的時間。

優化 DAX 代碼和數據模型的過程也將取決於關係數據庫的創建方式。如果您的列中有索引，那麼您的查詢將始終得到優化。但是，如果您的數據庫未針對使用分析服務或 LuckyTemplates 創建報告進行優化，那麼您可能會面臨一些性能挑戰。因此，請有意識地為報告開發構建數據庫。

使用複合模型

第三個選項是創建一個複合模型，這樣您就可以在導入模式下擁有一個表，在 DirectQuery 中擁有另一個表。

當您使用來自不同來源的兩個表時，公式引擎將向 Vertipaq 發送一個請求，向 DirectQuery 數據源發送另一個請求。在這兩種情況下，分析服務還將從 Vertipaq 和 DirectQuery 中檢索數據緩存。然後，公式引擎將在向最終用戶提供結果之前對兩個數據緩存使用 JOIN、

因此，假設您正嘗試在報表中按產品品牌可視化銷售額。公式引擎將向 Vertipaq 發送請求，在那裡它將檢索產品、品牌和產品密鑰。然後，它將嘗試從 DirectQuery 中檢索銷售額、淨價、銷售數量和銷售產品密鑰。

一旦有了基於產品密鑰的兩個數據緩存，它將加入兩個數據緩存併計算總銷售額。然後它將結果呈現給最終用戶。

關於存儲引擎的其他關鍵點

現在我們已經介紹了它的不同類型，您還需要了解一些其他關於存儲引擎的關鍵因素，以幫助您優化 DAX 查詢。

正如我之前提到的，存儲引擎以未壓縮數據緩存的形式將數據緩存提供回公式引擎。當您處於導入模式時，在流程中發送回 Vertipaq 的請求以 xmSQL 語言執行。

xmSQL 語言與 SQL 有點相似，但又不完全相同。當我們在另一個教程中討論查詢計劃時，我們將詳細討論 xmSWL。

記住存儲引擎使用 CPU 中所有可用的內核也很重要。如果您的數據模型中有多個段，使用多個核心的能力是有益的。

假設您在 LuckyTemplates 中有一個包含 1200 萬行的表。然後，此表將分為 12 個段，因為在 Power Pivot 和 LuckyTemplates 中，每個段都包含 100 萬行。這不同於一般的分析服務，其中一個段可容納 800 萬行。

因此，如果我的 CPU 中有六個內核，所有六個內核將同時掃描 12 個段中的前六個。完成後，他們將繼續進行下六個部分。

但是，如果我正在使用默認段包含 800 萬行的分析服務，則將只使用我的六個內核中的兩個 - 一個段將處理 800 萬行，而另一個處理 400 萬行。

處理複雜的查詢

早些時候，我提到導入模式僅支持 MIN、MAX、SUM、COUNT 和 GROUPBY 等基本操作。那麼，如果您處理更複雜的查詢會怎樣？

假設您決定在行上下文中使用 IF 語句，或者在 Products 和 Sales 表上使用 SUMX 等嵌套迭代。

在這種情況下，存儲引擎將無法自行解析查詢。然後它會調用公式引擎，它會開始在存儲引擎中逐行解決複雜的計算。有些人可能認為這是一個有利的場景，兩個引擎一起工作——但這與事實相去甚遠。

您會看到，發生這種情況時，如果特定查詢中存在回調數據 ID，則無法緩存存儲引擎生成的數據緩存。因此，如果您刷新視覺效果，則公式引擎和存儲引擎都必須完成相同的計算，即使您幾秒鐘前剛剛執行了相同的查詢。這將導致性能延遲和糟糕的用戶體驗。

另請注意，存儲引擎不知道查詢是使用 DAX 還是 MDX 執行的。正如我們之前提到的，公式引擎的工作是在傳遞查詢計劃之前將查詢轉換為正確的語言。

最後，公式引擎將查詢一個一個發送到存儲引擎。這意味著擁有多個段確實更好，這樣可以減少 Vertipaq 內的整體掃描時間，同時掃描多個段。

DAX For LuckyTemplates：在 DAX Studio 中使用公式引擎進行優化
DAX 查詢優化技術和課程
查詢性能和 DAX Studio 設置

結論

了解存儲引擎的來龍去脈確實有助於優化您的 DAX 查詢，尤其是在您使用 DAX Studio 時。如果您還閱讀了解釋公式引擎的教程，則可以更好地決定如何創建性能更好的查詢。

雖然公式引擎作為頂級引擎，但毫無疑問，如果我們不最大化兩個引擎，它就無法發揮最佳性能。

一切順利，