分享：兩年兩度升級資料庫，我們經歷了什麼

本文來自社群分享，僅限交流探討。原文作者：陳雄軍，上海芯昌盛供應鏈科技有限公司運維負責人，負責集團資料庫、IT資產等運維管理工作。擁有多年資料庫運維經驗，負責集團MySQL、MongoDB、SQL Server、OceanBase 等資料庫的運維工作。

歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/

一、企業背景

上海芯昌盛供應鏈科技有限公司，是一家國際供應鏈管理服務公司，公司業務包括倉儲託管、一件代發、定製包裝、質量檢驗、協助選品、退貨簽收&查驗、國際貨物運輸代理等。目前已與多家知名電商平臺合作，包括Shopee、Wish、Tiktok、唯品會等。

二、業務背景

隨著近幾年公司的快速發展，業務所產生的資料越來越多，之前一直使用的MySQL資料庫已經無法支撐業務的快速增長，每天產生的車輛執行軌跡資料、訂單物流狀態等資料非常龐大，儲存在MySQL上已經出現明顯問題：

• 單表資料量過大，查詢出現明顯的效能下降，很多稍微複雜一些的查詢就直接卡死；
• MySQL高可用能力差，我們只用了MySQL的主從，主節點出現故障，切換到從節點經常需要補資料；
• 隨著資料量越來越大，MySQL這類單體資料庫很難實現快速的擴充套件，只能透過增加主機的配置，成本太高；
• MySQL做了分庫分表之後，帶來的運維複雜度和維護成本也隨之提高。

基於以上幾點，我們不得不尋求更好的解決方案。

三、資料庫選型

2020年，當時的OceanBase還沒有開源，我們對業務進行資料庫選型，因為業務原本使用的主要是MySQL資料庫，所以在選型中，以相容MySQL協議為首選條件，然後考察資料庫的查詢效能、擴充套件性以及高可用能力，另外開源也是一個重要條件。當時經過一段時間的調研，我們發現市面上有幾款比較適合的資料庫產品，但是考慮到未來國產化需求，當時我們選擇了TiDB作為我們的選型目標。

選擇TiDB資料庫主要有以下幾點滿足我們當前需求：

• 基本完全相容MySQL協議，業務從MySQL遷移到TiDB基本不需要修改；
• TiDB作為分散式資料庫，可以承載更大的資料量；
• 遷移到TiDB之後，相比MySQL查詢效能也有一定的提升；

但是，隨著我們使用的時間越來越久，問題也逐漸凸顯出來。

• TiDB上有的SQL查詢時間有時候會突然變的很長，影響業務使用體感；
• 對叢集進行擴容比較麻煩，擴容操作經常出現不成功現象；
• 另外TiDB整體元件還是比較多，維護起來也有一定難度，PD存在單節點瓶頸等。

不過，這些都還能夠接受。

直到2021年10月份，一次偶然機會，我參加了一個技術大會，在大會上了解到OceanBase資料庫，作為淘寶、支付寶內部一直在用，並且完全自主研發的分散式資料庫，已經執行了好多年，這確實激發了我很強的好奇心。OceanBase資料庫同樣在擴充套件性、效能及高可用方面非常優秀，因此我再次對TiDB和OceanBase資料庫進行了對比，當時使用的是OceanBase 3.1.2的版本，TiDB使用的是5.0.1版本。

基於以上幾點，我們最終選擇將資料庫切換到OceanBase上，但是因為一些其他原因，這次切換直到2022年11月份才完成。

四、遷移測試

在最終決定用OceanBase資料庫替換掉TiDB之後，我們便開啟了完成整的測試，以及遷移方案的確定。測試主要包括相容性測試、效能測試、擴充套件性測試、高可用測試等。

• 相容性方面：因為OceanBase也是完全相容MySQL5.7的語法，我們在測試中發現，基本不需要任何的修改，就可以完全遷移到OceanBase，業務程式碼所使用的連線驅動直接用MySQL官方驅動就可以；
• 效能方面：最開始我們在使用OceanBase時，並沒有注意到需要做分割槽表，所以在測試過程中，發現SQL查詢的效能反而比較差。後來經過OceanBase的工程師指導，我們做了些最佳化，包括將表建立成分割槽表，並建立了聯合索引之後，效能有了很大提升。
• 擴充套件性方面：我們嘗試給叢集中去新增伺服器，發現只需要在圖形化OCP管理平臺上簡單的操作下，就可以將新機器加入到叢集中，非常方便。
• 高可用方面：我們上線的時候使用OceanBase 3.X版本，高可用方面我們嘗試將一臺伺服器關掉，發現基本對叢集沒有影響，只有個別請求會失敗，不過在幾秒之後重新嘗試就能成功，這也應證了官方所說的RPO=0，RTO < 30s的指標。
• 資料遷移方面，我們最終由研發人員寫了一套工具，不斷從TiDB叢集select資料，然後在OceanBase資料庫中insert寫入。經過一段時間的同步，兩邊資料基本上差不多之後，我們找了一個業務低谷時間段，將資料庫叢集進行了切換。在切換之前我們已經做了充分準備，包括業務連線用的使用者賬號、連線性、功能性測試等。

五、效能最佳化

上面提到，最開始我們在使用OceanBase時，並沒有對錶進行分割槽操作。所以在開始測試時，發現查詢效能比較差，在測試環境中，有一張表的資料量大概8000多萬行，在執行如下查詢的時候，用了將近1min57s。

對此，我們明顯感覺沒有發揮出OceanBase的效能優勢，諮詢了OceanBase的工程師。根據他們的最佳化方式進行排查，發現我們一方面沒有對錶進行分割槽，另一方面索引建立也有一些可以最佳化的地方。

因此，我們對錶重新建立了分割槽，使用createtime欄位作為一級分割槽，用id做二級分割槽：

partition by range(UNIX_TIMESTAMP(createtime)) subpartition by key(id) subpartition template (
 subpartition p0,
 subpartition p1,
 subpartition p2,
 subpartition p3,
 subpartition p4,
 subpartition p5)
 (partition p202205 values less than (1654012800),
 partition p202206 values less than (1656604800),
 partition p202207 values less than (1659283200),
 partition p202208 values less than (1661961600),
 partition p202209 values less than (1664553600),
 partition p202210 values less than (1667232000),
 partition p202211 values less than (1669824000),
 partition p202212 values less than (1672502400))

在對錶執行了分割槽之後，再次執行相同的操作，發現速度非常快，40ms就返回了結果，這個大超我們預期，比MySQL快非常多，而且比TiDB也要快很多。

所以這裡在使用OceanBase的時候一定要注意，因為這種分散式架構，只有對錶做了分割槽之後，資料才會打散到所有的節點上，在做查詢計算的時候，才能發揮每個節點的能力。並且在做了分割槽之後，我對叢集進行擴容，叢集在新增了伺服器之後，資料會以分割槽的粒度，自動負載均衡到新的節點上，實現真正了線性擴充套件。

六、取得收益

• 資料庫服務更加穩定：在2023年1月份的時候，OceanBase資料庫叢集中有一臺伺服器記憶體條發生了故障，導致機器不可用，當時是凌晨0點多，但是檢視業務，並沒有發生任何錯誤請求，因為我們是跨境電商業務，晚上也會有很多業務請求，而我們卻沒有收到任何業務異常的反饋。這個記憶體條，到第二天中午更換完成，整個過程我們業務都是無感的，這讓我對OceanBase資料庫好感度倍升；
• 資料壓縮能力更強：之前在TiDB資料庫上，我們給每臺TiKV伺服器配置了10T的磁碟，但是在遷移到OceanBase之前，磁碟空間已經接近告警閾值了，而我們在遷移到OceanBase 資料庫上之後，發現每臺機器的磁碟使用率只有2T左右，所以看下來，OceanBase資料庫的資料壓縮能力要好很多。
• 運維成本更低：目前我們只用一套OceanBase資料庫，就解決了之前需要維護多套MySQL主從的運維成本問題，並且高可用方面OceanBase原生具備，不需要人為過多幹預，節點發生故障也會自動實現切換，我們可以有更多時間聚焦業務。

七、對產品的展望

目前OceanBase使用下來整體感覺還是很絲滑，不過個人覺得還是有些地方可以再最佳化些，例如OceanBase的錯誤日誌目前還是比較難看懂，日誌列印太多了，有用資訊有時被淹沒在日誌裡。

未來我們還將對OceanBase做更多的探索，當前我們的AP報表業務資料庫用的是SQL Server，OceanBase具備HTAP的能力，一套叢集可以同時支撐TP和AP查詢，因此未來我們也計劃將這個業務切換到OceanBase上。最後希望OceanBase資料庫越來越強大。