GaussDB(DWS)性能調優系列基礎篇三：衍化至繁之分布式計劃詳解

前言

前面兩基礎篇已經分別介紹了性能調優最基本的數據庫命令ANALYZE和EXPLAIN，本篇作為基礎篇的最終篇，主要基于分布式數據庫GaussDB(DWS)中產生的分布式計劃多種多樣的特點，補充對現有分布式計劃種類及其性能優劣的詳細介紹。

1、 分布式架構

說到分布式計劃就不得不提到數據庫的分布式架構，當前數據庫分布式架構主要有Shared Nothing和Shared Disk兩種：

Shared Disk：各處理單元共享數據磁盤系統但私有CPU和Memory資源，可通過增加節點來提高并行處理的能力，擴展能力較好，但是當存儲器接口達到飽和的時候，增加節點并不能獲得更高的性能。業界代表Oracle Rac。

Shared Nothing：各處理單元都有自己私有的CPU/內存/硬盤等，不存在共享資源，各處理單元之間通過協議通信，并行處理和擴展能力更好。業界代表Teradata。

GaussDB(DWS)基于Shared Nothing架構，繼承了該架構良好的并行處理和擴展能力，但是也因數據分布存儲不共享的特點，計劃的生成需要面對數據傾斜、節點間數據交互等常見問題，生成的計劃相對復雜。

2、分布式計劃

2.1 計劃種類：

GaussDB(DWS)中當前主要存在三類分布式計劃， FQS(fast query shipping)計劃、Stream計劃以及Remote-Query計劃，其中前兩類都可稱之為下推計劃，執行性能一般較好，而Remote-Query計劃是前兩類計劃都無法生成情況下的最后選擇，執行性能一般較差。各類計劃介紹如下表，其中CN(Coordinator Node)表示數據庫全局SQL解析優化節點又稱協調節點，DN(Data Node)表示數據庫數據存儲節點也是計算單元。

計劃種類

執行原理

子場景

適用場景

FQS計劃

CN直接將原語句下發到DN，各DN單獨執行，并將執行結果在CN上進行匯總。

整個SQL下發所有DN（典型場景）

各DN執行時無數據交互。

整個SQL下發單個DN（Lightproxy場景）

單DN能完全執行出結果，常見于TP點查場景。

Stream 計劃

CN根據原語句生成計劃并將計劃下發給DN進行執行，各DN執行過程中使用Stream算子進行數據交互。

全部計劃下發DN執行（全部下推）

各DN執行時有數據交互，常見于AP復雜語句場景。

部分計劃下發DN執行（部分下推）

常見于子查詢可下推，父查詢存在不下推因素場景。

Remote-Query 計劃

CN生成計劃后，將部分原語句下發到DN，各DN單獨執行，執行后將結果發送給CN，CN執行剩余計劃。

僅當前單場景

不滿足FQS和STREAM計劃的極端場景，性能較差。

1）場景示例

前置：表定義和函數定義

示例1：FQS計劃之典型場景

計劃解讀：join條件中t1.a和t2.a都是各自表的分布列，所以join能夠匹配上的數據都在同一個DN，所以DN間不需要數據交換，原語句直接下發DN執行即可。

示例2：FQS計劃之Lightproxy場景

計劃解讀：因t1.a是表t1的分布列，所以能夠匹配上t1.a=1的數據只在某一個DN上，所以這個計劃執行相比典型的FQS應該更簡單，只在某一個DN上執行即可（例如上面計劃所示，只在datanode5執行）。

示例3：Stream計劃之全部下推場景

計劃解讀：join條件中t2.b列不是t2的分布列，所以需要對t2表按照a列做REDISTRIBUTE重分布，才能保證每個DN做join時能獲取到所需的t1和t2表的對應數據。

示例4：Stream計劃之部分下推場景

計劃解讀：unship_func為不能下推的函數，但是from后面的子查詢可以下推，這種情況直接把子查詢下推到了DN，執行完把數據返回給CN并在CN上調用unship_func計算出最終結果。

示例5：Remote-Query計劃場景

計劃解讀：因unship_func不能下推，且不滿足部分下推要求（子查詢下推），所以只能發送基表掃描的語句到DN，將基表數據收集到CN上來計算。

2）小結

FQS計劃和Stream計劃下推到DN后，DN上能夠執行除了scan之運算操作（例如join），但是Remote-Query計劃中DN除了scan做不了其他任何運算，DN的計算資源沒有得到充分利用，所以這類計劃執行效率較前面幾類差很多。同時，在前面介紹的這三大類計劃中，AP復雜查詢場景以Stream計劃和Remote-Query計劃最為常見，所以下面針對這兩類計劃進行進一步介紹。

2.2 Stream計劃

說到Stream計劃必須要說一說stream算子，stream算子是專門針對shared nothing型數據庫數據不共享的特征所實現的一種算子，用于解決單個DN在運算過程中需要用到其他DN數據的情況，該算子的詳細介紹參見《GaussDB(DWS)性能調優系列基礎篇二：大道至簡explain分布式計劃》中的第一章節，下面以“兩表join”和“雙層agg”兩個典型場景介紹stream計劃生成過程中如何選擇合適的stream算子，生成最優的stream計劃。

1）兩表join場景

例如，有兩張表t1(a,b)和t2(a,b)，t1按照t1.a進行hash分布，t2按照t2.a進行hash分布，當t1和t2進行join時，join列的不同將需要不同的stream算子：

JOIN條件

需要stream

可能生成的路徑

t1.a = t2.a

否

local(t1) join local(t2)

t1.a = t2.b

是

local(t1) join redistribute(t2)或broadcast(t1) join local(t2)

t1.b = t2.a

是

redistribute(t1) join local(t2)或local(t1) join broadcast(t2)

t1.b = t2.b

是

redistribute(t1) join redistribute(t2)或broadcast(t1) join local(t2)或local(t1) join broadcast(t2)

其中關于redistribute和broadcast的選擇主要是根據cost代價評估來選擇，大致來說，大表join小表的場景，小表傾向做broadcast，大表傾向做redistribute，這樣能夠會最小化DN間通信交互的數據量，減少通信交互的開銷，所以在調優過程中，如果通過explain發現大表在做broadcast，就要引起注意，可以通過調整分布列、planhint、SQL改寫等方式修正計劃以達到調優的目的，插播一條小廣告，更多的計劃調整方式會在后續“GaussDB(DWS)性能調優系列實戰篇”中逐步的詳細介紹

2）雙層agg場景

例如，聚集操作group by列中不包含分布列時，意味著需要聚集的同組數據可能在不同的DN上，這時就需要通過redistribute按照group by列進行重分布，可能生成如下三種計劃：

GaussDB(DWS)根據cost估算來決定選擇上面哪個計劃主要就兩點原則：

1、DN上第一層agg整體返回的數據很少時，就不需要redistribute，而直接把數據返回CN做最終的agg即可。

2、DN上第一層agg整體返回的數據較多時，如果agg能過濾的數據也較多，則先做agg，否則先做redistribute。

簡單點說，先做agg還是先做redistribute主要看先做agg是否能有效過濾數據，從而減少后續redistribute的數據量和傳輸代價，而在CN做二層agg還是DN做二層agg主要看第一層agg返回的整體數據量多少，因為這決定了Gather(數據從DN->CN)的代價。

3）小結

從前面兩個典型場景可以看出，對stream算子broadcast/redistribute的選擇，主要就是評估stream算子傳輸的數據量和代價，以減少stream傳輸數據量、降低通信消耗為基本原則。

2.3 Remote-Query計劃

可能有人會有疑問，既然前面說Remote-Query是性能最差的計劃，那為什么還要生成這種計劃？主要是因為存在一些因素會導致執行算子無法在分散到各個DN分別執行而只能在CN上來統一執行，否則執行結果會出現錯誤。這些因素常被稱之為不下推因素，最常見的不下推因素有不支持下推的函數和不支持下推的語法。

1）不下推因素之函數

數據庫函數有兩個關鍵屬性provolatile和proshippable共同決定函數是否可以下推，其中provolatile屬性的取值范圍主要有IMMUTABLE、STABLE、VOLATILE三種：

IMMUTABLE：簡單來講，如果一個函數對于同樣的輸入，一定有相同的輸出，那么這類函數就是IMMUTABLE的，例如絕大部分的字符串處理函數。

STABLE：如果一個函數的返回結果在一個SQL語句的調用過程中，結果是相同的，那么他就是STABLE的。例如時間相關的處理函數，這類函數都是STABLE的。

VOLATILE：如果一個函數的返回結果可能隨著每一次的調用而返回不同的結果。例如nextval，random這種函數，每次調用結果都是不可預期的。

根據屬性的介紹可以看到，IMMUTABLE/ STABLE屬性的函數是比較穩定的，也就是對于相同的輸出，輸出的結果比較固定，這類函數分散到不同的DN執行，結果也不會有多大變化，而VOLATILE函數則不行，所以絕大部分的IMMUTABLE/ STABLE屬性函數是可以下推的，VOLATILE函數則不能下推，具體下推情況如下表：

provolatile/proshippable

true

false

IMMUTABLE

可下推

可下推

STABLE

可下推

不可下推

VOLATILE

可下推

不可下推

需要注意的是當我們創建自定義函數時，默認的provolatile屬性是volatile的， proshippable屬性是false，也就是函數默認不下推，如果希望將函數定義為下推函數一定要清楚的理解這兩個屬性的含義，否則不能下推的函數下推了會導致執行結果的錯誤。

2）不下推因素之語法

無法下推的語法都有一定的特殊性，其中以“count(distinct expr)中的字段不支持重分布”場景為例：

例子中，distinct的b列為bool類型，不能做分布列，所以在DN通過局部的數據無法算出有效的distinct，所以這種場景不能下推，只能是DN把數據返回給CN統一執行，否則最終的計算結果會出現錯誤。

3）小結

從上面兩個場景可以看出，產生Remote-Qeury計劃一定是存在不下推因素導致，所以如果在業務調優場景發現Remote-Query計劃，需要通過CN日志等方式第一時間找到不下推因素，然后通過改寫、替換等方式將Remote-Query計劃轉變成Stream計劃，以達到提高性能的目的。

結語

數據庫性能調優是一個系統工程，除了要熟練掌握數據庫ANALYZE和EXPLAIN命令外，還需具備對數據庫各類計劃深度解讀的能力，并結合操作系統I/O、內存等各方面的資源使用情況等進行整體分析，最終實現高效的性能調優。

數據倉庫服務 GaussDB(DWS) 應用性能調優 Gauss AP 分布式 EI企業智能

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。