作者：杜霆，vivo互聯網存儲運維負責人
vivo 是一家以智能終端和智慧服務為核心的科技公司，服務全球 5億+ 用户，公司內分設多條業務線，其中vivo互聯網業務在近兩年內完成底層數據庫方案的升級以更好地支撐業務發展。業務使用OceanBase後，解決了原本的MySQL在大規模數據場景下的存儲與性能使用瓶頸，高併發數據更新效率提升60%，複雜查詢性能提升80%，存儲成本降低50%。
曾支撐數千套 MySQL 集羣穩定運行的技術架構遭遇瓶頸
在過去十多年，vivo一直使用MySQL作為底層數據庫。如圖1所示，vivo的 MySQL 集羣使用雙層異步複製架構：上層通過自研代理服務 Proxy 實現加解密、審計、連接池等能力，並通過運維平台對 Proxy 進行完全自動的運維管理，實現了探活、自動切換、自動部署等能力；最下層的 Agent 用於故障切換，通過 Raft 實現了多節點高可用部署；中間的Zookeeper 用於同步 MySQL元數據信息，保證 MySQL 集羣間的數據一致性。
圖1 MySQL 集羣的雙層異步複製架構
這套架構及管理方案具備自定義高可用切換能力、探活能力，已支撐數千套 MySQL 集羣的穩定運行。然而，在業務發展的過程中，該方案逐漸面臨數據存儲、讀寫性能的瓶頸。
數據存儲： MySQL 使用單機多實例部署架構，數據存儲在物理機中，當業務發展到一定規模後，存儲容量受到單機磁盤的限制，需要進行分表。而分庫分表的擴展性較差，導致業務、研發、運維等方面的投入成本越來越高。目前總存儲規模已經達到 PB 級別，面臨較高的存儲成本。
讀寫性能： vivo 龐大的業務規模中涉及大量複雜查詢，但 MySQL 的複雜查詢性能較低，無法滿足業務需求。而且在大批量高併發寫場景的效率低，上下游同步和離線查詢的從庫延遲較大，相關業務都會受到影響。
基於上述原因，vivo 開始調研能夠解決當前問題的數據庫產品。經過調研對比，最終選擇了具備水平擴展、資源隔離、低成本、強容災、高度兼容MySQL、HTAP等特性的OceanBase，並引進業務環境。
具體而言，自 2023 年第四季度起，存儲運維團隊開始啓動系統化調研，對部署架構、功能特性、性能指標、應用場景、成功案例、安全規範等方面進行調研評估。調研完成後，經部門級評審，正式決定引入 OceanBase 進行平台建設（見圖2）。
圖2 OceanBase的引入流程
2024 年，項目正式進入落地實施：
- 完成規範制定，開展性能壓測、高可用驗證、備份恢復與監控報警等驗證，確保滿足業務上線條件；
- 同步建設配套生態，部署 OCP、OMS、OBLoproxy 等核心組件，並集成下游 Binlog 消費鏈路，形成完整的上下游生態體系。
2024 年 7 月，首個邊緣業務完成試點接入。同時，存儲運維團隊將 OceanBase 的基礎能力（元數據管理、數據查詢、數據變更、集羣管理）逐步集成到現有運維平台。截至 2024 年底，已有十餘個業務、數十套集羣正式投產，規模持續擴大。
四個技術場景應用OceanBase，收益可觀
目前，在vivo互聯網業務線，已有四個數據庫場景使用OceanBase，並且運維體系已經開始逐步替換為OceanBase。
OceanBase解決了哪些問題？
1. 數據歸檔。
因為MySQL 存量數據龐大，部分業務的歷史數據已無需在線訪問，所以現階段冷數據歸檔採用 TokuDB 壓縮方案，壓縮比約 3–4 倍，並掛載大容量磁盤存儲。隨着數據持續增長，面對磁盤容量不足的問題，存儲運維團隊已多次拆分歸檔集羣，但拆分操作的運維成本高、擴展性差。引入 OceanBase ，利用其數據壓縮能力與分佈式擴展能力，可按業務粒度部署獨立集羣，實現橫向擴容與在線壓縮。一方面解決了業務側需要基於 MySQL 進行分庫分表的改造問題，另一方面降低了業務複雜度和運維成本，並顯著降低了歷史數據存儲空間。
2. 水平分庫分表。
在業務初期，業務團隊並沒有設計分庫分表，當集羣規模擴大後單實例容量受限，傳統 MySQL 需要人工實施分庫分表，投入大、週期長。引入 OceanBase 後，由於其原生支持分區表以及自動分區能力，可以自動水平拆分，減少了應用改造及人力成本等的投入，而且多租户資源隔離特性，可以減少原本單機多實例架構的資源爭用情況。
3. 高併發。
對於部分併發極高的業務，MySQL 容易出現寫延遲、吞吐下降等問題，而OceanBase 多節點並行處理，可有效分散寫壓力，保證低延遲與高吞吐。
4. HTAP 混合負載。
vivo互聯網業務線存在大量既有交易又有實時分析需求的混合型業務。引入 OceanBase 後，可同時滿足 TP 與 AP 查詢，顯著簡化整體架構。
自建運維平台，統一運維體系
使用 OceanBase 初期，vivo 互聯網業務的運維主要依賴開源平台，比如OceanBase 的運維管理平台 OCP。OCP 具備資源管理、性能監控、集羣管理、租户管理、備份恢復等完整的數據全生命週期管理能力，可以滿足基本的運維需求。但 vivo 互聯網業務內部有自建的 DaaS、PaaS 平台，於是存儲運維團隊啓動了將 OCP 的能力集成到自建平台的計劃，目前已在業務研發和 DBA 運維兩方面實現了一些必要能力。
- 面向業務研發：實現了應用詳情查詢、數據查詢、數據變更等能力。
- 面向 DBA 運維：實現了實例管理、域名管理、賬號管理等管理能力。
如圖3所示，藍色背景白色字體對應的功能是已經建設完成的功能；藍色背景黑色字體是正在建設的功能；白色背景對應的功能為後續規劃。通過平台整合，最終形成統一的內部自建運營平台，實現對開源平台的全面替代。
圖3 運營平台建設進度
OceanBase帶來了哪些收益？
高併發場景，性能提升60%以上
某業務因 MySQL 批量寫入過大，每秒40萬行的數據操作，導致 MySQL 主從延遲一直居高不下，存在數據丟失風險，同時離線業務無法查詢業務數據。該業務切換到 OceanBase 後，延遲問題得到解決，實現了上下游生態產品的數據實時同步。同時，得益於分佈式的特性，業務的寫入性能得到提升，整體的更新性能也提升了60%以上（見圖4）。
圖4 某業務切換到OceanBase後的性能提升
大規模數據變更效能翻倍，複雜查詢性能提升80%
業務歸檔庫原本使用 TokuDB 存儲引擎，數據容量可壓縮4倍，雖然緩解了物理機磁盤容量問題，但400億+的數據量，無法支持 DDL 變更。遷移到 OceanBase 數據庫後，不僅數據的存儲壓縮率和 TokuDB 基本一致，還支持對400億+數據量的大表做 DDL，僅用時2小時18分鐘就能完成， 性能相較於 TokuDB 提升多倍。OceanBase不僅解決了超大規模 MySQL 數據不能變更問題，還實現了與原業務表同步變更，徹底解決了原來大規模歸檔數據的在線變更難題。
此外，大規模數據量查詢業務切換至OceanBase後，整體時延降低了30%以上，實現TP、AP共存複雜業務查詢，性能提升80%。
硬件、運維等成本顯著降低
得益於 OceanBase 的高壓縮特性，數百TB的數據壓縮了60%，存儲成本節省50%，硬件成本得到顯著降低。此外，相較於運維人員對分庫分表的投入，OceanBase 原生支持的分區表、自動分區能力及在線擴縮容能力極大地釋放了運維人員的雙手，使運維成本和業務研發的開發成本大幅降低。
儲備國產技術棧，完善運維生態
後續vivo互聯網業務計劃從如下四個方面陸續落地 OceanBase 並逐步完善運維生態及體系建設。
- 將分佈式關係型數據庫長期納入技術棧。
公司現有數據庫產品已覆蓋多種類型的數據庫，如 MySQL、TiDB、Redis、Eelasticsearch、kv存儲 等，但缺少一款經過大規模驗證的分佈式關係型數據庫。經評估，OceanBase 可作為應對海量數據和高併發場景的分佈式數據庫產品補充，納入長期產品規劃。
- 國產數據庫技術儲備。
在國際供應鏈不確定性增加的背景下，MySQL、Redis 等開源產品存在潛在受限風險。OceanBase 屬國產自研數據庫，可將其作為關鍵備用技術棧，持續投入並完善其能力，以保障業務連續性。
- 運維生態建設。
結合OceanBase的生態工具產品，完善上下游運維生態工具，打造完整的上下游生態，涵蓋同步、備份、監控、審計、數據訂閲等全部環節，確保業務可無縫接入。
- 運維體系建設。
持續進行運維體系建設，逐步把 OceanBase 的元數據管理、集羣管理、監控告警、自動運維等能力集成至現有統一運維平台，實現與既有體系的風格一致、體驗一致。
