多機分析 - PolarDB

本文介紹PolarDB MySQL版列存表的多機並存執行能力，包括技術架構、適用情境、最佳實務和效能測試。

說明

若您對列存表多機並行功能有任何問題，可通過DingTalk搜尋群號入群諮詢。您可以直接@群內專家，並附上您要諮詢的問題。

DingTalk群號：24490017825

背景資訊

列存表是PolarDB的OLAP解決方案。隨著查詢資料量、查詢複雜度以及對OSS等外部表格的查詢需求的增加，單個唯讀節點已無法滿足海量資料情境下的效能需求。因此，列存表叢集提供了多機並存執行能力和資源彈升能力。

技術架構

列存表多機並行是由多個唯讀節點群組成的一個多機執行組，並提供多機並存執行能力。隨著查詢負載的變化，您可以快速增加或減少唯讀節點的個數，以平衡查詢效能和計算成本。

適用範圍

您的PolarDB MySQL版版叢集需滿足以下條件：

產品版本：企業版。
核心版本：MySQL 8.0.2，且核心小版本需為8.0.2.2.34及以上版本。

適用情境

通過多機並行的資源彈升能力擴充CPU和IOPS，降低查詢時延。
通過每個節點只處理部分資料來提升資料緩衝能力。

最佳實務

在處理海量資料的分析查詢時，核心目標是減少資料轉送（Shuffle）和減少磁碟讀取（I/O）。PolarDB的列存表通過分區鍵和排序鍵這兩個強大的工具，協助您實現優越的查詢效能。

分區鍵

分區鍵用於在多個節點間分布資料，其核心思想是“讓相關的資料在一起計算”。

工作原理

PolarDB中一級或二級分區採用HASH和KEY類型的分區策略的分區表，列存表多機執行環境中的處理方式為Share-Nothing。這種方式意味著每個分區僅由一個節點進行處理。

核心優勢

提升資料緩衝能力：每個節點只需處理其負責的分區，有助於更有效地利用本地記憶體快取資料。
最佳化查詢效能：在基於分區鍵進行的JOIN 操作和GROUP BY查詢時，只需在每個節點上本地處理資料，即可顯著減少多機之間的資料轉送量。

最佳實務

選擇業務核心關聯鍵：優先選擇最常用的 JOIN 或 GROUP BY 的列作為分區鍵（例如 order_id, user_id）。
保持分區數量一致：進行 JOIN 的多個表，其 HASH/KEY 分區數量必須完全相同，否則無法實現本地化計算。
使用大質數作為分區數：推薦選擇一個足夠大的質數（如 97, 199）作為分區數量，這能最大程度地保證資料在各機器間均勻分布，避免資料扭曲。

排序鍵

排序鍵用於在每個物理分區內部組織資料，其核心思想是“跳過讀取不相關的資料”。海量資料的過濾可以通過使用範圍（range）類型的分區或在列存表中增加排序鍵來實現。

工作原理

在列式儲存中，資料被組織成多個資料區塊（Stripe）。通過設定排序鍵，每個資料區塊內部的資料會按照指定列物理有序。資料庫在查詢時，會利用每個資料區塊頭部的中繼資料（如最大/最小值）進行判斷。

核心優勢

高效資料裁剪：這是排序鍵的核心價值。當WHERE子句中包含對排序鍵的過濾條件時，查詢引擎可以直接跳過（裁剪掉）那些資料範圍完全不合格整個資料區塊，從而減少需要掃描的磁碟I/O。

最佳實務

選擇高頻過濾列：將 WHERE子句中頻繁使用的過濾列，特別是進行範圍查詢（>, <, BETWEEN）或高基數等值查詢的列，設為排序鍵。
組合使用，效果更佳：將排序鍵與RANGE類型的分區結合使用，可以實現多層次的過濾。

效能測試結果

以下是一組規格為32核256 GB，3個節點群組成的MPP叢集，在TPC-H 1 TB的全列存表多機測試結果：

說明

本文的TPC-H的實現基於TPC-H的基準測試，並不能與發行的TPC-H基準測試結果相比較，本文中的測試並不完全符合TPC-H的所有要求。

Query	Time(s)
Q1	8.189
Q2	0.567
Q3	1.784
Q4	1.38
Q5	2.268
Q6	2.359
Q7	2.068
Q8	1.593
Q9	10.761
Q10	10.054
Q11	0.795
Q12	7.595
Q13	10.848
Q14	3.023
Q15	2.286
Q16	2.253
Q17	11.651
Q18	25.612
Q19	11.557
Q20	2.739
Q21	4.82
Q22	3.141
TOTAL	127.343

常見問題

如何判斷SQL是否已啟用多機並行（MPP）？

PolarDB列存表的多機並行（MPP）能力可以加速複雜查詢。您可以通過分析SQ 的EXPLAIN執行計畫，輕鬆判斷查詢是否利用了這一強大特性。核心標誌是是否存在Exchange運算元。

第一步：強制產生 MPP 計劃，判斷“可能性”
首先，需要確認您的SQL語句本身是否具備被最佳化器改寫為MPP計劃的潛力。這可以通過一個特定的HINT來實現。
操作方法
在您的SQL語句前加上EXPLAIN，並插入/*+ SET_VAR(imci_plan_use_mpp=forced) */這個HINT。這個HINT會強制最佳化器嘗試產生一個MPP執行計畫。
樣本
```
EXPLAIN SELECT /*+ SET_VAR(imci_plan_use_mpp=forced) */ COUNT(*) FROM nation;
```
結果解讀
執行上述命令後，如果返回的執行計畫中包含了Exchange運算元，那麼恭喜您，這證明您的SQL邏輯上可以利用多機並行能力。
第二步：查看實際執行計畫，判斷“真實性”
確認了可能性之後，再來檢查在不加任何HINT的正常情況下，最佳化器是否實際選擇了MPP模式來執行您的 SQL。
操作方法
直接對您的原始SQL語句執行EXPLAIN。
樣本
```
EXPLAIN SELECT COUNT(*) FROM nation;
```
結果解讀
- 如果執行計畫中出現了Exchange運算元：這表明最佳化器在綜合評估成本後，認為MPP是最高效的方式，並已經為您的查詢啟用了多機並存執行。
- 如果執行計畫中沒有Exchange運算元：這可能意味著
  - 查詢過於簡單，或者涉及的資料量太小，最佳化器認為單機執行更快。
  - SQL 的寫法或表的結構（如分區鍵設定）限制了MPP的使用。您可以回到第一步，檢查並最佳化您的SQL 或表設計。