分享：叢集吞吐量以1抵5，車企MySQL八大痛點的解決方案

本文來自社群分享，僅限交流探討。原文作者：李嬋玲，某智慧車企DBA。歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/

最近一年，我們完成了從MySQL到OceanBase的替代過程，既降低了架構複雜度和儲存成本，又提高了擴充套件性和吞吐量，而且再也不用擔心資料不一致問題了。故而將我們遇到的痛點問題、解決方案、技術選型過程總結成此文，供大家參考。

一、業務增長凸顯MySQL八大支撐瓶頸

相信很多企業都會因為業務快速發展，資料成指數級增長帶來一些新的需求或系統瓶頸。我所在的國內某知名智慧車企也面臨這樣的問題，特別是我們的業務監控資料和訊號資料在近幾年爆發式增長，我們過去使用的MySQL資料庫越來越難以應對，主要體現為以下八個方面。

1. 效能瓶頸：單臺伺服器難以承受大規模資料和請求訪問，導致資料庫效能下降，只能透過部署多套叢集解決。
2. 水平擴充套件困難：單叢集容量達到瓶頸時，無法實現無縫擴充套件，需要停機維護，影響業務執行。
3. 資料一致性難以保證：多叢集資料合併的時候，資料更新同步難度大，易出現資料不一致的情況。
4. 多活實現困難：多活場景下，無法保證業務雙寫。
5. 實效性差：多叢集的跨節點join操作需要記憶體運算，或者大資料整合後提供，時效性無法保證。
6. 容易造成叢集資料或流量傾斜。
7. 各叢集之間資料排程麻煩。
8. 運維壓力大：需要定期備份歸檔資料，排查資料問題。

為了解決上述八個問題，我們需要制定高效的資料庫解決方案，於是開始了資料庫的調研、選型、替換之旅。

二、分散式資料庫選型十要素

根據業務需求分析，我們決定擁抱分散式資料庫，並以十個方面為考慮因素對市面上的分散式資料庫產品展開調研。

1. 資料模型：支援的資料模型是否豐富？能否滿足各種應用場景？
2. 效能：效能是否足夠優秀？理論讀寫效能、事務能達到多少？併發能力和水平擴充套件能力如何？
3. 可用性和容錯性：RPO、RTO能達到多少？容錯機制怎麼樣？備份與恢復能力如何？透過什麼樣的機制保證資料的高可用和可靠性？叢集管理和運維能力如何？
4. 安全性：安全策略有哪些？能否對資料進行加密？身份驗證如何和？訪問控制如何？
5. 生態環境：生態如何？基本工具如何？社群與商業支援如何？
6. 成本效益：開發對接成本如何？同樣需求的部署成本如何？同等資料量的儲存成本如何？以及後續擴容的成本和運維成本如何？採購成本如何？
7. 可擴充套件性：節點數量有無限制？使用什麼分散式架構？叢集是如何管理的？
8. 應用場景：需要了解資料庫的適用場景和行業應用，是否有成功案例？
9. 是否自研：全自研？還是部分自研？
10. 是否支援單元化場景？

（一）TiDB與OceanBase多方面對比

透過篩選，最終選定兩個分散式資料庫產品：TiDB、OceanBase，並從分庫分表、相容性、多活容災、效能、安全性、成本、生態等環境進行對比。

首先，兩種資料庫型別應用設計方面，都對業務透明，對外表現為一個整體資料庫，不需要業務進行分庫分表。

其中TiDB是自動分割槽，底層自動使用region(預設96M)打散；不支援多租戶功能，資源無法隔離，同叢集的業務相互影響；提供TiDB節點配合負載均衡使用。

OceanBase可以根據業務規則設計最優資料模型，支援一級分割槽和二級分割槽，支援分割槽裁剪；支援多租戶，可做到租戶間資源隔離；提供OBProxy無狀態代理，支援部署在OB伺服器，對於延時要求較高的服務，可以以SIdeCar模式部署在應用Pod中，應用本地迴環地址訪問。

其次，應⽤和資料庫解耦方面，Oceanbase與TiDB都高度相容MySQL，方便業務平滑遷移。OceanBase3.x不支援的少許alter型別變更在4.1已支援（如：int到varchar）。

再次，對於異地多活架構，二者均可實現兩地三中⼼多活部署，以及同城的兩中⼼雙活。不過OceanBase採用的Paxos協議對於複雜⽹絡環境的容忍性比TiDB採用的 Raft更強。

最後，在運維管理方面，OceanBase和TiDB都具備查詢慢SQL、執行計劃、終止異常session等。OceanBase提供OCP平臺進行管理叢集，OBD黑屏命令輔助，TiDB提供dashboard平臺和Tiup黑屏命令進行叢集管理。

此外，我們針對產品調研時關注的十個方面也進行了詳細對比，資料如下表。

經過綜合對比，我們傾向於使用OceanBase，那麼，OceanBase真能解決MySQL的痛點嗎？我們接下來看下OceanBase和MySQL有哪些實際區別。

MySQL 與 OceanBase壓測對比

我們儘可能使用同樣的配置進行測試對比，資料如下。

硬體配置與軟體版本

硬體配置

補充說明一下，MySQL的機器配置雖然是32C128G，實際上我們透過引數配置最後和Oceanbase的20C90G保持一致；

軟體版本

壓測結果對比

TPS/QPS對比如下：

壓測結論

• 執行緒數 < 200時，MySQL在TPS、OPS方面表現更好；

• 執行緒數 > 200時，OceanBase在TPS、OPS方面表現更好；

• OceanBase的3個節點的叢集能達到20w的qps；

經過壓測，OceanBase的高可用、高併發能力完全能滿足我們的業務需求，同時，我們在壓測的時候進行故障模擬，能達到官方所說的RPO=0，RTO<30s（我們壓測的3.x的版本，4.x的RTO可以達到8s以下）。另外，動態擴容基本上也無感知，透過租戶管理讓業務資料隔離；我們用OMS將業務壓測的測試資料同步到OceanBase上，能夠實現業務在測試環境無縫切換到Oceanbase上。所以我們決定部署OceanBase。

三、業務遷移過程及注意事項

經過壓測，我們發現OceanBase在高併發的情況下，除了QPS的效能不錯外，還使用了LSM-Tree的儲存結構（主要分為兩方面：MemTable代表記憶體、 SSTable代表磁碟）。理論上只要服務的記憶體足夠大，基本上都是記憶體寫（轉儲的時候，效能會有一定的下降），這比較適合我們的業務監控資料和訊號資料。同時，OceanBase支援單張萬億級資料的表，完全能滿足我們的需求，還不需要做資料的歸檔。

我們的業務監控資料和訊號資料，以接收為主，主要是寫，前端應用會有一些場景透過id去查基線資料。在平臺端，根據監控資料做指標計算，以流的方式處理。我們的訊號資料也差不多類似的場景，OceanBase的壓測情況，完全能滿足我們的需求。

第一步，分割槽表設計

首次設計分割槽表的表結構如下：

-- 分割槽欄位是create_time，型別TIMESTAMP 
 CREATE TABLE biz_monitor (
  id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵', 
  biz_name varchar(50) NOT NULL COMMENT '業務名稱', 
  event_type varchar(50) NOT NULL COMMENT '事件型別', 
  ...., 
  create_time TIMESTAMP NOT NULL COMMENT '建立時間', 
  PRIMARY KEY (id,create_time) 
 )AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT = '業務監控資料表' 
 PARTITION BY RANGE(UNIX_TIMESTAMP(create_time)) 
 ( 
  PARTITION M202301 VALUES LESS THAN(UNIX_TIMESTAMP('2023-02-01')), 
  PARTITION M202302 VALUES LESS THAN(UNIX_TIMESTAMP('2023-03-01')), 
  PARTITION M202303 VALUES LESS THAN(UNIX_TIMESTAMP('2023-04-01')) 
 );

為了保證業務上線OceanBase後的穩定性，我們根據業務場景對OceanBase進行了壓測。 期間遇到了問題：壓測期間機器的CPU大約50%左右，說明未達到瓶頸，但QPS一直壓測不上去，TopSQL也沒有特別慢，大約30ms左右。

最後的租戶配置是12C40G*4unit

從監控資料可知：

1. 壓測期間機器的CPU大約50%左右，未達到瓶頸。
2. 響應時間較慢，對於other型別需要100ms以上。
3. 等待事件也較多，其中other_wait最多。

而且配置由6C20G 4(primary zone)改為 12C40G 4(zone1,zone2,zone3)未見QPS由提升，最多的QPS只有2.5w左右。

經過分析，發現業務存在單獨使用表id進行查詢的情況，查詢耗時30ms以上，執行次數較多，導致CPU總耗時較長，具體資訊如下圖TopSQL所示。

針對分割槽表直接使用id查詢的情況，我們調整了分割槽表的結構（如下所示），將主鍵調整為分割槽欄位在前，id在後的形式，再加入一個單獨的id全域性唯一索引。表結構調整後，該sql的效能得到了極大提升，從30ms降低至5ms左右。

-- 分割槽欄位是create_time，型別TIMESTAMP,將主鍵調整為分割槽欄位在前，id在後的形式，然後再加入一個單獨的id全域性唯一索引
 CREATE TABLE biz_monitor (
  id bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵', 
  biz_name varchar(50) NOT NULL COMMENT '業務名稱', 
  event_type varchar(50) NOT NULL COMMENT '事件型別', 
  ...., 
  create_time TIMESTAMP NOT NULL COMMENT '建立時間', 
  PRIMARY KEY (create_time,id),
  UNIQUE KEY `uniq_id` (`id`) global
 )AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COMMENT = '業務監控資料表' 
 PARTITION BY RANGE(UNIX_TIMESTAMP(create_time)) 
 ( 
  PARTITION M202301 VALU，ES LESS THAN(UNIX_TIMESTAMP('2023-02-01')), 
  PARTITION M202302 VALUES LESS THAN(UNIX_TIMESTAMP('2023-03-01')), 
  PARTITION M202303 VALUES LESS THAN(UNIX_TIMESTAMP('2023-04-01')) 
 );

第二步，使用OMS進行資料遷移

將資料從MySQL遷移到OceanBase的時候，我們選擇了OceanBase 資料庫一站式資料傳輸和同步的產品OMS（如下圖），它支援多種關係型資料庫、訊息佇列與 OceanBase 資料庫之間的資料複製，是集資料遷移、實時資料同步和增量資料訂閱於一體的資料傳輸服務。使用OMS進行資料遷移，極大地簡化了DBA的工作。

使用OMS資料遷移的流程如下。

值得一提的是， 使用 OMS 需要注意兩點 ：一是遷移和全量校驗對原業務有一定的影響，建議遷移時選擇業務低峰期或者從庫進行；二是遷移時建議調大租戶的記憶體，避免Over tenant memory limits問題。

四、總結

以上就是我們解決MySQL痛點的過程，那麼替換為OceanBase以後真的有效嗎？

就目前的使用效果來看，OceanBase給我們 的業務帶來了七方面的明顯提升。

1. 降低了業務系統的複雜度，叢集從有狀態變成了無狀態，服務的穩定性提高，開發運維成本降低。
2. 在流量傾斜時，我們可以動態的切換主從副本，從而快速的實現流量轉移。
3. 當有突發流量的時候，我們可以快速的擴充套件，提升整體的吞吐量。
4. 叢集內join操作，透過表組最佳化後，能實時提供。
5. 我們一套OceanBase叢集寫吞吐量是之前MySQL叢集5套的總和。
6. 使用OceanBase的壓縮功能後，我們的儲存由16TB降到了4-5TB，整體成本降低了70%。
7. 再也不用幫業務排查資料不一致的問題了。

OceanBase為我們分割槽分表提供了非常好的一個開端，避免了使用分散式中介軟體 sql的不相容、維護繁瑣問題。目前，我們還有業務單元化的需求，也已經經過了測試和驗證，後續會逐漸應用到生產環境中。

此外，在使用OceanBase過程中也遇到了幾個小問題，希望官方在後續版本中支援OCP平臺自動檢測分割槽表並新增分割槽，以及叢集磁碟佔用百分比可以調大也可以調小。