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