PolarDB：概述

功能簡介

彈性並行查詢（Elastic Parallel Query，ePQ）目前支援單機並行和多機並行兩種並行引擎，單機並行引擎等效於原有的並行查詢，多機並行引擎支援叢集內跨節點的自適應彈性調度。

PolarDB MySQL版8.0.1版本支援單機並行查詢，查詢時在儲存層將資料分區到不同的線程上，單個節點內多個線程並行計算，將結果流水線匯總到匯流排程。最後匯流排程做簡單歸併返回給使用者，提高查詢效率。

PolarDB MySQL版8.0.2版本除了支援原有的單機並行查詢，又將線性加速能力提升了一個等級，引入了多節點分布式並行計算能力，即多機並行查詢。基於代價將執行計畫最佳化為更靈活的並存執行計劃，改進了單機並行查詢可能存在的Leader單點瓶頸和Worker負載不均衡的問題，同時突破了單個節點在CPU、Memory、IO上的資源瓶頸。基於多節點的資源檢視，自適應的調度並行計算任務，在大幅提升並行計算能力、降低查詢延遲的同時，平衡了各節點的資源負載，提升叢集整體的資源使用率。

彈性並行查詢（Elastic Parallel Query）針對雲上使用者執行個體CPU資源使用率較低、使用不均衡的特徵，充分挖掘叢集中多核CPU的平行處理能力，以8核32 GB（獨享規格）的PolarDB MySQL版叢集版為例，示意圖如下所示：

前提條件

如何查看叢集版本，請參見查詢版本號碼。

應用情境

並行查詢適用於大部分SELECT語句，例如大表查詢、多表串連查詢、計算量較大的查詢。對於非常短的查詢，效果並不顯著。同時由於並行方式的多樣化，可以適用於多種廣泛而靈活的應用情境：

• 海量資料分析情境

  在中等及更大規模資料量的情況下，分析類業務的報表查詢SQL通常複雜且比較耗費時間，通過開啟並行查詢可以線性降低查詢的回應時間。

• 資源負載不均衡情境

  叢集內的多個節點可以藉助資料庫代理的負載平衡能力，使每個節點的並發串連數大致相同。但由於不同查詢的計算複雜度、資源使用方式各有差異，基於串連數的load balance無法完全避免節點間負載不均衡的問題。同所有分散式資料庫一樣，熱點節點也會對PolarDB造成一定的負面影響：

  1. 如果RO節點過熱使得查詢執行過慢，可能造成RW節點無法purge undo log導致磁碟空間膨脹。

  2. 如果RO節點過熱導致redo apply過慢，會導致RW節點無法刷髒降低RW節點的寫吞吐效能。

  彈性並行查詢引入全域資源檢視機制，並基於該視圖做自適應調度，依據各節點的資源使用率和資料親和性反饋，將查詢的部分甚至全部子任務調度到有空閑資源的節點上，在保證目標並行度的基礎上均衡叢集資源使用率。

  

• 彈性計算情境

  如前所述，彈性是雲原生資料庫的PolarDB的核心能力之一，自動擴、縮容功能提供了對短查詢類業務非常友好的彈效能力，但之前並不適用於複雜分析類業務，因為對於大查詢情境，單條查詢仍無法通過增加節點實現提速。而現在開啟彈性並行查詢（ePQ）的叢集，新擴充的節點會自動加入到叢集分組中共用計算資源，彌補了之前彈效能力上的這一短板。

  

• 在離線業務混合情境

  前面提到了多個子叢集的實體資源隔離能力，最徹底的隔離方式是將線上交易業務和離線分析業務劃定為不同節點集合，但如果使用者在意成本，這種模式會顯得有些浪費。因為很多情況下，在、離線業務會有不同的高、低峰特性，更經濟的方式是通過錯峰使用，讓不同業務共用部分叢集資源，但使用不同的叢集地址承接業務。通過開啟彈性並行，讓離線業務重疊使用線上業務低峰期的空閑資源，進一步降本增效。

  

使用說明

關於如何使用彈性並行查詢，請參見使用說明。

效能指標

本次測試將使用TPC-H產生100 GB資料來測試PolarDB MySQL版8.0版本叢集的效能指標。測試用的PolarDB叢集規格為32核256 GB（獨享規格）×4節點，單節點並行度max_parallel_degree分別設定為32和0，對比PolarDB串列執行、單節點32並行度執行、4節點128並行度執行的效能資料，具體測試步驟請參見並行查詢效能。

通過以上測試結果圖得出，TPC-H中100%的SQL可以被加速，平均加速比在17倍，最高加速比56倍。

開啟多機並行後，平均加速比在59倍，最高加速比159倍。

並存執行EXPLAIN

更多關於EXPLAIN執行計畫輸出中與並行查詢相關的內容，請參見使用EXPLAIN查看並行計劃。

相關概念

• 並行掃描

  在並行掃描中，每個Worker並行獨立掃描資料表中的資料。Worker掃描產生的中間結果集將會返回給Leader線程，Leader線程通過Gather操作收集產生的中間結果，並將所有結果匯總返回到用戶端。

• 多表並行串連

  並行查詢會將多表串連操作完整的下推到Worker上去執行。PolarDB最佳化器只會選擇一個自認為最優的表進行並行掃描，而除了該表外，其他表都是一般掃描。每個Worker會將串連結果集返回給Leader線程，Leader線程通過Gather操作進行匯總，最後將結果返回給用戶端。

• 並行排序

  PolarDB最佳化器會根據查詢情況，將ORDER BY下推到每個Worker裡執行，每個Worker將排序後的結果返回給Leader，Leader通過Gather Merge Sort操作進行歸併排序，最後將排序結果返回到用戶端。

• 並行分組

  PolarDB最佳化器會根據查詢情況，將GROUP BY下推到Worker上去並存執行。每個Worker負責部分資料的GROUP BY。Worker會將GROUP BY的中間結果返回給Leader，Leader通過Gather操作匯總所有資料。這裡PolarDB最佳化器會根據查詢計劃情況來自動識別是否需要再次在Leader上進行GROUP BY。例如，如果GROUP BY使用了Loose Index Scan，Leader上將不會進行再次GROUP BY；否則Leader會再次進行GROUP BY操作，然後把最終結果返回到用戶端。

• 並行聚集

  並行查詢執行聚集合函式下推到Worker上並存執行。並行聚集將基於最佳化器代價，選擇串列執行、一階段聚集或者兩階段聚集。

  • 一階段聚集：將聚集操作分發到Worker中，每個worker包含對應分組中的全部資料。因此無需第二階段的匯總聚集計算，各個Worker直接計算得到所擁有分組的最終聚集結果，避免Leader再次聚集。

  • 兩階段聚集：在第一次，參與並行查詢部分的每個Worker執行聚集步驟；第二次，Gather或Gather Merge節點將每個Worker產生的結果匯總到Leader。最後，Leader會將所有Worker的結果再次進行聚集得到最終結果。

  • 兩階段shuffle聚集：在第一次，參與並行查詢部分的每個Worker執行聚集步驟；第二次，Repartition節點將每個Worker產生的結果，按照分組列分發到多個worker，worker並行完成最終聚集計算。最後，聚集結果匯總到Leader。

  採用哪種聚集執行方式由PolarDB最佳化器根據代價來決定。

• 並行視窗函數

  PolarDB最佳化器會根據代價計算，將Window Function分發到Worker上並存執行，每個Worker負責部分資料的計算，分發方式根據Window Function中Partition by子句的key來決定。因此如果Window Function中沒有使用Partition by子句，只能串列完成計算。但如果後續計算仍可以並行，會根據代價，重新將後續計算任務分發到多個Worker上執行，保證最大程度的並行化。

• 子查詢支援

  在並行查詢下子查詢有四種執行策略：

  • 在Leader線程中串列執行

    當子查詢不可並存執行時，例如2個表JOIN，在JOIN條件上引用了使用者的函數，此時子查詢會在Leader線程上進行串列查詢。

  • 在Leader上並存執行（Leader會啟動另一組Worker）

    產生並行計劃後，在Leader上執行的計劃包含有支援並存執行的子查詢，但這些子查詢不能提前並存執行（即不能採用Shared access)。例如，當前如果子查詢中包括window function，子查詢就不能採用Shared access策略。

  • Shared access

    產生並行計劃後，Worker的執行計畫引用了可並存執行的子查詢，PolarDB最佳化器會選擇先提前並存執行這些子查詢，讓Worker可以直接存取這些子查詢的結果。

  • Pushed down

    產生並行計劃後，Worker執行計畫引用了相互關聯的子查詢，這些子查詢會被整體推送到Worker上執行。