X-Engine是阿里巴巴自研的存儲引擎，作為阿里云 RDS MySQL 的一個可選引擎，除了主打高性能和低成本，還增加了不少惠及用戶的新功能。本文將詳細(xì)介紹 MySQL(X-Engine) 如何近乎瞬時完成傳統(tǒng)數(shù)據(jù)庫需要數(shù)小時完成的DDL操作。
1.數(shù)據(jù)庫DDL操作面臨的問題
互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展迅速，應(yīng)用模式頻繁更改是常態(tài)。相應(yīng)地，數(shù)據(jù)庫訪問模式和schema也隨之變化。DDL（Data Definition Language）是SQL的一類，主要作用是創(chuàng)建和更改數(shù)據(jù)的schema信息，最常見的操作包括：加減列、更改列類型、加減索引等。熟悉MySQL的同學(xué)都知道，在8.0以前，雖然Online DDL不阻塞其它DML（Insert/Update/Delete）操作，但許多重要的DDL操作，如加列、減列等，仍舊需要等待數(shù)小時、甚至好幾天時間（依據(jù)數(shù)據(jù)量的大小）才會生效。更改列類型等操作甚至仍需要鎖表執(zhí)行，阻塞DML操作。
DDL操作運行時間長，占用系統(tǒng)資源，需要額外的磁盤空間（建立臨時表），影響系統(tǒng)吞吐，并且一旦DDL過程中實例crash，恢復(fù)時間也會很久。以加列DDL為例，MySQL經(jīng)歷如下過程：
1.以新schema建立空表。
2.拷貝數(shù)據(jù)到新表，并且將新加列的值賦為默認(rèn)值，同時更新索引表。數(shù)據(jù)庫接受到的DML操作被記錄在臨時文件。
3.加exclusive lock，阻塞寫操作，將臨時文件記錄的DML操作Apply到新表。如果DML很多，這一階段將花費較多時間。
4.刪除舊表，將新表命名為舊表的名字。
顯然，這個過程加鎖時間長，拷貝數(shù)據(jù)操作會占用系統(tǒng)資源和臨時空間，并需要大量I/O。為了適應(yīng)變化頻繁的業(yè)務(wù)，不立即更改存儲層數(shù)據(jù)、可以快速完成的DDL（我們稱之為Fast DDL）成為了一個必要feature。MySQL 8.0 增加了instant add column功能，可以在短時間內(nèi)只修改table元信息，完成加列操作。遺憾的是，它還不支持其它類型的DDL。得益于阿里自研的存儲引擎X-Engine存儲了多版本Table Schema，每一行記錄在引擎層就完成了解析，并且可以依據(jù)更新版本的schema實現(xiàn)格式轉(zhuǎn)換，X-Engine因此可支持多種類型的Fast DDL。
2.業(yè)界Fast ddl實現(xiàn)方案
MySQL 8.0
record記錄了列個數(shù), instant add column操作只修改系統(tǒng)表。
寫操作：新格式的記錄。
讀操作：根據(jù)存儲在系統(tǒng)表中default value補齊新加列。
支持類型：
• Change index optionRename table• Set/drop default• Modify column when the table is empty• Add/drop virtual columnsAdd columns
MariaDB10.3
整體實現(xiàn)方案與MySQL8.0類似，record記錄了列個數(shù)，在leftmost leaf page中記錄所有列的default值.支持類型：
• Add column• Drop column• Extend VARCHAR maximum （Only if the physical format allows; not VARCHAR(255) to VARCHAR(256)）
Aurora
發(fā)生ddl后，更新系統(tǒng)表，新、舊版本的schema均要記錄下來。然后廣播該修改。之后接受DML請求，首先轉(zhuǎn)換相關(guān)leaf page的所有記錄，然后執(zhí)行DML。
select請求會將舊版本的記錄拼接成新版本記錄。
支持類型
• only supports adding nullable columns, without default values
3.X-Engine多版本schema
顧名思義，F(xiàn)ast DDL指數(shù)據(jù)庫能夠在極短的時間內(nèi)完成用戶發(fā)出的DDL指令并返回。之所以這么快，是因為只修系統(tǒng)表里的元數(shù)據(jù)，不變更引擎層存儲的數(shù)據(jù)。其實現(xiàn)的關(guān)鍵在于：元信息變更之后，內(nèi)存、磁盤中的物理記錄該如何解析。
Engine的架構(gòu)采用了LSM-Tree的思想，將新寫入的數(shù)據(jù)以追加方式寫入內(nèi)存memtable，memtable到一定大小后switch為immutable memtable，不再修改。然后逐漸以固定大小extent的形式，flush到持久化存儲中。當(dāng)extent到一定數(shù)量后，通過合并(Compaction)操作，將相同Key的多個版本合并。為了讓每行記錄可解析，最直觀簡單的方案便是將元信息附著在記錄上面。為了能夠不依賴系統(tǒng)表解析記錄，X-Engine存儲了較為詳細(xì)的元數(shù)據(jù)，如果為每一行都附著一份，會占用大量的空間。為了大大減少存儲成本，我們保證每個memtable和extent內(nèi)部的數(shù)據(jù)schema一致，并將schema信息存儲在memtable和extent之上。
schema信息包含了諸如列個數(shù)、列類型、列長度、默認(rèn)值等關(guān)鍵信息。利用這些信息，X-Engine可以在返回結(jié)果之前，完成列解析，并只需返回查詢目標(biāo)列的對應(yīng)結(jié)果。下面給出了一個具體的例子，同一張表存在不同schema版本的extent時，如何返回結(jié)果。
4.X-Engine fast ddl實現(xiàn)
當(dāng) MySQL 接收到一條fast ddl語句時，更新相關(guān)系統(tǒng)表及元數(shù)據(jù)，新版本的表結(jié)構(gòu)隨之生效，這時這條DDL語句就執(zhí)行成功啦！到現(xiàn)在為止X-Engine存儲的信息沒有發(fā)生任何變化。
讀請求
當(dāng)系統(tǒng)接收到Select請求時，MySQL 會將請求本身，連同當(dāng)前最新版本schema信息（稱之為target schema）傳遞到X-Engine。X-Engine首先定位到記錄的位置（某個memtable或extent），并取相應(yīng)數(shù)據(jù)schema解析記錄得到初步結(jié)果。接著，對比數(shù)據(jù)schema和target schema，對初步結(jié)果做適當(dāng)填充、刪減或修改得到最終結(jié)果返回。
X-Engine schema更新
Fast DDL命令執(zhí)行成功，新版本的schema生效，X-Engine還對此無感知。當(dāng)接收到第一條針對該表的DML（Insert/Update/ Delete）請后，如果發(fā)現(xiàn)X-Engine的活躍memtable的schema版本落后于最新版本，會觸發(fā)switch memtable行為：凍結(jié)當(dāng)前活躍memtable，產(chǎn)生新活躍memtable，將新schema賦予新活躍memtable。為了保證數(shù)據(jù)的正確性，該操作會等待所有正在進行的寫事務(wù)完成后再執(zhí)行。
寫請求
每個寫事務(wù)可能涉及到n（n>=1）個表。事務(wù)在提交時，需要在寫入活躍memtable之前判斷：事務(wù)寫入數(shù)據(jù)的schema版本是否與活躍memtable的schema版本一致，如果不一致則應(yīng)該報錯退出，提醒用戶重試。
Flush/Compaction
內(nèi)存中memtable數(shù)量到一定個數(shù)時會觸發(fā)Flush操作，被選中memtable的數(shù)據(jù)以extent的形式寫入磁盤，schema也隨之由memtable傳遞到extent。Compaction操作會合并多個extent，如果參與同一任務(wù)的extent schema版本不一致，X-Engine會以其中最新版本為準(zhǔn)，生成新extent。
總結(jié)
Fast DDL可以解決很多應(yīng)用的痛點，加列、擴展列的常用的操作不用再需要漫長的等待。技術(shù)上，X-Engine通過存儲詳細(xì)的多版本schema信息，不僅無需借助系統(tǒng)表解析記錄，而且可以輕易地實現(xiàn)不同版本schema之間的數(shù)據(jù)轉(zhuǎn)換，進而可以支持豐富的Fast DDL類型。
