OceanBase進軍公有云這一年：在最激烈的賽道，殺出來
如今，數據庫市場正在邁入新的競爭階段——一場云上的角逐。
2022 年，cn公有云數據庫市場規模首次過半[1]，預計未來占比將進一步擴大。許多cn的數據庫廠商也抓住了云計算的發展趨勢，積極進軍云數據庫。
但是，這并不容易。許多企業已經在使用傳統的數據庫產品，要說服他們使用或遷移到云，需要打消客戶對新技術的疑慮，解決數據遷移的技術和業務挑戰，提供強大的數據安全和隱私保護功能，以及，在保證產品質量和服務水平的前提下，提供具有競爭力的價格——以數據庫產品的固有「粘性」，這是一件極難做到的事情。
云數據庫市場的參與者眾多，每個玩家都在努力提供更好的產品和服務，爭取獲得更大的市場份額。
作為原生分布式數據庫的領先產品，OceanBase 在 2022 年 8 月宣布推出云數據庫 OB Cloud。經過一年的發展，OB Cloud 在全球贏得了眾多客戶，包括新零售行業的海底撈、二維火和客如云，制造業的理想汽車，互聯網行業的高德、攜程、快手、作業幫、翼鷗教育、GCash，以及跨境行業的洋蔥集團、縱騰集團、遞四方等。
OB Cloud 做對了什么？
今天就來看幾個故事，了解 OceanBase 在公有云領域的技術之道。
RTO<8 秒，云上可享分布式數據庫的最高可用性
2023 年 5 月，理想汽車自動駕駛和車云等系統批量上線 OB Cloud，以應對大量云場景帶來的挑戰。這一決定的背后，是其產線運維系統在 OceanBase 上一年多的穩定運行，實踐了 RTO（Recovery Time Objective，恢復時間目標）秒級的極致體驗。
RTO 對汽車制造為什么重要？
汽車制造流水線是一個高度復雜和自動化的系統，會產生大量的數據，包括機器數據（生產線上的各種設備和機器的運行數據，如溫度、壓力、轉速、電流等）、工藝數據（產品制造過程的各種參數，如加工時間、材料使用量、產品質量數據等），制造執行系統（MES）數據（如生產計劃、庫存管理、訂單信息、物料需求計劃等）。
一些大型的汽車制造商可能會每天產生高達數 PB（1PB=1000TB）的數據。
使用這些數據進行分析，可以幫助制造商更好地理解生產過程、優化工藝，提高生產效率和產品質量。然而，處理如此巨量的數據需要強大的數據庫系統，這也是許多制造商在數字化轉型過程中需要面對的一個主要難題。
隨著理想汽車近年來的高速發展，產線系統的數據量激增，其數據庫系統在處理大量并發請求或大規模數據時開始出現性能瓶頸，對生產線的穩定運行構成了嚴重威脅。對車企來說，產線就是生命線，保證產線的平穩高效運轉至關重要，產線上的任何一個系統出現故障，都可能導致停產，而每一秒的停滯都意味著巨大的人力和資源損失。
在這樣的背景下，理想汽車開始自研智能制造操作系統 Li-MOS，并急于尋找一款極致穩定、可靠、擴展性強的數據庫，以應對系統穩定性和高可用的挑戰。「OceanBase 投產至今，始終保持零故障穩定運行。」理想 DBA 負責人趙海軍回憶。
RTO 是一個衡量系統在出現故障后恢復正常運行所需時間的重要指標。這個時間包括了檢測到問題、啟動恢復過程，以及恢復操作直到系統恢復正常運行的全部時間，這一數字也成為衡量在線應用的數據庫故障恢復水平的核心指標。
2014 年，OceanBase 在業界首次提出 RTO<30 秒，并且整個故障恢復過程完全自動不再需要人工參與，在當年雙十一支_付_寶交易過程中全球首次做到分布式數據庫不丟數據（RPO=0）、不停服務（RTO<30s）。如今，RTO＜30s 已經成為分布式數據庫業界的事實標準。2022 年，OceanBase 4.0 首次實現 RTO<8s，真正將故障恢復時間從分鐘級降低到秒級。
從 30 秒到 8 秒，這短短 22 秒的提升看似簡單，但背后涉及了大量技術和工程的挑戰。就像 F1 賽車比賽中的換胎過程，每一秒的縮短都是對技術、基礎設施、團隊協作，以及最重要的，對應用場景和業務流程的深刻理解和精準控制。
在 4.0 版本中，OceanBase 做了非常大的架構調整，把最底層的選舉和一致性協議做了重新設計和實現，并做了大量的優化。選舉方面，不再依賴于Node之間的絕對時間，而是完全基于消息驅動，將整個選舉 Lease 的時間縮短到了 4 秒以內。不僅如此，在更上層的 RPC 框架內部重新設計了一套故障檢測機制，當主Node出現故障時，系統會直接進行有主的改選，可以在百毫秒的級別就把主的服務切換到一個新的 leader 上。一致性方面，所有的備Node都能實時并行地去回放主Node寫入的內容，從而確保了在主Node故障后，備Node能夠立即承擔服務。并且，基于 Paxos 算法和動態日志流技術的創新，OceanBase 在單機模式下可以跑出超過MySQL 的性能，在測試場景下，可以做到接近 200 萬的 TPS。
作為共識協議的「本源」、容錯性最好的 Paxos，其工程實現難度也是最大的。OceanBase 早在 1.0 版本就完整獨立地實現了基于 Multi-Paxos 算法的日志同步機制，并在極致場景下打磨多年。正是因為一開始就完全自研，所以能夠實現這些在底層架構上的創新。
升級至 OceanBase 后，理想汽車的產線執行系統數據庫抖動頻率平均下降約 80%，對于常見的故障事件真正做到了「先恢復、后分析」，大幅提升系統運行穩定性，結合智能運維體系，理想汽車的產線執行系統能夠在無人值守的情況下，迅速完成故障的自動恢復，實現汽車產線系統數據庫的「無人駕駛」。
OB Cloud 完全支持 OceanBase 4.x 版本，提供同樣的高可用服務。在產線運維系統已穩定運行 17 個月后，理想汽車決定，繼續將自動駕駛和車云等構建于云上的數據庫系統遷移至 OceanBase 的云上版本，繼續在云上實現嚴苛的 RTO 目標。
極致壓縮，用技術可持續降本
再來看一個故事。
作為菲律賓最大的電子錢包應用，GCash 被稱為「菲律賓的支_付_寶」，注冊用戶 6000 萬。然而，業務的快速擴展，其存儲和計算資源成本也呈現出迅猛的增長，給公司帶來了巨大的成本壓力。2020 年，GCash 日均交易量已達百萬級，每個月都有超過 18TB 的新數據涌入，而且還在以大約 10% 的增幅繼續上漲。為了處理這些數據，運維團隊不得不投入大量資源進行數據拆分，不僅消耗了大量的人力和時間，還可能對系統的性能和穩定性產生影響。與此同時，數據存儲空間的壓力也在不斷增大，數據庫管理員（DBA）經常需要通宵達旦地進行數據清理和歸檔以釋放存儲空間。然而，這種解決方案只是暫時的，不能從根本上解決問題，反而進一步增加了運維成本。
在最繁忙的時候，運維團隊需要管理超過 200 個 MySQL 實例。面對如此大的業務量，系統很難平穩地進行變更以支持新的業務，在極端情況下還可能會出現數據丟失。
GCash 迫切需要一個新的云上的存儲解決方案，以應對數據快速增長帶來的成本挑戰。
最終，憑借高效、可擴展且高性價比的數據存儲服務，以及 OceanBase 在金融支付領域的豐富積累，GCash 選擇 OB Cloud 作為其新一代的存儲底盤，OB Cloud提供了同 OceanBase 完全一致的數據壓縮體驗。
OceanBase 自研 LSM-Tree 架構的存儲引擎，能根據數據存儲的特征進行自適應編碼壓縮，提供高效的數據壓縮能力。在過去服務用戶的經驗中，存儲空間甚至可以降低到用戶原有數據庫系統存儲空間的十分之一。
通過壓縮來降低存儲成本是再自然不過的選擇。但是，數據壓縮最終目的是降本增效，降本不能犧牲效率，因此，實現高壓縮比的前提一定是先保證高性能，其次，是做出更適合實際業務場景的數據壓縮。
通過使用自主研發的數據編碼壓縮技術，OceanBase可以根據數據類型和分布特性，自動選擇最合適的編碼方式，在保證性能的同時，實現高效的數據壓縮。假設需要存儲這 15 個數字：「0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233」。我們可以選擇直接存儲它們，每個數字占用一個存儲單元，共需要 15 個存儲單元。或者，我們也可以根據這串數字的特性——每個數字都是前兩個數字之和，選擇在一個存儲單元中寫入「前 15 個斐波那契數」。這樣，相同的信息內容，存儲的數據量卻大幅度減少。更重要的是，這種壓縮過程是無損的。當然，這只是一個簡化的例子，實際的過程要復雜得多。除了能感知數據特征并按列進行壓縮的數據編碼（encoding），OceanBase還同時支持不感知數據特征的通用壓縮（compression）。也就是說，可以對一個數據塊先進行編碼，然后再進行通用壓縮，從而實現更高的壓縮率。
這些數據編碼格式考慮到了對查詢性能的影響。不僅如此，壓縮的路徑也經過設計，不會降低計算效率和解壓縮性能。
結果顯示，借助高效存儲引擎和云上高速的塊存儲服務，OB Cloud 使 GCash 的數據存儲空間節省了 70%，數據庫資源成本節省了 40%。這一結果大大超過了 GCash 的預期，為其帶來了顯著的效益，并使其能夠更有效地服務持續增長的用戶群體。
多級彈性擴縮容，應對流量常態化急劇波動
在現今的消費市場，新的流量模式和消費習慣正在不斷涌現。
每年的節假日，尤其是七夕、雙旦，對海底撈這類餐飲及零售類企業至關重要。在數字化轉型過程中，系統在流量波峰與波谷的處理能力也直接影響到業務。
海底撈的進銷存系統，就是個典型例子。以 2021 年上半年為例，海底撈僅在瓜果蔬肉類的采購總金額就超過了 28 億元，覆蓋新疆、貴州、云南等 29 個省市自治區，數據體量異常巨大，絲滑的數據處理關系著食材品質和及時供應。
隨著業務快速增長，使用傳統數據庫的進銷存系統面臨越來越多的挑戰。比如，全國門店的食材和物料進貨、存儲、銷售及供應等數據，以及數據實時變化帶來的高并發問題；門店銷售單中的食材和物料變動必須與庫存模塊的數量保持一致，如果不一致可能會導致備貨過量或缺貨；訂單狀態不明確，會導致用戶服務不到位，影響就餐滿意度等。
每年的七夕、雙旦，不僅是海底撈員工，也是系統數據處理最繁忙的時候，由于個別熱銷商品庫存變化非常快，單條數據需支持秒級數千次的高變動頻次，這也要求系統必須能做到實時分析匯總商品數量變化情況，以及時備貨供應。
如何更靈活、更安全、更低成本地實現數據庫靈活擴縮容，完美支持每次節假日的流量洪峰，成為海底撈最關心的問題。
為了更好地應對流量的急速變化，海底撈的業務數據庫需要具備靈活的調整能力：在業務低峰期，以較小的規模穩定運行，減少資源浪費；在業務高峰期，快速擴容，以保障節假日的穩定運營。
針對海底撈的業務特點和需求，OB Cloud 以其從 OceanBase 繼承的多級彈性伸縮能力，在云上打造了一個理想的解決方案。
在 OB Cloud 中，每一個業務（租戶）擁有自己獨立的資源。這些資源位于同一個資源池中，可以根據業務的實際需求進行動態調整。這種設計使得資源的使用更加精確，避免浪費。同時，這種設計也使得業務能夠更快速地響應流量的變化，提高了業務的響應能力。
面對較大的業務流量，簡單調整租戶規格可能還無法滿足業務需求，這時候就要在集群上做調整。在 OB Cloud 中，可以通過改變服務器的配置（垂直擴縮容），或者增加或減少服務器的數量（水平擴縮容）來適應業務需求的變化，而后者是 MySQL 等主備架構難以做到的。這兩種擴縮容可以互相結合，提供更大的靈活性，有效地應對流量的突增和突減，保證業務的穩定性和效率。
在剛剛過去的七夕節，海底撈進銷存系統經受了兩倍于去年的流量峰值，但基于 OB Cloud 的加持，提升了 45% 的系統實時分析算力、降低 50% 的數據庫整體成本，從容應對了節日大考。
OceanBase 還在一個更高的層面，探索業務和架構的靈活性：首次引入了創新的「單機分布式一體化架構」，小到使用公共云的個人小站點，大到使用私有云、混合云的銀行核心系統、巨型電商網站，都可以在業務發展不同階段根據自身特點，靈活滿足性價比和高可用的需求，而不是受制于技術被迫接受一些他們并不需要的能力。
這也引出了一個新的挑戰——如何在復雜的云計算架構和多樣的計算場景中，提供一種統一而且高效的云數據庫解決方案。支持多種云的基礎設施及混合云架構
云計算已經從初期的公有云和私有云，發展到包含多個數據中心的混合云架構。這轉變也讓我們向更復雜的架構和混合云場景邁進。越來越多的企業開始在多個基礎設施上部署應用和數據，一方面利用混合云環境的靈活性和快速響應，一方面可以為不同的應用場景選擇不同的云基礎設施，充分發揮各個云服務的獨特優勢。
例如理想汽車，其生產線制造系統在數據中心進行私有部署，而車輛云和自動駕駛系統則選擇了多個不同的云基礎設施，并且在公有云的多個地域進行部署，這樣即使部分功能出現故障，整體服務也不會受到影響，保證車主的行車安全。
但是，這種模式也帶來了很多技術上的挑戰：不同數據庫產品在不同云基礎設施上的功能性能差異，增加了運維復雜度和資源整合難度；傳統單體數據庫難以擴展并存在單點瓶頸問題，無法滿足如車聯網系統這樣的多地訪問的低延遲需求。此外，雖然某些數據庫產品解決了擴展性問題，但它們的一致性協議對網絡延遲敏感，可能導致在遠距離機房或網絡環境不穩定的場景下產生寫入抖動和服務不穩定，難以滿足類似車聯網、自動駕駛業務的低延遲要求，等等。
面對多基礎設施的挑戰，需要一種靈活、可擴展的混合云架構解決方案，能夠統一管理和簡化這些環境，同時還能提供一致的性能和功能。
OceanBase 不依賴專屬硬件并能支持不同云基礎設施，它采用了無共享架構。通過使用 OB Cloud，理想汽車可以在數據中心部署整套 OceanBase 平臺，也可以在不同的云基礎設施和云服務上提供一致的功能和管理界面，這大大提高了存儲底盤的一體性和管理效率。同時，OB Cloud 的原生高可用架構可以在局部單點故障時快速自動恢復，甚至在跨地域部署的情況下也能提供穩定的服務，確保像聯網車機這樣的關鍵系統的安全運行，保證車主的行車體驗。
現在，理想汽車借助 OceanBase 打造全球領先的制造系統，并在 OB Cloud 上實現車云業務跨云異地多活，產線連續性和業務穩定性得到保障。
結語
OB Cloud 的一年表現，是 OceanBase 不斷從結果出發，自我創新、自我迭代的印證。
cn擁有最龐大的數據基礎，用戶的應用最有可能催生原創創新。無論是技術還是工程，都要回歸實際，一個參數的調整，毫秒級的誤差，都可能導致各種問題，需要一步步打磨，持續改進。過去幾年來，OceanBase 擁抱開源和社區、推出云數據庫，除了產品本身的研發，相關的文檔、培訓和配套措施也在同步推進。
正如 C++之父 Bjarne Stroustrup 說的，世界只有兩種編程語言：一種是為人詬病的，一種是無人問津的。
云數據庫擁有巨大的發展潛力和前景，需要依賴全生態的協同才能成功。這是一個困難的過程，需要大量的投入和持續的努力。
最終，客戶的口碑將是最有力的證明。