作者：阿裡雲資料庫 胡慶達，張海平，季育軒
在過去的幾年裡，我們觀察到，當資料達到一定規模後，PolarDB for MySQL（後文簡稱PolarDB）的部分使用者（包括集團内部使用者和公有雲上的外部客戶）更願意使用gh-ost/pt-osc這樣的外部工具來進行DDL操作。PolarDB核心團隊為使用者case by case地解決了很多DDL使用帶來的問題，在處理這些問題的同時，我們也在不斷地思考和讨論，雲上客戶越來越多，中小客戶群體不斷擴大，我們究竟要如何在核心層面解決DDL日益凸顯的繁重弊端，讓客戶少為DDL擔憂。
DDL面臨的問題
DDL在生産環境下面臨的問題主要來自兩個方面：一個是MDL導緻的阻塞問題，一個是全量資料複制帶來的資源使用問題。
為了保證DD的一緻性，MDL被引入來同步DDL，DML和DQL，這使得同一個表上的各種操縱必須在MDL這一粗粒度鎖上彙聚，由此引發了各種逾時問題，嚴重影響了上層業務。此外，在PolarDB共享存儲結構下，多節點間的DD一緻性要求使得這一問題拓展到了讀寫節點之間，也為使用者帶來了諸多困擾。
在PolarDB内部，資料實體存儲和資料定義是分離的，是以DDL操作常常需要進行全量資料的重建，由此導緻了單次DDL操作耗時甚至可以達到天級。這種操作的潛藏風險讓使用者不得不焦躁地在客戶群裡反複和研發同學溝通确認。同時，全量資料的重建會占用大量的系統資源。PolarDB的雲原生優勢已經在相當程度上為客戶規避了這一問題，資源的快速彈性伸縮防止了OOM，磁盤空間不足等問題，但是系統資源的大量占用将提高其他操作的耗時，降低資料庫的整體吞吐，最終将影響上層業務的穩定性。
此外，在全面上雲的大背景下，雲上中小客戶群體不斷擴大，他們中很多還缺乏處理資料庫複雜生産環境下的各種細節問題的經驗。在我們的觀察裡，這些客戶的DDL操作頻率顯著高于集團内部使用者和其他大客戶，DDL使用過程中的很多問題讓這些使用者焦頭爛額。
優化和演進方向
解決DDL帶來的問題，本質上我們需要做到的隻有一點：降低DDL執行耗時。如果DDL可以在瞬間完成，那麼DDL帶來的諸多問題都将迎刃而解。于是在這樣一種思路的指導下，我們提出了Instant DDL + Parallel DDL + 實體複制鍊路優化的整體解決方案。
對于可通過變更資料定義完成的DDL類型，如加列，減列等，我們将其Instant化，使其無需修改存量資料，因而可在瞬間完成；對于必須全量掃描并建構資料的DDL類型，如重建主鍵索引，建立二級索引等，我們允許其在引擎内部被并行地處理，進而充分利用系統資源，降低執行耗時。
此外，我們還使用了并行MDL同步方案，解決DDL過程MDL在讀寫節點上的阻塞問題，同時優化了實體複制使用的Redo Log,降低了DDL操作時讀節點同步Redo Log的負載。這些實體複制鍊路上的優化和DDL執行鍊路上的整體演進共同作用，構成了攻克DDL難關的主力軍和護衛隊。
Instant DDL
像add column這類DDL，原有的執行邏輯包含兩個部分的操作，分别涉及資料字典和存量資料。其中資料字典的修改是非常快速的，但是表全量資料的重建則耗時漫長。
Instant DDL則僅改變資料字典中的表定義資訊，而不修改任何存量資料，進而使得DDL操作可以在瞬間完成。
目前add column at last instantly已經在PolarDB 5.7和8.0上得到支援， add column at any position instantly和drop column instantly等也将在随後的版本中上線，未來所有邏輯上可Instant 化的DDL操作都将支援Instant算法。使用者隻需熱更新到相應的版本，即可讓原本耗時達到小時級甚至天級的DDL操作在瞬間完成。
Parallel DDL
建立二級索引這類DDL操作，執行時必須掃描全量資料，并建構新的索引樹，整體耗時非常長。
Parallel DDL則将Data Scan和B+ Tree Build操作劃分成多個子任務，通過内部的并行服務子系統進行排程并适時地執行，最後将各個子任務的執行結果進行合并得到最終結果。
Parallel DDL 通過存儲引擎内部的并行執行，充分利用系統資源，使得部分DDL的執行效率最高可提高十倍以上，進而将整個DDL的時間視窗縮小到原來的十分之一。目前parallelly create secondary index 已經在PolarDB 8.0上得到支援，後續将陸續上線到其他版本，同時其他類型的Parallel DDL支援也将在随後的版本中釋出。
實體複制鍊路上的DDL優化
Instant DDL 和Parallel DDL 是DDL執行鍊路上的演進方案。但是在PolarDB共享存儲架構下，複制鍊路上的問題同樣制約着DDL的能力。例如為了保證各節點的一緻性，必須在讀寫節點間通過Redo Log同步MDL資訊，然而MDL鎖的阻塞将影響Redo Log的同步，為此我們采用了并行MDL同步方案，将MDL資訊的同步和Redo Log的同步解偶，提高了整個叢集在DDL時的吞吐能力。此外我們改進了DDL過程中的Redo Log同步路徑，不僅優化了寫節點在産生DDL Redo Log時的IO開銷，同時讓隻讀節點有選擇的同步Redo Log，降低DDL 操作時隻讀節點的負載，進而降低DDL過程中的讀寫節點間的同步代價。這些實體複制鍊路上的優化為DDL執行鍊路上的優化效果保駕護航，兩者協同使得整個叢集處理DDL的能力顯著增強。
小結
DDL是PolarDB所有操作中最繁重的一種，曾經為使用者帶去了一些不太好的使用體驗。而Instant DDL + Parallel DDL + 實體複制鍊路優化是切實解決DDL 繁重弊端的重要組合拳。相信經過未來若幹版本的疊代和演進，PolarDB DDL将為客戶帶來體驗上翻天覆地的變化。期待未來使用者執行DDL操作像執行簡單查詢一樣淡定坦然，PolarDB核心團隊将始終如一地為使用者打造最佳的雲原生關系型資料庫管理系統。