背景
國內某家兼具投資理財、文化旅遊、票務爲一體的大型綜合型集團公司，2015年成立至今，由於業務高速發展，業務數據增長非常快，數據庫系統屢次不堪重負。該公司數據庫運維總監介紹，他們目前業務壓力比較大的是票務和訂單系統，他們的平臺每天新增幾千萬的訂單數據，訂單的數據來自於各個終端，近幾年每個月以300G的數據規模在高速增長，由於數據不斷增加，數據庫系統迄今爲止迭代過了3次。
第一階段：自建單機MySQL，開始單機MySQL還能滿足業務的增長，所有的票務數據都可以放在MySQL數據庫裏頭，但是數據越來越多的時候，我們發現有些單表的數據早已超過2000w，熟悉MySQL的朋友應該知道，表數據超過2000w後，性能變差。數據庫變慢，開始我們的業務方還能接受，到後來越來越慢，最終我們只能刪數據，刪數據後，必須做Optimize Table纔會釋放空間，每次操作都非常緊張。但後來公司的業務做了升級，要求保留過往所有的票務數據和訂單數據，就意味着不能刪除老數據了。所以我們在18年年底做了一次數據庫系統升級。
第二階段：利用開源中間件+MySQL我們自建了一套分庫分表的數據庫，極大緩解了我們業務增長帶來的壓力。這套系統在我們線上運行還不錯，唯一不足點就是這套數據庫系統庫沒有一套完整的binlog日誌，無法直接利用同步工具將數據同步給數倉系統。只能挨個將底下的MySQL做單獨的數據同步，到數倉系統。
這套同步鏈路比較大的問題就是無法保證分佈式事務的完整性，同時在同步過程中還不能做DDL操作。我們公司的業務其實也一直在調整，偶爾需要對錶結構做變更的話，業務需要停服，我們挨個對底下的MySQL做表結構的變更，很麻煩。我們在18年-20年業務增長確實很快，到22年底我們的數據已經到達了20幾個T了，這樣每次做結構變更，業務的停服時間也越來越久了。期間我們還做了兩次數據庫的擴容，使用過分庫分表中間件自建MySQL集羣的人都知道，這個擴容相當於再自建一套更大規模的MySQL集羣，然後將數據遷移過去，非常麻煩。所以到22年年底，我們就不得不考慮遷移到分佈式數據庫。
第三階段：我們當時覺得自建MySQL集羣的維護成本已經很高了，當時公司政策也是上雲。所以在22年年底我們開始調研業界的分佈式數據庫，最終我們選型了PolarDB分佈式數據庫，這套系統經歷了多次雙11大促，是一套高性能雲原生分佈式數據庫產品。但是我們當時對比了其他雲產品，讓我們下定決心遷移的主要是看中了以下三點：
1.透明分佈式特性：從連接、開發到管理行爲均最大限度保留單機MySQL的使用體驗，讓用戶的分佈式改造週期大幅縮短，研發運維團隊的原有技術棧最大限度保留。同時也支持Online DDL和在線擴容，在做數據庫變更的時候，困擾我們幾年的停服也得以解決。
2.全局Binlog能力: PolarDB-X是兼容MySQL生態的分佈式數據庫。通過實例內PolarDB-X的CDC組件，能夠提供與MySQL binlog格式兼容的變更日誌，並且對外隱藏了實例擴縮容、分佈式事務、全局索引等分佈式特性，讓您獲得與單機MySQL數據庫一致的使用體驗。這個能力大大降低我們同步的運維成本，兼容MySQL Binlog的協議，讓我們無縫對接開源同步工具。
3.冷數據歸檔能力: PolarDB-X基於OSS存儲服務，推出冷熱數據分離存儲這一新功能。在這一功能的基礎上，可以便捷地將冷數據從源表中剝離出來，歸檔至更低成本的OSS中，形成一張歸檔表；歸檔表支持高效的主鍵與索引點查、複雜分析型查詢，滿足高可用、MySQL兼容性和任意時間點閃回等特性。您可以像訪問MySQL表一樣來訪問歸檔表，也可以用開源大數據產品接入OSS的歸檔數據。
4.這個特性其實很適用我們這種票務和訂單系統的業務，這類業務天然按照時間日期劃分爲冷熱。好比我們公司的業務客戶往往會查詢最近3個月的訂單數據，3個月之前的數據基本不查詢，但是這些歷史數據都必須保留下來，所以數據會非常大。我們在正式遷移之前，按照下面的表格計算了一筆賬：
5.按照目前的數據規模，我們3個月之前的數據做了下估算，大概是20T。
這20T的數據可以歸檔到oss上，光一個月就幫我們節省了近2w的成本，整體的存儲成本最高降低了原來的 5% ，所以當時我們非常有動力做這次數據庫系統的升級。
數據遷移與歸檔
得益於PolarDB-X高度兼容MySQL數據庫，其開源開發的能力也充分兼容了MySQL的生態工具，整個過程異常的順利。我們先做了全量的遷移，再做了增量遷移。前後過程中我們充分做了數據校驗，確保數據萬無一失，最後做了數據切流。
我們遷移之前的表結構導入到PolarDB-X其實沒有做太大的變化，PolarDB-X的透明分佈式提供了表自動按主鍵拆分的能力，這樣我們遷移到PolarDB-X數據庫的表默認都是分表，極大滿足了我們分佈式的分表需求。 但遷移後我們的表並不是TTL表，也無法做冷數據歸檔，所以我們需要首先將表改造成TTL表，然後將該表做歸檔表的綁定。
TTL（Time to Live，生存週期）功能，支持在創建表的DDL語句中指定local_partition_definition語法，創建一個TTL表。TTL表會將每個物理表按照時間進行分區，並通過定時任務進行管理，能夠讓冷數據在PolarDB-X中按照一定的策略歸檔到OSS 但是遇到的第一個問題是TTL表主鍵必須包含時間列，那就得先做主鍵變更，再爲將表做TTL的轉化。好在PolarDB-X的主鍵變更是Online的過程，整個過程其實對業務是無感的，只需要做兩個DDL操作。
alter table t_orders drop primary key, add primary key(id，gmt_modified);
2. ALTER TABLE t_orders
LOCAL PARTITION BY RANGE (gmt_modified)
STARTWITH '2015-01-01'
INTERVAL 1 MONTH
EXPIRE AFTER 3
所以我們業務低峯期，做了下TTL表的轉化，這部分還算順利。但是此時的TTL表還不能定時歸檔，需要綁定到另外一張歸檔表。綁定過程很簡單，如下圖所示。
CREATE TABLE t_order_oss LIKE t_orders ENGINE = 'OSS' ARCHIVE_MODE = 'TTL';
將TTL表 t_orders 綁定到另外一張表t_order_oss，兩者的表結構一致，這樣定時將過期的冷數據從t_order遷移到 t_order_oss。只不過t_order_oss是更低成本的存儲介質oss。
一張表變成了兩者不同的表，對我們來說業務有改造成本的。但冷數據和熱數據的適用場景和存儲介質是不一樣的，兩者數據訪問延遲也是有一定的差異。熱數據經常需要高頻訪問，冷數據對我們來說很少查，也很少做變更。如果兩者是一張表，會增加業務異常訪問冷數據的風險，影響到了熱數據的SLA。區分之後，對熱表DDL操作由於數據有限，變更操作會非常友好。出於這樣的考慮，我們接受這樣的改造，實際證明改造成本也比較低，受益也明顯。經過這一波的遷移後，我們熱數據通常是指最近3個月的數據，意味着我們需要把過去幾年的數據歸檔到oss上，整個數據量大概是20T。我們配置歸檔的窗口都是我們的業務低峯期（02:00～-5:00），由於數據量比較多，整個歸檔持續了1個多月。歸檔後上線半年，業務感受非常深，由於訪問的數據更少了，業務訪問性能也提升了。
可以看到歸檔前訪問的數據量隨着時間不斷在增加，那麼大的數據量添加一個索引都非常困難。而歸檔後，業務訪問的數據量始終維持在1T左右，不再隨時間而變化。其實降低的不僅僅是存儲成本，之前數據都在數據庫，對存儲空間和資源要求比較高，我們需要配置比較大的MySQL集羣，現在數據大部分遷移到了冷數據上，數據庫本身存儲的數據其實不多，所以現在數據庫資源使用較之前也減少了很多。
冷表的結構變更
PolarDB-X數據庫系統上線後，不管是性能和成本都達到了我們的預期。但是後來我們業務需要對錶結構做變更，提示不允許做表結構的變更。由於PolarDB-X冷數據存儲介質是對象存儲，並且存儲格式是ORC。這兩者都不能直接對原生數據文件做變更，每次變更都要求對數據進行重寫，對於龐大的冷數據數據量，這種方案是無法接受了。好在PolarDB-X第一時間採用了多版本的方案，改寫SQL的方式做了支持。這個冷表的DDL過程，不涉及到數據重寫過程，每次DDL變更，只是在元數據構建了一個新的版本，元數據層面做好歷史數據和元數據版本的映射關係。在查詢掃描過程中，做好transform read。這裏我們以列類型變更爲例：
對t_order_oss的c3列類型做了變更，從int 類型變成了decimal類型。在修改列類型後，整個過程非常快，不涉及到數據文件的重寫。只是在元數據會記錄之前的version1和更改後的version2.當用戶發起查詢的時候，優化器識別數據文件的元數據版本和最終的數據版本。如果查詢的數據文件版本和最終的數據版本一致，則數據文件讀取的數據不需要做任何project。如果查詢的數據文件版本和最終版本有差異，那麼數據文件讀取的數據需要做project。如上圖所示，將一條SQL拆分成了兩條執行計劃，兩條執行計劃結果做union all，就是我們的查詢結果。這樣對DDL本身沒有任何代價，只是對查詢有代價，考慮到冷數據本身主要查詢頻率低，對RT延遲要求也低，所以我們覺得這個設計是合理的。基於這套online schema change方案，PolarDB-X數據庫對冷表支持了完備的DDL。
冷表的查詢加速
熟悉OSS的朋友都知道，OSS有帶寬限制，對於大量的數據掃描並不友好；而且PolarDB-X採用的是列存存儲格式（ORC），這種列存格式其實不太適用於TP數據庫。雖然我們將冷數據歸檔到了OSS，但是這塊票務系統在對賬期間，難免會對冷數據進行大規模掃描或點查。我們開始其實比較擔心冷數據歸檔的查詢性能的，但實際效果還是不錯的。
PolarDB-X在查詢鏈路上引入了Local Cache的IO加速技術，並且基於元數據和統計信息構建了多級裁剪技術。
1、表分區級別：通過分區規則裁剪到目標分區
2、RuntimeFilter級別：通過構建MinMaxFilter並下推用於文件裁剪
3、文件級別：通過MinMax統計信息定位到唯一文件
4、Stripe級別：通過MinMax統計信息及BloomFilter定位到唯一Striple
5、RowIndex級別：通過MinMax統計信息及BloomFilter定位到唯一RowGroup
6、列級別：通過列裁剪定位到制定的列做掃描
可以很好的滿足我們在冷數據的點查需求，在一些重吞吐的複雜查詢中PolarDB-X也引入了Native MPP技術和向量化技術，大大提高了複雜查詢的查詢效率。
數據庫系統遷移的總結
到目前爲止，這次數據庫系統遷移到PolarDB-X數據庫還是很成功的，取得以下四種主要的收益：
1、PolarDB-X提供的透明分佈式能力，大大降低我們的使用成本，業務上可以像使用單機MySQL數據庫一樣使用PolarDB-X。當空間不夠的時候，其提供的在線擴容能力，也確保我們後面可以從容面對業務的高速發展；
2、PolarDB-X提供的全局Binlog能力，可以確保我們的業務數據更加方便同步到下游的數倉系統，降低了我們ETL鏈路的維護成本；
3、存儲成本最高降至原來的5%，我們將大部分數據歸檔到了OSS上，極大的降低的我們的存儲成本。由於業務數據量訪問減少，數據庫本身的規格也減少了，數據庫部署成本也降低。PolarDB-X對冷表提供的Online Schema Change和查詢加速的技術，也滿足了我們業務需求。
4、PolarDB-X支持對冷數據對備份恢復，對，你沒聽錯。PolarDB-X也支持對帶有冷數據的實例做數據庫備份，這種InnoDB+OSS一體化備份能力，是其他產品不具備的。這個也是我們後期在生產中比較看重的點。
但是該吐槽還得吐槽。目前冷數據歸檔的表要求主鍵必須包含時間列，也分區必須按照時間分區，過期粒度是分區級別。這些都限制了用戶的使用。不過PolarDB-X數據庫馬上就要發佈新的冷數據歸檔的解決方案，新的方案聽說去除了主鍵必須包含時間列的限制，且支持行級的歸檔需求，那我們拭目以待吧！
本文爲阿里雲原創內容，未經允許不得轉載。