資料庫DDL操作面臨的問題
網際網路業務發展迅速，應用模式頻繁更改是常态。相應地，資料庫通路模式和schema也随之變化。DDL（Data Definition Language）是SQL的一類，主要作用是建立和更改資料的schema資訊，最常見的操作包括：加減列、更改列類型、加減索引等。熟悉MySQL的同學都知道，在8.0以前，雖然Online DDL不阻塞其它DML（Insert/Update/Delete）操作，但許多重要的DDL操作，如加列、減列等，仍舊需要等待數小時（依據資料量的大小）才會生效。更改列類型等操作甚至仍需要鎖表執行，阻塞DML操作。
DDL操作運作時間長，占用系統資源，需要額外的磁盤空間（建立臨時表），影響系統吞吐，并且一旦DDL過程中執行個體crash，恢複時間也會很久。以加列DDL為例，MySQL經曆如下過程：
1.以新schema建立空表。
2.拷貝資料到新表，并且将新加列的值賦為預設值，同時更新索引表。資料庫接受到的DML操作被記錄在臨時檔案。
3.加exclusive lock，阻塞寫操作，将臨時檔案記錄的DML操作apply到新表。如果DML很多，這一階段将花費較多時間。
4.删除舊表，将新表命名為舊表的名字。
顯然，這個過程加鎖時間長，拷貝資料操作會占用系統資源和臨時空間，并需要大量I/O。為了适應變化頻繁的業務，不立即更改存儲層資料、可以快速完成的DDL（我們稱之為Fast DDL）成為了一個必要feature。今年釋出的MySQL 8.0，增加了instant add column功能，可以在短時間内隻修改table元資訊，完成加列操作。遺憾的是，它還不支援其它類型的DDL。得益于阿裡自研的存儲引擎X-Engine存儲了多版本Table Schema，每一行記錄在引擎層就完成了解析，并且可以依據更新版本schema實作格式轉換，X-DB是以支援多種類型的Fast DDL。
業界Fast ddl實作方案
MySQL 8.0
MariaDB10.3
整體實作方案與MySQL8.0類似，record記錄了列個數，在leftmost leaf page中記錄所有列的default值.
支援類型：
Add column
Drop column
Extend VARCHAR maximum （Only if the physical format allows; not VARCHAR(255) to VARCHAR(256)）
Aurora
發生ddl後，更新系統表，新、舊版本的schema均要記錄下來。然後廣播該修改。之後接受DML請求，首先轉換相關leaf page的所有記錄，然後執行DML。
select請求會将舊版本的記錄拼接成新版本記錄
支援類型
only supports adding nullable columns, without default values
X-Engine多版本schema
顧名思義，Fast DDL指資料庫能夠在極短的時間内完成使用者發出的DDL指令并傳回。之是以這麼快，是因為隻修系統表裡的中繼資料，不變更引擎層存儲的資料。其實作的關鍵在于：元資訊變更之後，記憶體、磁盤中的實體記錄該如何解析。
X-DB基于新一代存儲引擎X-Engine，它的架構采用了LSM-Tree的思想，将新寫入的資料以追加方式寫入記憶體memtable，memtable到一定大小後switch為immutable memtable，不再修改。然後逐漸以extent的形式，flush到持久化存儲中。當extent到一定數量後，通過合并(Compaction)操作，将相同Key的多個版本合并。為了讓每行記錄可解析，最直覺簡單的方案便是将元資訊附着在記錄上面。為了能夠不依賴系統表解析記錄，X-Engine存儲了較為詳細的中繼資料，如果為每一行都附着一份，會占用大量的空間。為了減少存儲成本，我們保證每個memtable和extent内部的資料schema一緻，并将schema資訊存儲在memtable和extent之上。
X-DB fast ddl實作
X-DB是一個分布式關系型資料庫，所有元資訊都由名為GMS（Global Management Service）的子產品管理。當X-DB接收到一條fast ddl語句時，GMS更新相關中繼資料表資訊（分布式DDL的執行流程的詳細過程，會在另一篇文章介紹，不是本文重點），新版本的表結構随之生效，這時這條DDL語句就執行成功啦！到現在為止X-Engine存儲的資訊沒有發生任何變化。
讀請求
當系統接收到Select請求時，X-DB Server會将請求本身，連同目前最新版本schema資訊（稱之為target schema）傳遞到X-Engine。X-Engine首先定位到記錄的位置（某個memtable或extent），并取相應資料schema解析記錄得到初步結果。接着，對比資料schema和target schema，對初步結果做适當填充、删減或修改得到最終結果傳回。
X-Engine schema更新
Fast DDL指令執行成功，新版本的schema生效，X-Engine還對此無感覺。當X-DB接收到第一條針對該表的DML（Insert/Update/ Delete）請後，如果發現X-Engine的活躍memtable的schema版本落後于最新版本，會觸發switch memtable行為：當機目前活躍memtable，産生新活躍memtable，将新schema賦予新活躍memtable。為了保證資料的正确性，該操作會等待所有正在進行的寫事務完成後再執行。
寫請求
每個寫事務可能涉及到n（n>=1）個表。事務在送出時，需要在寫入活躍memtable之前判斷：事務寫入資料的schema版本是否與活躍memtable的schema版本一緻，如果不一緻則應該報錯退出，提醒使用者重試。
Flush/Compaction
記憶體中memtable數量到一定個數時會觸發Flush操作，被選中memtable的資料以extent的形式寫入磁盤，schema也随之由memtable傳遞到extent。Compaction操作會合并多個extent，如果參與同一任務的extent schema版本不一緻，X-Engine會以其中最新版本為準，生成新extent。
X-DB支援的Fast DDL類型
目前X-DB支援的Fast DDL類型包括：
Renaming a table
Renaming an index
Renaming a column
Adding a column
Dropping a column
Reordering columns
Setting a column default value
Dropping the column default value
Changing the column data type, including:
- TINYINT->SMALLINT->MEDIUMINT->INT->BIGINT
- TINYTEXT->TEXT->LONGTEXT
- TINYBLOB->BLOB->LONGBLOB
- VARCHAR<->TEXT , not supported if column size decreased
- VARBINARY<->BLOB, not supported if column size decreased
Extending CHAR/BINARY column size
Extending VARCHAR/VARBINARY column size
Adding a virtual column
Modifying virtual column order
Dropping a virtual column
總結
X-DB Fast DDL可以解決很多應用的痛點，加列、擴充列的常用的操作不用再需要漫長的等待。技術上，X-Engine通過存儲詳細的多版本schema資訊，不僅無需借助系統表解析記錄，而且可以輕易地實作不同版本schema之間的資料轉換，進而可以支援類型豐富的Fast DDL。