Vertipaq 中的數據索引：行存儲與列存儲

在本教程中，我們將介紹關係數據庫與 Vertipaq 中數據索引工作方式的差異。

關係數據庫逐行存儲數據。另一方面，Vertipaq 是逐列進行的。

讓我們看看這兩種存儲和索引數據的方式如何影響您的報表開發過程，尤其是在運行查詢時。

目錄

• 每行數據索引
• 每列數據索引
• 比較簡單查詢的執行時間
• 比較更複雜查詢的執行時間
• 結論

每行數據索引

逐行存儲數據是傳統的數據存儲方式。但是，此過程需要更多時間，這會影響查詢的性能。

假設我們有一個包含品牌、顏色、性別、數量和淨價的表格。

如果我們將此表中的所有內容存儲在數據庫中，那麼它將逐行存儲數據。這就是為什麼傳統的數據存儲結構也被稱為行存儲。

首先，在同一行中，它將存儲第一行中的列標題——品牌、顏色、性別、數量和淨價。然後它移動到下一行以存儲每列下的第一個項目 — A. Datum、Azure、空白、1 和 103.2。這逐行繼續。

那麼我們如何使用這種數據索引方法計算數量的呢？

首先，它從第一行開始，其中包含列標題。然後，它跳到下一行並跳過其他數據，直到它到達它看到的第一個數量，即 1。然後它從一行跳到另一行，遍歷每行包含的所有數據並收集所有數據數量是發現。

一旦它擱置了每一行的所有數量，這就是計算完成的唯一時間。

如果您正在準備一個使用 DirectQuery 連接到 SQL 數據源的 LuckyTemplates 報表，您可能可以想像這個過程是多麼乏味。在這種情況下，分析服務會將 DAX 代碼轉換為 SQL 語言，然後開始逐行遍歷數據結構。

每列數據索引

為避免涉及的冗長過程，當您選擇導入模式時，您可以選擇通過 Vertipaq 逐列存儲數據。

當您使用列存儲而不是行存儲時，品牌、顏色、性別、數量和淨價將分別存儲在不同的數據結構中。

假設我們想要獲取 Quantity 列中值的 SUM。不需要傳遞品牌、顏色和數量列之外的其他數據。在單次掃描中，它從上到下讀取整個 Quantity 列並將所有值相加。

因此，與從左到右執行查詢相比，查詢將更快地執行。

比較簡單查詢的執行時間

要真正了解行存儲和列存儲之間的巨大差異，讓我們在 SQL 和 Vertipaq 中進行一些測試查詢。執行時間應該告訴我們一個進程與另一個進程相比有多快。

讓我們從一個簡單的 SQL 查詢開始。我們將計算 Sales 表中 Quantity 列的 SUM。

如您所見，總執行時間為 2.2 秒。

現在，讓我們轉到 DAX Studio 並使用EVALUATE函數執行相同的查詢。我們需要打開服務器計時並等待跟踪完成。

我們還需要確保在運行查詢時選擇了“清除緩存然後運行”選項。

執行查詢後，您會發現只需 3 毫秒即可完成我們之前在 SQL 中執行的相同查詢。

結果集還應該匹配 SQL 和 DAX Studio。如果我們將它們並排放置，您會看到我們返回的是相同的值。

您可以嘗試多運行幾次查詢以查看執行時間的一致性。

比較更複雜查詢的執行時間

這一次，讓我們比較運行更複雜查詢時的執行時間。

假設我們要確定每個品牌的銷售數量總和。為此，我們可以對每個產品品牌的在低上下文中，我們還將創建一個名為總數量的新表，我們將在其中計算數量的總和。

如果我們運行這段代碼，您可以看到總執行時間為 7 毫秒。

在後台，這段代碼實際上運行了兩個查詢。第一個從 Products 表中獲取 Brand 列，然後對 Sales 列和 Products 列中的 Product Key 列執行 OUTER JOIN 。

第二個查詢只是從 Products 表中檢索 Brand 列。

如果我轉到結果屏幕，您可以看到總數量度量已根據每個品牌進行了拆分。

現在讓我們轉到 SQL 服務器並編寫相同的查詢。

我們將 DaxStudio Sales 表推到下一行，引用 Sales 表 AS S。然後，我們還將在引用 AS P 的 DaxStudio Products 表中執行 LEFT JOIN ， S.Product Key 等於P.產品密鑰。我們還將在SELECT語句中將 P.Brand 與數量和總數量的總和一起使用。最後，我們將為 P.brand 使用。

運行此代碼後，我們將獲得一個包含每個品牌分隔的總數量的表格，這與我們之前在 Vertipaq 中獲得的相同。

至於總執行時間，它仍然慢得多，為 2.5 秒。

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

結論

很明顯，與 SQL 數據庫中的行存儲相比，通過 Vertipaq 的列存儲到底有多快。這表明真正了解數據索引在不同平台上的工作方式的重要性。

與 7 毫秒相比，如果您仍然選擇行存儲運行查詢的 2.5 秒，乍一看似乎是一個很小的犧牲。但是我們在創建報告時都會運行多個查詢，所有這些執行時間都會加起來，從長遠來看會影響生產力和用戶體驗。