華為云GaussDB(for openGauss)專場直播第5期：SQL優化解讀

1.前言

在關系型數據庫中，優化器是數據庫的核心組件之一，由于一些列因素都會影響語句的執行，優化器綜合權衡各個因素，在眾多的執行計劃中選擇認為是最佳的執行計劃。隨著大數據時代的到來，像電商、游戲、電信等行業都大規模的應用，單一數據庫節點是難以應對數據規模的不斷增長并確保性能的需要，業務面臨“存不下、算得慢、算不準”的問題。而GaussDB(for openGauss)采用了可橫向擴展的分布式架構，可以很好滿足大規模海量數據的存儲和計算的需求，其通過目標SQL執行計劃的CBO成本，從目標SQL的諸多執行計劃中選取成本值最小的執行路徑為其執行計劃，各執行路徑的成本值是根據目標SQL中涉及到的表、索引、列等相關對象的統計信息計算出來的，實際反應執行目標SQL所要消耗的I/O、CPU和網絡資源的一個估計值。

I/O資源：把表的數據從磁盤讀入內存時所需代價

CPU資源：處理內存中表的數據所需的代價

網絡資源：需要DN間數據交互的分布式SQL，在實際執行時所需要的數據并不在本地DN中（需要從其他DN中取數據），便會將網絡資源消耗折算成對等的I/O資源消耗再進行估算。

本文結合第5場直播內容從分布式并行執行框架、分布式執行計劃等方面進行介紹。

2.分布式并行執行框架

2.1? 執行器：PIPELINE模型

GaussDB(for openGauss)的執行器特點是：按照查詢計劃樹從底往上執行，基于火山模型執行，即每個節點執行返回一行記錄給父節點。

火山模型的最大優點就是可以按需請求，每次只取出一條元組，在處理本條元組后，系統將會取出下一條滿足條件的元組，直到取出所有滿足條件的元組為止。從這種方式的運行機制可以看出，其每次執行時對于系統資源的需求都非常小。

2.2 ?高性能分布式查詢引擎

GaussDB(for openGauss)充分利用當前多核特點，通過多線程并發執行，提高系統吞吐量。眾所周知，在傳統的分布式?MPP?數據庫中，因數據的重分布，也就是數據shuffle的代價非常昂貴，從而限制了用戶使用場景范圍。

GaussDB(for openGauss)能充分利用當前多核特點，采用并行執行機制，在SQL執行優化方面有多年的沉淀，并提供了三種stream流（廣播流、聚合流和重分布流）來降低數據在DN節點間的流動，突破了傳統分布式?MPP?數據庫因為數據shuffle代價高昂帶來的用戶使用場景限制，即使是復雜的SQL、事務分析混合（HTAP）場景也能得到最佳執行。

GaussDB(for openGauss)的大致執行過程：

業務應用下發SQL給Coordinator?，SQL可以包含對數據的CRUD操作；

Coordinator利用數據庫的優化器生成執行計劃，每個DN會按照執行計劃的要求去處理數據；

數據基于一致性Hash算法分布在每個DN，因此DN在處理數據的過程中，可能需要從其他DN獲取數據，GaussDB提供三種stream流（廣播流、聚合流和重分布流）實現數據在DN間的流動，使得join無需抽取到CN執行；

DN將結果集返回給Coordinate進行匯總；

Coordinator將匯總后的結果返回給業務應用。

3.分布式執行計劃

CN根據表的分布列信息和關聯列信息進行判定，SQL語句是否可以直接在各個DN上執行而且不需要數據交流，如果是，CN采用LIGHT_QUERY或FQS_QUERY流程，保持了事不關己的態度，你發給我什么我就下發什么，直接將整個query命令下發給DN執行，執行完成后直接輸出；如果需要在各個DN之間進行數據交互，則會選擇使用stream算子；如果發現無法使用stream算子時，就回到了原始的PGXC流程。

3.1? LIGHT_QUERY

-?場景：語句可以直接在一個DN執行（單shard語句，點查場景）。

-?原理：CN直接下發語句QPBE報文到對應DN，這樣的做的好處是，執行效率高，線性擴展比好。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1); create table t2 ( col1 int, col2 varchar ) distribute by hash(col1);

3.2? FQS_QUERY

-?場景：當語句可以完全下推到多個DN上執行，且DN之間不需要數據交互時。

-?原理：CN不通過優化器，直接生成RemoteQuery計劃，走執行器邏輯下發到DN，各DN根據下推語句生成執行計劃并進行執行，執行結果在CN上進行匯總。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1); create table t2 ( col1 int, col2 varchar ) distribute by hash(col1);

LIGHT_QUERY和FQS_QUERY的最大異同點在于，雖然CN都是經過判定后直接把收到的query下發給DN進行處理，但是LIGHT_QUERY只涉及到單DN進行操作，而FQS_QUERY涉及到多個DN分別進行操作，它們都不會涉及到DN間的數據交互。

3.3? STREAM GATHER

-?場景：需要各DN之間進行數據交互。

-?原理：CN根據原語句通過優化器生成帶stream算子的執行計劃，下發給DN進行執行，DN執行過程中存在數據交互（stream節點），stream算子在DN之間建立連接進行數據交互，CN匯總執行結果并承擔大部分計算。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1); create table t2 ( col1 int, col2 varchar ) distribute by hash(col2);

3.4? STREAM REDISTRIBUTE

-?場景：需要各DN之間進行數據交互。

-?原理：CN根據原語句通過優化器生成帶stream算子的執行計劃，下發給DN進行執行，各DN執行過程中存在數據交互（stream節點），stream算子在DN之間建立連接進行數據交互，CN匯總執行結果并承擔大部分計算。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1); create table t2 ( col1 int, col2 varchar ) distribute by hash(col2);

3.5? STREAM BROADCAST

-?場景：需要各DN之間進行數據交互。

-?原理：CN根據原語句通過優化器生成帶stream算子的執行計劃，下發給DN進行執行，各DN執行過程中存在數據交互（stream節點），stream算子在DN之間建立連接進行數據交互，CN匯總執行結果并承擔大部分計算。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1); create table t2 ( col1 int, col2 varchar ) distribute by hash(col2);

使用REDISTRIBUTE算子時，數據進行重分布可以充分利用多個節點的算力，而BROADCAST算子主要用于stream的子計劃產生的數據量較少的情況，此時BROADCAST的代價較少。

3.6 PGXC

-?場景：不能滿足前面處理方式的極端場景，性能非常差。

-?原理：CN通過優化器把原語句中的部分語句生成RemoteQuery計劃，把每個RemoteQuery下發到DN，DN執行后把中間結果數據發送給CN，CN收集后進行剩余執行計劃的執行計算，CN承擔了大部分計算。

總結

綜上所述，GaussDB(for openGauss)作為自主研發的新一代金融級分布式關系型數據庫，采用可橫向擴展的分布式架構，通過SQL優化器生成分布式算子以及分布式執行計劃，提供了三種stream流（廣播流、聚合流和重分布流）來降低數據在DN節點間的流動；執行引擎是一個分布式并行執行框架，支持節點間并行和節點內并行能力，充分利用當前多核特點，通過并發執行，提高系統吞吐量，具備大數據下高性能查詢能力。

Ps：更多精彩內容，請點擊回播鏈接進行觀看：https://bbs.huaweicloud.com/live/cloud_live/202107061900.html

SQL 云數據庫 GaussDB(for openGauss) 視頻直播

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

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