1. 概覽
在過去的3個月中，我們發布上線了冷熱數據分離存儲等功能。今天很高興和大家交流PolarDB-X最新的內核版本5.4.15。在最新版本中，提供諸多新的功能：存儲過程，讀寫分離優化，表級分區管理，密碼、審計優化等。
除此之外，在這一版本中相較于前序版本也有了長足的進步，修復了 15個 Issues，并融入了26個增強特性。我們會不斷地將新版本的功能，開放同步到開源社區。
另外，我們將在近期推出PolarDB-X標準版，滿足小規模部署要求，降低分布式數據庫的使用門檻，未來更加順滑的過度到分布式數據庫，歡迎大家到公共云進行使用。
2. MySQL生態
PolarDB-X堅持MySQL生態，在內核新版本中支持存儲過程功能。
2.1 存儲過程
在實現某些需求時，需要編寫一組復雜的SQL語句才能實現的時候，很多資深數據庫用戶習慣使用存儲過程。很顯然存儲過程能帶來如下好處：
- 復用性高。存儲過程可以重復使用，從而減少數據庫開發人員的工作量，同時降低業務出錯概率。
- 效率高。存儲過程編譯一次后，就會存到數據庫，每次調用時都直接執行。
- 降低網絡流量。存儲過程編譯好會放在數據庫，我們在遠程調用時，不會傳輸大量的字符串類型的SQL語句。
- 安全性高。完成某個特定功能的存儲過程一般只有特定的用戶可以使用，具有使用身份限制，更安全。
當然存儲過程也存在一些缺點：
- 可移植性差。
- 如果使用大量的存儲過程，使用這些存儲過程的每個連接的內存使用量將大大增加。
在PolarDB-X中我們對內存進行了嚴格管理。
原理簡介
存儲過程會被持久化到Meta center中，按需加載到計算節點中執行，SQL相關的執行邏輯會發送到SQL engine中執行，然后獲取執行結果，存儲過程的控制流程等相關的邏輯會在PL engine中執行。
存儲過程在真正執行前會注冊到運行時存儲過程管理中心，同時整個執行過程中存儲過程所占用的內存大小會被嚴格限制。
存儲過程內存管理
存儲過程執行過程中的內存占用主要為緩存的cursor，因此我們對單個cursor所能使用的最大內存以及整個存儲過程在執行時占用的內存進行了限制，由兩個參數控制，PL_CURSOR_MEMORY_LIMIT和PL_MEMORY_LIMIT。
其中，變量PL_CURSOR_MEMORY_LIMIT用于控制每個Cursor所占用的內存，超過該閾值時會spill到硬盤中；變量PL_MEMORY_LIMIT用于控制每個存儲過程所能使用的最大內存。
3. 易用性優化3.1 讀寫分離優化
PolarDB-X配置了多種讀寫策略，提供了透明的強一致的讀寫分離能力。其特點有：
- 無論什么狀況都不用擔心誤寫了“備副本或只讀副本”，因為它不支持寫，寫操作會被路由到主副本；
- 無論什么時候不用擔心“備副本或只讀副本”故障，因為它會自動路由給其他正常的副本或者切回主副本；
- 無論什么場景不用擔心 “備副本或只讀副本”讀不到最新的數據，因為它提供的是強一致的讀寫能力；
- 大查詢不用擔心打爆“主副本”，因為它支持將大查詢路由給”備副本或只讀副本“，避免對主副本造成壓力。
PolarDB-X會基于CTS+Log 在主副本和只讀副本間做一致性復制，基于CTS+TSO確保在只讀副本上讀到已經提交的最新數據。在一致性讀的能力上，配置了規則讀寫分離和智能讀寫分離的能力，業務可以更加透明的使用。
強一致性讀
RW節點會維護好自身MAX CTS（全局一致性日志位點），RO節點通過日志回放，也會不斷更新當前自身的CTS。路由到RO節點的強一致性讀查詢過程如下：
- 客戶端把請求發送到計算節點；
- 計算節點識別到請求會發送給RO，首先會從RW節點獲取當前最大CTS；
- 計算節點把CTS /TSO /請求一起發送給RO；
- RO節點根據接收到的CTS判斷是否等到RO節點事務狀態回放到相應位點；根據TSO判斷數據可見性，給CN返回結果。
規則讀寫分離
用戶不需自己做業務改造，去支持讀寫分離場景。PolarDB-X支持業務透明使用讀寫分離能力，用戶只需要配置讀寫分離權重，內核自己會將部分讀請求發送給主副本，部分讀請求發送給只讀副本。此外其相比于傳統的讀寫分離，還有如下優勢：
- 如果存在多個只讀副本，會把請求調度到延遲更低的只讀副本上；
- 支持只讀副本異?；蛘哐舆t過大，自動將流量切回主副本。
智能讀寫分離
PolarDB-X 提供的只讀實例具有MPP查詢加速的能力，在內核上我們提供了基于查詢代價智能識別工作負載。將AP類查詢轉發給只讀實例計算層CN，在只讀實例CN上做MPP查詢后，將結果返回給主實例CN。這類讀寫分離主要針對于混合負載場景。
3.2 表級分區精細化管理
在數據庫使用過程中，原來預想的數據分區和實際的數據分布不匹配，導致數據分布不均勻，或者需要進行遷移，那么如何進行調整呢。
分區分裂
當一個分區數據出現傾斜的時候，可以將表的一個分區分裂成多個分區。
原表定義將數據分成P1和P2
CREATE TABLE Table1(a int) PARTITION BY RANGE(a) (PARTITION p1 VALUES LESS THAN(20), PARTITION p2 VALUES LESS THAN(100))
那么我們可以通過以下SQL將P1分裂成P10,P11,P12
ALTER TABLE Table1 SPLIT PARTITION p1 INTO (PARTITION p10 VALUES LESS THAN (8), PARTITION p11 VALUES LESS THAN(15), PARTITION p12 VALUES LESS THAN(20))
分區合并
將多個分區（兩個或者兩個以上）合并成一個分區。
對于Hash/Key/Range/Range column分區，只能將相鄰的分區合并，對于List/List column分區，可以將任意分區合并在一起。
例如表tb1的定義如下：
CREATE TABLE tb1(a int) PARTITION BY RANGE(a) (PARTITION p1 VALUES LESS THAN(20), PARTITION p2 VALUES LESS THAN(40), PARTITION p3 VALUES LESS THAN(100))
可以通過以下SQL將p1和p2合并：
ALTER TABLE tb1 MERGE PARTITIONS p1,p2 to p12
需要注意的是不能將不相鄰的兩個分區，例如p1和p3合并到一起。
分區遷移
將分區遷移到指定的存儲節點
例如表tb1的定義如下：
CREATE TABLE tb1(a int) PARTITION BY RANGE(a) (PARTITION p1 VALUES LESS THAN(20), PARTITION p2 VALUES LESS THAN(40), PARTITION p3 VALUES LESS THAN(100))
可以通過以下SQL將p1，p3遷移到指定的存儲節點DN2（其中DN2是存儲節點的ID）中
ALTER TABLE tb1 MOVE PARTITIONS p1,p3 to 'DN2'3.3 密碼、審計優化
當前，對于數據庫安全性要求越來越高，尤其在等保、合規方面，通常都會對密碼復雜度、密碼是否能定期修改、或者是否配置密碼自動過期策略有嚴格要求。避免出現過于簡單的密碼或相同密碼長期未修改被暴力破解，降低數據庫的安全風險。
在新版本中新增支持了以下安全審計功能：
1、基于正則表達式規則來配置密碼復雜度；(?=.*[0-9])(?=.*[A-Z])(?=.*[a-z]).{8,20}配置了密碼必須包含大小寫字母和數字，且長度在8~20個字符之間；
如果您采用了11位組合字符密碼，那在現有技術條件下，需要400年才能破解。
2、為不同賬戶配置不同的密碼自動過期策略。當系統時間到達指定日期時間（可精確到秒），對應賬戶將無法登錄數據庫。
注意，在開啟密碼自動過期策略后，用戶需要定期檢查密碼是否即將過期，并及時進行修改，避免影響業務。
4. 展望
越來越多的業務需要彈性，靈活而有效的應對突發情況。如何快速適應業務形態的變化，對云原生分布式數據庫提出了更高的要求。我們在細細打磨產品的深度上下功夫的同時，對于這種廣度的延伸一致保持著敏銳的洞察。非常期待和大家一起，將分布式數據庫對業務的覆蓋廣度更加延伸，我們將在近期推出PolarDB-X 標準版，滿足分布式數據庫小規模部署要求，敬請期待。
