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