先決條件

本文假定讀者對EVI，DB2 i索引策略，DB2 i星型聯接支持和物化查詢表（MQT）有基本的了解。 DB2 for i卓越中心團隊已經發布了許多提供此背景信息的白皮書。 如有必要，請在“ 參考”部分中查看這些論文的鏈接。

本文同時包含示例SQL查詢和查詢的直觀說明，以演示如何使用EVI來提高性能。 使用IBM i Navigator隨附的Visual Explain工具創建了視覺說明。 有關此工具的更多信息，請參考“參考”部分中包含的數據庫查詢優化參考。

參考資料部分還包括一個鏈接，該鏈接指向DB2 for i卓越中心團隊提供SQL性能研討會的描述。 該研討會是獲得對DB2 for i性能分析和優化概念的深入了解的一流方法。 有關更多詳細信息，請參考參考部分中的鏈接。

本文中描述的功能假定商業智能或分析應用程序是基于DB2 i 7.1構建的，其臨時修訂級別至少為SF99701第18級。IBM建議客戶應用最新的更新以便接收最新的更新。修復和增強。 您可以在“ 參考”部分中找到指向DB2 for i技術更新頁面的鏈接。

總覽

在典型的BI或分析環境中，事實表包含一個或多個度量，需要通過對維度進行分組來匯總。 例如，報告可能需要提供按位置維度分組的收入度量的總和。 當事實表包含數百萬（或數十億）行時，一種有效的聚合計算機制對于臨時查詢的性能至關重要。

EVI并不是DB2 for i的最新成員，而且一直非常適合BI環境中發生的針對大型數據集的臨時查詢類型。 這些索引基于IBM研究開發的專利技術，于1998年隨IBM OS /400?Version 4 Release 3首次使用。EVI的常規使用通過允許數據庫管理器有效地實現行的本地選擇來提高查詢性能。使用跳過順序處理； 也就是說，將按其物理順序（而不是隨機訪問）訪問感興趣的行，并跳過不滿足選擇條件的行范圍。 EVI的另一個常規優點是，統計信息和描述性信息存儲在EVI的符號表中，用于每個不同的鍵，從而使優化器可以在優化查詢時使用EVI做出非常明智的選擇。 本文討論了DB2 for i 7.1中的增強功能的好處，該功能允許將度量列的聚合值包含在EVI的符號表中。

在EVI的符號表中包含度量值列的合計值是增強現有索引策略以獲得其他性能改進的一種簡便方法。 包含意味著EVI的符號表中的每個符號還包括與該符號關聯的所有行的一個或多個聚合值。 如果將索引鍵用作分組標準，則在EVI中包含度量的合計值將為DB2優化器提供用于計算查詢中這些值的快速選項。

例如， 圖1中顯示的表按日期和城市包含收入和利潤數字。

圖1：按日期和城市劃分的收入和利潤數字

如果使用城市作為鍵列創建EVI，則EVI可以包括度量列的有用匯總，例如SUM(revenue)和AVG(profit) 。 創建后，EVI的符號表將如表1所示。

表1：EVI符號表

總和（收入） AVG（利潤） 市

35	14	紐約
150	42	羅切斯特

在城市上分組時，需要計算SUM(revenue)或AVG(profit)的查詢只需要訪問EVI符號表并檢索包括的聚合，而無需訪問列表中的（通常很多）行。事實表。

與MQT的比較

許多BI解決方案都使用MQT來存儲預聚合的值。 多年來，由于DB2 for i優化器能夠利用MQT中預先聚合的數據，因此MQT的使用一直是一項重要的性能技術。 MQT的主要缺點是需要經常刷新它們，并且維護成本可能很高。

作為替代方案，DB2 for i優化器可以使用EVI中包含的預聚合值。 在索引中存儲預匯總的值可以立即維護這些值； 結果，無需刷新聚合值以使存儲的值與數據保持一致。 總計值的增加不會顯著增加索引維護成本。

AVG，COUNT，COUNT_BIG，SUM，STDDEV，STDDEV_SAMP，VARIANCE和VARIANCE_SAMP函數可以作為匯總值表達式包含在EVI中。 EVI的一個限制是，非鍵列不能包含合計的MIN和MAX值。

在以下情況下，DB2 for i優化器最有可能通過使用EVI中包含的聚合值來優化查詢：

• GROUP BY來自單個表
• GROUP BY的引用列在鍵定義中
• 選擇基于索引鍵
• 承諾控制級別為* NONE或* CHG

這些條件描述了最常見的查詢類型，將對其進行優化以利用EVI的符號表中的合計值。 條件不是對合計值何時對優化程序有用的絕對限制。 本文稍后將提供復雜查詢的示例，這些示例將進行優化以充分利用所包含的聚合值。

當MQT執行聚合并且GROUP BY引用單個表時，可能可以用包含聚合值的EVI替換MQT。 隨著基本表中數據的更改，系統將維護EVI，而MQT則不會。 MQT維護是用戶的責任。

對于DB2優化器不太可能使用EVI中包含的聚合值的查詢，MQT仍然是一種可能的選擇。 當GROUP BY超過一個表時，DB2優化器可以將查詢與MQT匹配。 MQT可以與包含MIN或MAX聚合函數的查詢匹配。 MQT的另一個功能是，MQT的提交級別必須大于或等于查詢的提交級別，但不一定必須是* NONE或* CHG。

何時在EVI中包括合計值

創建包含聚合值而不是包含相同聚合的MQT的EVI可能是有益的。 在允許系統自動維護聚合值的環境中，EVI是有利的。 創建有用的EVI（包括聚合）的一種策略是設計最佳的MQT策略，然后用EVI識別并替換合適的MQT。 如果EVI可能對否則可能使用MQT的查詢有用，則該MQT適合用EVI替換。 在單個表上執行聚合的MQT是可能適合替換的MQT的示例。

另一種方法是創建包含匯總值的EVI，作為高級索引策略的一部分。 使用此方法時，如果EVI由于傳統原因而對EVI有利，則應該在EVI中包括度量列的匯總，并且經常通過按EVI的鍵分組來匯總度量列。 然后，優化器將具有可供該組使用的其他聚合信息，可以選擇該優化器在查詢的實現中使用。 當優化器無法使用所包含的信息進行匯總時，索引仍然可以用于檢索準確的統計信息； 此外，（在適當時）EVI可用于表選擇，跳過順序計劃或用于索引ANDing和ORing計劃。 因此，包括合計值可以在一個查詢子集中產生出色的性能（維護成本很低），并且EVI繼續被優化器用來對其他查詢執行廣泛的優化。

通過查看一些示例，將更容易理解包含合計值的效果。

星型模式示例

圖2顯示了一個非常簡單的星型模式，名為sales_bi。 事實表（sales_fact）具有一個度量列（sale_amount_measure）。 事實表提供了用于分組的兩個維度。 日期維度（sale_date）和位置（sale_location_id）。 此外，這些維度中的每一個都提供了進一步分組的機會。 例如，sale_date列還允許按年，季度和月分組，而sale_location_id列則允許按城市，州或地區分組（使用sales_location_dimension表）。 如果由于市場營銷活動而進行購買的客戶這樣做，則customer_included_in_marketing列包含“ Y”值。

圖2：sales_bi模式

在GROUP BY sale_location_id上優化SUM（）

清單1顯示了一個簡單的查詢，該查詢以降序返回按位置ID分組的銷售總額。 HAVING子句中的選擇條件可確保結果中僅包含位置4、16和13。

清單1：特定位置的sale_amount_measure匯總

SELECT SUM(sale_amount_measure) sum_of_sales,sale_location_id FROM sales_fact GROUP BY sale_location_id HAVING sale_location_id IN (4, 16, 13) ORDER BY sum_of_sales DESC

清單1中查詢的示例輸出如圖3所示。

圖3：銷售總額，按sale_location_id分組

清單1中的查詢是一個簡單但不常見的示例。 大多數分析查詢將涉及與維表的聯接。 例如， 清單2中的查詢進行聯接，以便按狀態而不是位置ID對聚合進行分組。 僅包括紐約州，威斯康星州和明尼蘇達州。

清單2：按州匯總的sale_amount_measure

SELECT SUM(sale_amount_measure) AS sum_of_sales, state FROM sales_fact INNER JOIN sales_location_dimension ON (sales_fact.sale_location_id = sales_location_dimension.sale_location_id) GROUP BY state HAVING state IN ('NY', 'WI', 'MN') ORDER BY sum_of_sales DESC

清單2中查詢的輸出如圖4所示。

圖4：按州分組的銷售總額

清單1和清單2中的查詢都需要訪問sales_fact表中的大量行，這將導致性能下降。 因此，通過創建索引來提高這些查詢的性能是成功的基礎。

回顧了DB2 for i星型連接支持和DB2 for i索引策略（在參考資料部分中找到）的數據庫開發人員，可以認識到事實表的sale_location_id列是EVI的關鍵。 第二個觀察結果是，預期EVI的鍵用作清單1中查詢的分組列，而在清單2中 ，狀態列的分組基于鍵列上的層次結構。 由于兩個查詢都還需要計算SUM(sale_amount_measure) ，因此此聚合是要包含在索引中的不錯的選擇。

DB2 for i Index Advisor不建議在EVI中包含合計值。 但是，由于出于常規原因通常需要在EVI中包含合計值，因此可以使用Index Advisor來幫助標識必須創建的索引。 在確定了預期的EVI之后，可以檢查導致推薦該EVI的查詢，以確定EVI中是否應包含合計值。 （查看導致建議創建索引的語句的功能是針對DB2 i 7.1的一項技術更新。有關更多詳細信息，請參閱“ 參考”部分中的鏈接。）

DB2 for i優化器可以確定是否在查詢中使用EVI的聚合值。 包含這些值的額外維護成本很小，不是主要的考慮因素。

使用包含的匯總值創建EVI

創建一個EVI并包含一個或多個聚合值很簡單。 CREATE ENCODED VECTOR INDEX語句具有INCLUDE子句，可用于指定非鍵集合值。 清單3顯示了編碼矢量索引SQL語法，該索引將sale_location_id列定義為鍵，并包括SUM（sale_amount_measure）作為其他非鍵數據。

清單3：創建一個EVI語句

CREATE ENCODED VECTOR INDEX sales_fact_location_id_evi ON sales_fact(sale_location_id ASC) INCLUDE(SUM(sale_amount_measure))

另外，對IBM i Navigator進行了增強，以便新的索引對話框包含一個用于添加非關鍵聚合值的選項， 如圖5所示。

圖5：帶有其他非關鍵數據的選項選項卡

本示例僅包含索引的單個匯總值。 實際上，創建索引時通常會包含多個匯總值。 不必為每個需要包括的匯總度量創建單獨的EVI。

EVI的使用包括合計值

在索引之后清單3被創建，在示出的查詢中的視覺解釋清單1中示出了圖6中 。

圖6：直觀說明顯示了一個EVI符號表探針

僅需要訪問EVI的符號表，而無需訪問事實表。 之所以SUM(sale_amount_measure)是因為符號表現在具有為sale_location_id列的每個不同值維護的SUM(sale_amount_measure)結果。

通常，當查詢涉及單個表時，查詢優化器最能應用此技術，因為聯接是在聚合之前進行評估的。 但是，如果我們看一下清單2的直觀說明（如圖7所示），我們會看到優化器有時能夠重寫查詢，以使聯接與EVI的符號表一起使用。 重寫允許使用EVI中包含的合計值。 無需探測或掃描事實表，就可以將符號表中針對位置ID的部分聚合進一步聚合為狀態分組的值。

圖7：可視化說明顯示了與EVI的符號表的聯接

在EVI的符號表中包括匯總度量是整體索引策略的一部分。 警報讀者可以看出， 圖7顯示了一個表格掃描，該表格從sales_location_dimension表中選擇具有特定狀態值的行。 由于表中只有很少的行符合選擇標準，因此表掃描不是最佳的。 作為改進，DB2 for i優化器建議在state列上創建一個二進制基數。 創建建議的二進制基數索引之后， 清單 8中的查詢的直觀說明如圖8所示。

圖8：創建建議的二進制基數索引后的直觀說明

通過GROUP BY ROLLUP優化SUM（）

下一個示例演示了OLAP查詢的一種常見類型，其中對從sales_fact表中的sale_date維度派生的年，季度和月值執行GROUP BY ROLLUP。

清單4顯示了一個查詢，其中按年，季度和月匯總了總銷售額。

清單4：GROUP BY ROLLUP（年，季度，月）

SELECT SUM(sale_amount_measure) AS sum_of_sales,YEAR(sale_date) AS sale_year, QUARTER(sale_date) AS sale_quarter, MONTH(sale_date) AS sale_month FROM sales_fact GROUP BY ROLLUP(YEAR(sale_date), QUARTER(sale_date), MONTH(sale_date)) ORDER BY YEAR(sale_date), QUARTER(sale_date), MONTH(sale_date)

清單4中查詢的一些示例結果（部分）如圖9所示。

圖9：GROUP BY ROLLUP的結果集（年，季度，月）

在其他臨時查詢中，年，季度和月值可能會用于本地選擇。 這使這些表達式成為EVI的絕佳候選鍵。

索引顧問不建議將派生的表達式作為EVI的可能鍵，因此，數據庫設計者識別類似于此情形的能力很重要。 派生密鑰上的EVI會對性能產生重大影響。

由于預期的EVI的鍵列也用于對SUM(sale_amount_measure)聚合值進行分組，因此可以為導出的鍵表達式創建單個EVI，并包括聚合值。

使用派生鍵和包含值創建EVI

清單5顯示了CREATE INDEX語句SQL語句。 這將表達式指定為鍵，并包括其他非鍵聚合值。

清單5：創建年，季度和月的編碼矢量索引

CREATE ENCODED VECTOR INDEX sales_fact_date_yqm_evi ON sales_bi.sales_fact (YEAR(sale_date), QUARTER(sale_date),MONTH(sale_date) ) INCLUDE(SUM(sale_amount_measure))

EVI在GROUP BY ROLLUP中的使用

清單4中查詢的直觀說明如圖10所示。 該查詢不再需要訪問事實表，因為執行GROUP BY ROLLUP所需的所有信息現在都在EVI中。

圖10：使用EVI的符號表對GROUP BY ROLLUP的直觀說明

與GROUP BY ROLLUP相似，當分組涉及GROUP BY CUBE或GROUP BY GROUPING SETS時，DB2 for i優化器可以使用EVI的符號表。

作為DB2 for i 7.1技術更新（PTF組SF99701級別18）的一部分，添加了優化器使用GROUP BY ROLLUP，GROUP BY CUBE或GROUP BY GROUPING SETS中包含的EVI聚合的功能。 參考部分中包含指向這些功能的技術更新說明的鏈接。

在行的子集上優化AVG（）

在BI應用程序中，通常要求使用獨立于分組條件的選擇條件對事實表中的行的子集執行聚合。 例如，業務分析師可能希望對sales_fact表中的sale_amount_measure列執行匯總（使用一個或多個維度進行分組），但僅對customer_included_in_marketing列中值為“ Y”的行進行匯總。

清單6顯示了一個示例查詢，該查詢僅針對那些由于營銷活動而進行購買的銷售計算按州和星期幾分組的平均sale_amount_measure值。 僅包括紐約州，威斯康星州和明尼蘇達州。

清單6：包含事件的州和星期幾的平均sale_amount_measure

SELECTCAST(AVG(sale_amount_measure) AS DECIMAL(5,2)) average_sale, state, DAYOFWEEK_ISO(sale_date) day_of_week FROM sales_fact INNER JOIN sales_location_dimension ON (sales_fact.sale_location_id =sales_location_dimension.sale_location_id) WHERE customer_included_in_marketing = 'Y' GROUP BY state, DAYOFWEEK_ISO(sale_date) HAVING state IN ('NY', 'WI', 'MN') ORDER BY average_sale DESC

清單6中查詢的示例輸出如圖11所示。

圖11：平均銷售結果集

創建EVI以使分組列和選擇列都是索引的鍵，這是一種允許利用包含的聚合的方法。 清單7中顯示了此方法的示例create index語句。

清單7：使用分組和選擇列作為鍵創建EVI

CREATE ENCODED VECTOR INDEX sales_fact_location_day_marketing_evi ON sales_fact (sale_location_id, DAYOFWEEK_ISO(sale_date),customer_included_in_marketing) INCLUDE (AVG(sale_amount_measure))

清單7中所示方法的問題在于，EVI的符號表中的條目（和合計值）的數量可能不必要地變大。 符號表包含EVI鍵列中值的每個組合的匯總值。 如果在選擇涉及多個列且每個列具有許多可能值的情況下采用此方法，則EVI的符號表可能會增長到索引的有用性大大降低的大小。 另外，用于選擇的列并不總是具有有限范圍的不同值，這使該列成為EVI鍵的不切實際的選擇。

創建稀疏的EVI

對于清單6中的查詢，創建一個僅包含customer_included_in_marketing值為'Y'的行的稀疏EVI是合適的解決方案。 通常，必須謹慎使用此方法。 僅當查詢的選擇條件與用于創建索引的選擇條件完全匹配時，稀疏索引才對優化程序有用。 清單8顯示了用于創建稀疏EVISQL語法。

清單8：創建一個包含匯總值的稀疏EVI

CREATE ENCODED VECTOR INDEX sales_fact_location_day_select_marketing_y_evi ON sales_fact ( sale_location_id,DAYOFWEEK_ISO(sale_date) ) WHERE customer_included_in_marketing = 'Y' INCLUDE (AVG(sale_amount_measure))

稀疏EVI用于聚合的用法

圖12顯示了清單8中創建稀疏EVI之后的清單6中查詢的直觀說明。 稀疏EVI的符號表包含與查詢的WHERE子句匹配的行的平均值（在位置ID上）。 結果，無需訪問事實表即可實現查詢。

圖12：使用稀疏EVI的查詢的直觀說明

當包含的值無用時的索引用法

不能總是使用EVI中包含的聚合值來實現查詢。 清單9顯示了一個示例查詢，其中包含的聚集值無濟于事。 該查詢包含與清單4中的查詢類似的GROUP BY ROLLUP子句，但是該聚合僅包含具有sale_date為2011或2012年的行和一個值為'EAST'的區域。

清單9：無法從包含的聚合中受益的查詢

SELECT SUM(sale_amount_measure) AS sum_of_sales,YEAR(sale_date) AS sale_year, QUARTER(sale_date) AS sale_quarter, MONTH(sale_date) AS sale_month FROM sales_fact INNER JOIN sales_location_dimension ON (sales_fact.sale_location_id =sales_location_dimension.sale_location_id) WHERE YEAR(sale_date) IN (2011, 2012) AND region = 'EAST' GROUP BY ROLLUP(YEAR(sale_date), QUARTER(sale_date), MONTH(sale_date)) ORDER BY YEAR(sale_date),QUARTER(sale_date), MONTH(sale_date)

清單9的示例輸出如圖13所示。

圖13：2011年和2012年東部地區的銷售額，按年，季度和月匯總

清單9中所示的查詢是一個普通的臨時BI查詢的示例，其中將不使用索引中包含的合計值，因為選擇和分組標準不僅限于具有以下特征的任何單個EVI的符號表中的信息：被創建。 但是， 清單3和清單5中創建的EVI對于查詢仍然具有重要的整體價值。

圖14顯示了清單9中查詢的直觀說明。 盡管不會使用EVI包含的聚合值來執行聚合，但是清單3和清單5中的EVI可以用于在事實表中生成滿足選擇謂詞的相對記錄號（RRN）行列表。 RRN列表允許查詢僅訪問具有有趣行的頁面，這可以大大提高查詢的性能。 因為維護包含的聚合值對索引維護成本的影響很小，所以包括可用于其他查詢的其他信息的該附加信息仍對應用程序有利。

圖14：無法使用包含的聚合值的查詢的直觀說明

摘要

在EVI的符號表中包括聚合值的功能是DB2 i 7.1中的一項強大功能，可以幫助提高BI或分析應用程序的性能。 本文介紹了幾個示例，其中在聚合的矢量索引中包括聚合值是有益的。 創建包含聚合的索引是一個好主意，因為維護聚合值的維護成本極低，并且性能提升非常可觀。

要了解和最大化DB2 for i SQL的所有功能，需要學習，培訓和經驗； 結果是出色的投資回報。 系統和技術小組實驗室服務i2卓越中心的DB2團隊提供了許多出色的教育機會，其中包括夢幻般的 DB2 for i SQL性能研討會。 “ 參考”部分包括指向研討會網站的鏈接，以及指向IBM Lab Services and Training網站的鏈接。

致謝

特別感謝Systems and Technology Group Lab Services for i2卓越中心和DB2 for i優化器團隊對本文的審閱和評論。

翻譯自: https://www.ibm.com/developerworks/ibmi/library/i-accelerated-analytics-db2-evi-tech/index.html

總結

以上是生活随笔為你收集整理的1叉叉加速器分析_加速分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。