摘要：在關係型數據庫中，優化器是數據庫的核心組件之一，由於一些列因素都會影響語句的執行，優化器綜合權衡各個因素，在衆多的執行計劃中選擇認爲是最佳的執行計劃。
本文分享自華爲雲社區《華爲雲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