1. 程式人生 > >十八般武藝玩轉GaussDB(DWS)效能調優:路徑干預

十八般武藝玩轉GaussDB(DWS)效能調優:路徑干預

摘要:路徑生成是表關聯方式確定的主要階段,本文介紹了幾個影響路徑生成的要素:cost_param, scan方式,join方式,stream方式,並從原理上分析如何幹預路徑的生成。

一、cost模型選擇

顧名思義,cost_param是控制cost相關的一個引數。在瞭解cost_param之前,先回顧一下選擇率的概念,GaussDB優化器中的選擇率是指,當一個表有一個過濾或關聯條件時,通過該條件能被選中的行數佔總行數的比例,是介於0~1之間的一個實數。選擇率在優化器中是一個重要的概念,主要應用於行數和distinct值的估算,行數和distinct值是計劃生成中的基本要素。

首先,我們來看帶有過濾條件的基錶行數如何估算。如果一個表只有一個過濾條件,那麼以選擇率乘以表的行數,即可得到過濾完的行數;如果有多個過濾條件,那麼就需要算出一個綜合的選擇率,如何計算?方式有二:一是通過多列統計資訊直接計算,二是通過組合單列的選擇率。那麼組合的方式就由引數cost_param決定了,具體地,

舉一個例子,TPC-H 1x的part表,過濾條件是:p_brand = 'Brand#45' and p_container = 'WRAP CASE',檢視不同cost_param下的過濾後行數。

(1)cost_param=0

(2)cost_param=2

從估算出的行數(E-rows)和實際的行數(A-rows)對比可以看出,cost_param=0的不相關模型適合part表的p_brand和p_container列。

其次,Join的行數怎麼估算的呢?原理跟過濾條件的行數估算是類似的,如果沒有多列統計資訊可以使用,則也需要單獨計算每個條件的選擇率,然後計算出綜合選擇率,得出行數。例如 TPC-H 1x lineitem和orders關聯,關聯條件是:l_orderkey = o_orderkey and o_custkey = l_suppkey,不同cost_param的執行情況如下:

(1)cost_param=0

(2)cost_param=2

此例中,Join的列之間也適合完全相關模型,這與l_orderkey和l_suppkey的分佈是吻合的。

由於TPC-H的模型接近完全不相關模型,因此cost_param=0模型可以較好的描述場景,實際應用中,使用者可以根據具體業務場景來調整模型,行數估算的準確性是計劃生成的重要保證,在調優中檢查估算的最直接的地方。GaussDB會在後續版本中新增更多的模型供業務需求選擇。

二、Scan方式的選擇

GaussDB中掃描方式主要分順序掃描和索引掃描,每種掃描方式都對應若干掃描運算元,順序掃描在行列存中對應的掃描運算元分別是Seq Scan和CStore Scan運算元(下面我們討論中不加區分)。這些掃描運算元大部分都可以通過開關來進行調控,例如Seq Scan,如果設定enable_seqscan=off,則表示不會優先選擇Seq Scan,而不是一定不會選。掃描方式的選擇,很大程度上決定了獲取基表資料的路徑。我們以如下的例子來說明:

select l_orderkey, o_custkey from lineitem, orders where l_orderkey = o_orderkey;

lineitem分佈鍵是l_orderkey,並且在l_orderkey上有index,orders分佈鍵是o_orderkey。預設情況下,Scan的方式如下:

兩個表都是順序掃描的路徑,關聯方式選擇了Hash Join。如果把Seq Scan關掉(enable_seqscan=off),計劃如下:

lineitem的掃描變成了Index Only Scan(因為l_orderkey的型別是int),而在orders表上仍然選擇Seq Scan(因為沒有其他路徑),同時關聯方式也變為了Nest Loop,因為Hash Join需要全表掃描資料(lineitem的Seq Scan已經被關掉了)。優化器的選擇方式我們從代價(E-costs)一欄中也可以看出。再把Index Only Scan關掉,看看計劃如何變化:

掃描路徑都變為了Seq Scan,而且Seq Scan的代價都很大。此時既然都走了Seq Scan,為什麼不選Hash Join呢,把Nest Loop關掉,看看Hash Join計劃的代價:

從代價上看出Hash Join的總代價比Nest Loop的小,但優化器沒有選擇Hash Join,這是因為優化器比較路徑代價時,會比較Startup和Total代價,即啟動代價和總代價,綜合考慮,E-costs欄中顯示的是總代價。把explain_perf_mode設定為normal,檢視原Nest Loop的啟動代價:

紅框中的兩個cost,分別是啟動代價和總代價,在看Hash Join的cost,明顯Hash Join的啟動代價比Nest Loop的大很多(啟動代價代表了輸出第一條資料的代價),優化器在比較路徑時,綜合了這兩個代價,最終推薦了Nest Loop的路徑。

從上面的例子可以看出,掃描路徑的調控,可以改變路徑生成,合理的搭配是生成最優計劃的前提,預設情況下,GaussDB優化器可以根據現有的路徑選擇(如上面的lineitem有兩條掃描路徑,orders只有一條掃描路徑),最後確定出最優的一條。兩條路徑代價比較時,總代價不是唯一要素,但總代價越小,一般也會越容易被選中。

三、關聯方式的選擇

GaussDB優化器中表關聯的主要方式有:Nest Loop,Hash Join和Merge Join,分別可以通過enable_nestloop、enable_hashjoin、enable_mergejoin進行控制,這種控制也不是絕對的,可以理解為是否優先選擇。大部分場景下,三種路徑的代價關係:Hash Join < Merge Join < Nest Loop。我們以一個簡單的關聯示例說明,store_returns和store_sales是TPC-DS 1x中兩個表,SQL如下:

select count(*) from store_returns, store_sales where sr_customer_sk = ss_customer_sk;

預設情況下,優化器推薦Hash Join路徑,計劃如下:

如果把Hash Join關掉,則優化器選擇了Merge Join路徑:

如果再把Merge Join路徑關掉,可能就會選擇Nest Loop路徑。關聯方式的控制開關一般用於調優或規避問題,但具體是否能夠起作用要看具體的語句,除了當前關聯方式,還有沒有其他方式。實際場景中,一個語句中關聯的運算元較多,一般很難用引數enable_hashjoin或enable_nestloop或enable_mergejoin來控制某兩個表的Join方式,GaussDB中更細緻的語句級別的調優手段是Plan Hint,感興趣的讀者可以參考產品手冊。

四、Stream方式的選擇

Stream運算元是GaussDB分散式執行的關鍵運算元之一,主要起到網路傳輸的作用,概要介紹可以參考:GaussDB(DWS)效能調優系列實戰篇一:十八般武藝之總體調優策略。Stream運算元由引數enable_stream_operator控制,如果關掉Stream運算元,則可能導致生成不下推的計劃,例如:

因為lineitem表關聯的鍵l_partkey不是lineitem的分佈鍵,需要新增Stream運算元,但Stream功能被禁,於是只能生成不下推計劃。

GaussDB計劃中常見的主要Stream運算元包括Redistribute、Broadcast和Gather。Gather一般是分散式計劃中,CN用於收集DN的資料進行最後的處理,除非最後收集的行數非常多,這個運算元涉及效能問題一般較少。Redistribute和Broadcast一是對“互補”的運算元,前者用於重分佈,後者用於廣播,生成計劃時,優化器會根據代價大小來選擇。當Join Key沒有包含表的分佈鍵的時候,一般會新增Redistribute路徑,能選擇Redistribute路徑理論上也可選擇Broadcast路徑,最終選擇哪條路徑要看優化器估算的代價是多少。這兩個運算元可以通過引數enable_redistribute和enable_broadcast進行控制。

在SMP開啟的情況下,當並行度(dop)大於1時,一般還會有Local Redistribute、Split Redistribute、Local Broadcast和Split Broadcast;當傾斜優化開啟時,還有PART REDISTRIBUTE PART ROUNDROBIN、PART_REDISTRIBUTE_PART_BROADCAST、PART_REDISTERIBUTE_PART_LOCAL等等,這些也是Stream運算元,主要就是重分佈、廣播、RoundRobin的一些擴充套件形式,這裡我們不一一介紹了,感興趣的讀者可以參考GaussDB DWS 產品手冊。

我們考慮兩個表的簡單關聯,store_sales和sr_tbl,它們的分佈鍵分別是ss_item_sk 和sr_returned_date_sk,Join 條件是store_sales.ss_customer_sk =sr_tbl. sr_customer_sk,執行結果如下:

由於兩個表的分佈鍵都不是Join Key,因此走Hash Join路徑的話需要有一個表做Broadcast或者兩個表都做Redistribute,但是store_sales表比較大(E-rows顯示28.7億行),而sr_tbl錶行數估算比較少(E-rows顯示100行),優化器認為適合做Broadcast。於是最終選擇了一邊Broadcast的計劃。

對於這個計劃,由於sr_tbl表統計資訊不準確(如果是中間結果集,則表示中間結果集估算不準),一種調優的方法是,將sr_tbl的表統計資訊重新收集準確一些(如果sr_tbl是中間結果集,則無法收集),另一種方法是讓sr_tbl走Redistribute路徑,而後者我們又有兩種方式來實現,一是用Plan Hint,即在生成計劃時,告訴優化器走Redistribute路徑,二是把Broadcast關掉。禁用Broadcast後,執行計劃如下:

本列中,開啟了SMP自適應,即優化器會根據系統資源和當前Active SQL數量來自行決定並行度(dop),如果Redistribute和Broadcast選擇不當,則可能導致

(1)Broadcast計劃會出現下盤

(2)兩個計劃的並行度不一樣,最終執行時間可能會差異比較大。

對於Stream方式的控制,一般的調優方式有Plan Hint、GUC引數、改善統計資訊或估算資訊。

五、結束語

本文介紹的cost_param屬於cost底層引數,建議對資料特徵和使用場景比較熟悉的DBA慎重使用。Scan、Join、Stream調控的基本依據也是代價,代價一般體現在執行耗時上,調優時可從Performance中識別出效能的瓶頸點,分析選擇的運算元是否與代價匹配。另外,除了本文介紹的Session級別的控制引數外,還有基表、中間結果的行數,也可以通過Plan Hint進行語句級別的調控,感興趣讀者可通過GaussDB DWS產品文件進一步瞭解。

本文分享自華為雲社群《GaussDB(DWS)效能調優系列實戰篇五:十八般武藝之路徑干預》,原文作者:- 大道至簡 - 。

 

點選關注,第一時間瞭解華為雲新鮮技