第三代DRDS分佈式SQL引擎全新發布

時間 2020-08-10

原文原文鏈接

DRDS （阿里雲分佈式關係型數據庫服務，https://www.aliyun.com/product/drds）於 4 月 30 號發佈了 5.3 版本，這是一個年度大更新。主要帶來了如下特性：html

性能提高。在大多數場景下（拆分鍵上的等值查詢、讀寫分離等），同規格的吞吐量（最大 QPS）能夠提高到以前的300%。
原生分佈式事務。無需額外付費或者開通，不依賴第三方組件，便可執行分佈式事務。提供柔性事務與 XA 兩種實現。
Outline。在無需改動程序的狀況下，便可經過建立 Outline 的形式改變 SQL 的執行計劃，例如指定索引、指定走主庫或者備庫等。
明確的 SQL 邊界文檔。在 SQL 邊界內，進行了大量的隨機測試，確保功能的穩定可靠。
更強大的分佈式查詢優化器。確保分佈式 SQL 執行代價的最小化。
簡潔易讀的執行計劃。提供一種新的執行計劃顯示格式，能夠很是方便的看出 SQL 的執行策略。

1. 性能

DRDS 5.3，使用了 Plan Cache、協程、FastSQL 等技術，大幅提高了吞吐量，在同規格下，最大 QPS 提高到了以前的 300%。
例如，對於以前的版本，8C16G 的 DRDS 最大能夠提供 2W/s 的 QPS；對於 DRDS 5.3，8C16G 的 DRDS 最大能夠提供 6W+/s 的 QPS。java

測試場景：

1.實例規格爲入門版 8C16G
2.測試工具爲 sysbench
3.後端 RDS 不存在瓶頸
4.測試 SQL：單表拆分鍵上的等值查詢node

SELECT * FROM t1 WHERE partition_key=?

5.持續加大併發，直至 DRDS CPU 接近 100%，而且 rt 在5ms左右mysql

Plan Cache

DRDS 5.3 中，引入了 Plan Cache，大幅下降了 SQL 解析與查詢優化的代價。DRDS 5.3 中，針對不一樣類型的 SQL，分紅了多級 Plan Cache，其中，性能最高的是命中了一級 Plan Cache 的 SQL。不管參數取值如何，必定能夠被下推到單分片執行的 SQL 會命中一級 Plan Cache，常見的形式有如下幾種：git

1.單表拆分鍵上的等值查詢，例如：github

SELECT * FROM t1 WHERE partition_key=?

2.拆分鍵上的等值 JOIN 查詢，而且至少其中一個錶帶了拆分鍵上的等值條件，例如：算法

SELECT * FROM t1 JOIN t2 ON t1.partition_key = t2.partition_key WHERE t1.partition_key=?

3.拆分鍵上的等值關聯子查詢，而且其中內表或者外表帶了拆分鍵上的等值條件，例如：sql

SELECT * FROM t1 WHERE EXSITS (SELECT 1 FROM t2 WHERE t1.partition_key = t2.partition_key) AND t1.partition_key=?

在應用中，更多的使用可以命中一級 Plan Cache 的 SQL，能更高的提高系統容量。數據庫

協程

DRDS 5.3 使用了 AliJDK 的 Wisp 協程。在業務邏輯相同的狀況下，使用協程模型與使用線程模型相比，系統容量提高了 30% 左右。後端

更快的 Parser：FastSQL

DRDS 5.3 中的 Parser 部分，換成了從 Druid（https://github.com/alibaba/druid）剝離出來的 FastSQL。相對於老的 Parser，FastSQL 在 SQL 解析方面，比 antlr、javacc 等自動生成的 Parser 快了數十倍至數百倍，相對 DRDS 老版本的 Parser 帶來了一倍的性能提高。FastSQL 近期會開源。

2. 原生分佈式事務

DRDS 5.3 提供原生的分佈式事務功能，有如下特色：

提供柔性事務與 XA 事務兩種事務方案供用戶在不一樣的場景下進行選擇。
不依賴任何第三方組件，能力集成在 DRDS Server 中，專有云無需額外資源進行部署。
無熱點狀況下性能線性可擴，無單點瓶頸。
無需額外開通，公有云上購買的實例便可當即使用，不產生額外費用。

DRDS 5.3 提供柔性事務和 XA 事務兩種方案，通常狀況下，當 DRDS 後端的 MySQL 爲 5.7 及以上版本時，推薦使用 XA 事務。

柔性事務

DRDS 5.3 提供的最終一致方式執行的分佈式事務稱爲柔性事務（Flexible Transactions）。

柔性事務放棄了隔離性，減少了事務中鎖的粒度，使得應用可以更好的利用數據庫的併發性能，實現吞吐量的線性擴展。異步執行方式能夠更好的適應分佈式環境，在網絡抖動、節點故障的狀況下可以儘可能保障服務的可用性（Availability）。

DRDS 5.3 中開啓柔性事務只須要一行代碼：

SET drds_transaction_policy = 'flexible';

SHOW VARIABLES LIKE 'drds_transaction_policy'; 
+-------------------------+----------+
| VARIABLE_NAME           | VALUE    |
+-------------------------+----------+
| drds_transaction_policy | FLEXIBLE |
+-------------------------+----------+
1 row in set (0.07 sec)

除此以外，DRDS 柔性事務的使用方法和普通事務徹底相同：應用首先用 SET autocommit = 0 和SET drds_transaction_policy = 'flexible' 開啓柔性事務；而後在同一個會話中執行事務的 SQL 語句 —— 最後當應用發起 commit 或 rollback 後，DRDS 將保證這些 SQL 語句執行的原子性：所有成功，或者所有失敗。

XA 事務

DRDS 5.3 也支持 XA 事務，在柔性事務的基礎上提供了強一致能力。因爲 MySQL XA 實現機制的限制，咱們要求只有在 DRDS 後端是 MySQL 5.7 版本以上才啓用 XA 事務功能。

SET drds_transaction_policy = 'XA';

SHOW VARIABLES LIKE 'drds_transaction_policy'; 
+-------------------------+-------+
| VARIABLE_NAME           | VALUE |
+-------------------------+-------+
| drds_transaction_policy | XA    |
+-------------------------+-------+
1 row in set (0.07 sec)

DRDS XA 事務使用兩階段提交協議（XA Protocol）保護子事務的提交與回滾，消除了柔性事務的異步回滾問題。因爲 XA Protocol 在提交與回滾階段始終加鎖，避免了事務結束前的髒讀和覆蓋，可是對性能有較大影響。

3. Outline

DRDS 5.3 提供 Outline 機制，容許用戶在不修改程序與 SQL 的狀況下，對特定類型的 SQL 的行爲進行定製。簡單說，Outline 能夠將一個類型的源 SQL 在執行時動態的替換成另外一個目標 SQL，目標 SQL 中能夠帶一些 HINT。

一些典型的應用場景：

使用 SLAVE HINT 將特定的SQL路由到只讀實例執行：

CREATE OUTLINE O1 ON SELECT * FROM T1 WHERE ID=? TO SELECT /*+TDDL:SLAVE()*/ * FROM T1 WHERE ID=?

使用 MySQL 原生的 FORCE INDEX 爲特定的 SQL 指定須要選擇的索引：

CREATE OUTLINE O2 ON SELECT * FROM T1 WHERE ID=? TO SELECT * FROM T1 FORCE INDEX(index_xxx) WHERE ID=?

使用 DRDS 的 HINT 將特定的 SQL 路由到指定分片上執行：

CREATE OUTLINE O3 ON SELECT * FROM T1 WHERE ID=? TO SELECT /*+TDDL:node('0')*/ * FROM T1 WHERE ID=?

DRDS 中的 Outline，能夠對參數化的 SQL 進行匹配，也能夠對特定參數的 SQL 進行匹配。例如，對於 SQL：

SELECT * FROM T1 WHERE ID=?

當 ID 取 1 時，需求到只讀實例執行；當 ID 取其餘值時，需求到主實例執行，則能夠建立如下兩個 Outline：

CREATE OUTLINE O1 ON SELECT * FROM T1 WHERE ID=1 TO SELECT /*+TDDL:SLAVE()*/ * FROM T1 WHERE ID=1;
CREATE OUTLINE O2 ON SELECT * FROM T1 WHERE ID=? TO SELECT /*+TDDL:MASTER()*/ * FROM T1 WHERE ID=?;

DRDS 會優先匹配帶具體參數的 Outline。

DRDS Outline 的詳細說明：https://help.aliyun.com/document_detail/71254.html
DRDS Hint 說明：https://help.aliyun.com/document_detail/71287.html

4. SQL 支持

SQL 兼容性方面，DRDS 5.3 最大的特色在於明確了 SQL 的邊界，也即可以明確的說明哪些 SQL 支持、哪些 SQL 不支持。

DRDS 5.3 SQL 邊界文檔：https://help.aliyun.com/document_detail/71252.html。

一些重要的 SQL 類型：

子要查詢方面，支持 Correlated Subqueries（不要求關聯項必定是拆分鍵）、Derived Tables，暫不支持列子查詢。更多子查詢的支持範圍參考：https://help.aliyun.com/document_detail/71295.html。
支持分佈式 JOIN（不要求必定要帶拆分鍵，不要求必須是拆分鍵上的 JOIN），暫不支持 STRAIGHT_JOIN 和 NATURAL JOIN。
支持大部分 MySQL 函數，主要暫不支持的爲：全文檢索函數、XML 函數、空間分析函數與 JSON 函數。
UPDATE/DELETE 語句僅支持單表操做，不支持 UPDATE/DELETE 中包含 JOIN 以及子查詢。
聚合函數支持 COUNT/SUM/MAX/MIN/AVG，GROUP BY 不要求FULL_GROUP_BY（https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_only_full_group_by）。
支持邏輯 SQL 的 KILL 與 SHOW PROCESSLIST：https://help.aliyun.com/document_detail/71372.html。
支持 CREATE USER 建立更多用戶，並使用 GRANT 語句對用戶權限進行受權：https://help.aliyun.com/document_detail/71356.html。
支持 PREPARE 協議、多語句與壓縮協議。

5. Optimizer 與執行計劃

DRDS 5.3 中，提供了很是豐富的分佈式 SQL 優化策略，一些重要的例如：

對 Filter 的上拉、下壓、推導等優化，確保 DRDS 能夠準確的識別出 SQL 中能夠下推的部分，這個能很大程度上提高 JOIN、子查詢的性能，避免應該能下推卻沒法下推帶來的性能損耗。
子查詢的 SEMI-JOIN 優化。DRDS中，子查詢會被改寫爲 SEMI-JOIN 進行優化，從而使其可以複用大量針對的 JOIN 的優化策略，提高性能和功能穩定性。
提供了一系列 Hint，容許調整執行計劃的任意一個節點，結合 Outline 機制，達到不更改 SQL 也能對 SQL 進行性能優化的目的。
針對不一樣的場景，對排序與 Limit 進行優化，確保能將排序與 Limit 儘量多的下推到存儲節點上，保證傳輸的數據量最小。

DRDS 5.3 設計了全新的執行計劃顯示格式，相對老版本，具備如下特徵：

收縮了分片的顯示，執行計劃不會由於涉及多個分片而臃腫龐大。
執行計劃中包含了完整的執行策略，不存在二義性。
執行計劃使用了標準的算子的語義，易於將標準的數據庫知識應用到 DRDS 的查詢優化中。
執行計劃中將同時包含分佈式執行計劃以及存儲分片上的執行計劃（此特性 6 月份上線）。
提供 Optimizer Tracing 功能，能一步一步的展現出執行計劃的優化過程，方便進行 SQL 調優。
經過執行計劃能夠清晰的判斷出：
- SQL 須要在哪些分片上執行，是否跨分片
- JOIN、子查詢、聚合、排序等操做是否可以下推
- JOIN、排序等所使用的算法是什麼

例如，針對如下 SQL 的執行計劃：

mysql> explain SELECT count(*), name FROM drds GROUP BY name ORDER BY count(*);
+-----------------------------------------------------------------------------------------------------------------------------------------------------------+
| LOGICAL PLAN                                                                                                                                              |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------+
| Project(count(*)="count(*)", name="name")                                                                                                                 |
|   MemSort(sort="count(*) ASC")                                                                                                                            |
|     Aggregate(group="name", count(*)="SUM(count(*))")                                                                                                     |
|       MergeSort(sort="name ASC")                                                                                                                          |
|         LogicalView(tables="[00-03].drds", shardCount=4, sql="SELECT `name`, COUNT(*) AS `count(*)` FROM `drds` GROUP BY `name` ORDER BY `name`")         |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------+
5 rows in set (0.13 sec)

今後執行計劃中，咱們能夠得到如下信息：

須要在 00-03 供 4 個分片上執行物理 SQL （LogicalView 算子）：SELECT name, COUNT(*) AS count(*) FROM drds GROUP BY name ORDER BY name。
Group By 操做基於排序實現，須要對 name 進行排序。因爲每一個分片上已經完成了 Order By 操做，所以分佈式層須要對各個分片的數據作歸併排序（MergeSort 算子）。
每一個分組內，對 COUNT(*) 的結果作 SUM 操做，以彙總每一個分片 COUNT(*) 的結果（Aggregate 算子）。
使用內存排序，對 Aggregate 節點輸出的 count(*) 進行排序（MemSort 算子）。
最終結果集輸出的是 count(*) 與 name 兩列（Project 算子）。

更多關於 DRDS 5.3 執行計劃的介紹，請關注後續的文章。

What's NEXT

6 月底，DRDS 將發佈 5.3.2，將會提供如下特性：

帶計算能力的 DRDS 只讀實例。能夠直接在RDS主實例或者只讀實例上，進行最高可提供 READ COMMITTED 級別的複雜 SQL（例如千萬級的表的 JOIN 等）執行能力，而且隨規格的提高，響應時間能進行近線性的擴展。
回收站，可對 DROP TABLE 操做進行閃回，方便在誤刪表的場景下快速對數據進行恢復。
基於事務的廣播表寫入。廣播表將再也不依賴任何第三方組件，可自行建立使用。
跨實例、機房、單元依然能保證全局惟一的主鍵服務。

歡迎你們持續關注 DRDS（阿里雲分佈式關係型數據庫服務），詳情：https://www.aliyun.com/product/drds。

相關標籤/搜索