商業化爆發的背後是13年的純自研和產品化的成熟。會中，OB圍繞「一體化」產品戰略，發布一體化數據的首個長期支持版本OceanBase4.2.1LTS，並進一步提升列存性能，同時也從金融行業邁出一隻腳，在千行百業中留下腳印。

從集中式到分布式、從邊緣系統到核心系統，2023年國產資料庫生態在經歷著時代的變遷。這背後不只是OB一家企業的成績單，更代表整個中國企業對分布式資料庫從懷疑到嘗試，再到信任的發展歷程。

從場景中來，到產業中去

每每談到OB的自研之路，楊冰都會講到全球資料庫發展經歷了20年的空窗期。

80年代初期，今天全世界主流的關係型資料庫排著隊地誕生，到了90年代，又冒出了兩個開源的關係數據庫，但是在本世紀20多年來，全世界再也沒有出現新的關係型資料庫。

在「斷檔」的20年里，網際網路興起、移動網際網路爆發，但全世界再也沒有出現新的關係型資料庫，不是因為沒有需求，而是沒有新的場景。

楊冰對此解釋道：「資料庫本身是一個場景驅動的技術，使用場景上沒有形成代際躍遷的變化，也就沒法對現有資料庫的能力和架構產生太大的推動力。」

我們都知道，科技企業的技術往往分為兩類：一種是從實驗室走出來的技術，不斷突破功能和性能的極限，沒有最快只有更快；另一種則是從產業中走出來的技術，貼近客戶需求，不斷打磨，沒那麼「酷炫」但卻非常實用。

顯然，想要做好資料庫，就必須貼近場景、貼近用戶、貼近產業，這是一條幾乎不可選擇，卻少有人能夠「活下來」的路。

「開源的產品化簡單，自研更難，但我覺得這樣的系統很難有長久的競爭力，核心代碼不掌握在自己手裡，客戶的深度需求就沒有辦法滿足。」陽振坤講到。

從這個角度來看，早在2010年，OB做出全自研決定的那一刻，就埋下了商業化的引線。

縱觀OB的技術體系，會發現每一個技術特徵都是從客戶的需求出發，經過不斷打磨，做深做精後的結果。

當OB開始獨立面對市場上形形色色的企業級客戶，便發現從集中式替換到分布式，客戶並不擔心分布式資料庫本身，而是更在意平滑遷移的過程。

而這個過程是極為精細而複雜的工作，楊冰將這個過程比做「心臟搭橋手術」，首先要確保穩定可靠、可並跑、可回切，同時核心系統往往也是數據的中心樞紐，需要讓新的資料庫也融入原來的資料庫。

為了保證平滑遷移，OB向上適配了5大類的資料庫，包括Oracle、MySQL等傳統資料庫，也包括10＋雲上雲下的資料庫，向下通過Canel、Flink、DTS等比較常見的數據同步工具打通了上下游的數據處理軟體，讓其無縫地跟數據架構進行對接。

另一方面，一旦開始進行核心系統的大規模替換，成本是繞不開的。據楊冰透露，目前已經有大大小小的客戶all in OB，或者70%的業務系統都跑在OB上，當資料庫承載的業務量變大、規模變大、係數變多後，如何高效利用好每一份資源一定是企業最重要的目標。

比如OB採用了多副本備份的技術來保證數據一致性和穩定性，但多副本往往會對存儲成本提出更高的要求。於是，OB採用LSM-Tree的架構把數據分成了基線數據＋增量數據的形式，多副本之間共享一分基線數據，最終可以做到只有接近一分數據的存儲成本，

當然，包括HTAP引擎、高於通用標準的「五地三中心」、單機一體化的產品架構，也皆是OB這十三年「趟河」摸過的石頭。正如楊冰所說，「一個關係型資料庫不是開發出來的，更多是用出來的。」

從淘寶中誕生、支付寶中歷練再到產業中打磨，技術能力，從場景中來到產業中去。

究竟何為一體化？

金融行業客戶有個特點：極為在意效率和極致的性能。高效、簡潔是金融級資料庫的「魔鬼集訓必修課」。紅塔銀行內部就曾反饋道：「精密不複雜才是常理，架構本該簡潔」。

在這樣的背景下，產品化繁為簡，儘可能做到一體化，是OB的核心思路。

2022年，OB發布了業內首個單機分布式一體化架構的資料庫：小魚，這意味著客戶不再需要集中式分布式「二選一」，小魚可以隨意切換，小到個人站點、大到銀行核心系統、巨型電商網站，都可以在業務發展的不同階段選擇適配自己的高性價比方案。

據OceanBase CTO楊傳輝回憶：「13年前我加入OB團隊時，業界很流行開源的MySQL，但MySQL有兩個問題，只能處理簡單查詢，不能處理複雜查詢；只能處理小數據量，很難做擴展。我們希望OB的資料庫能兼具這兩方面的能力」，這可能算得上是OB做一體化初心之一。

當網際網路開始極速發展背後產生的數據，需要用EB作為單位計算，截止2022年底我國數據存儲量已達724.5EB，這意味著如今數據量的「大」和40年前Oracle誕生時理解的「大」，早已不在一個量級。

同時，隨著大量的中小企業湧進數字化大軍，資料庫不僅要大，更要小，彈性伸縮的能力成為對資料庫性能的一項核心考驗。OB誕生的第一個大型實戰場景，便是支持雙11，在10餘個雙11的歷練下，可以進行秒級擴縮容，並提供租戶級彈性和集群級彈性的多級彈性擴縮容能力，支持彈性水平或垂直的無中斷縮容。

單機分布式一體化架構資料庫的出現，也為OB打開了新的商業化思路。分布式資料庫是大型企業的核心業務負載過重，集中式資料庫性能無法滿足時的產物，但小魚的出現，讓中小企業得以在業務早期就可靈活選擇，並為後續業務體量爆發做準備，不必經歷大規模遷移的過程。

2023年，OB從一體化架構演進成了一體化資料庫、一體化產品，「一體化」的思路貫穿始終。

楊傳輝介紹到，一體化的思路就像蓋房子，單機分布式一體化架構如同地基，主要解決數據規模的問題，不管數據量級如何，都能通過一套系統統一解決。在一體化架構的基礎上，是進一步搭建一體化引擎，如同房子的鋼筋鐵骨支撐起來的架構，包括一體化存儲引擎、一體化事務、一體化的SQL引擎，主要解決數據的存儲和計算問題。

一體化引擎之後，進一步搭建產品，即房子本身。產品解決如何給客戶提供數據服務的問題，包括支持多種工作負載、實現多種數據模型、多種數據接口和兼容模式等等，這樣的一體化思路，用一個資料庫幾乎能解決80%的問題。

但需要注意的是，這裡的一體化思路並不是指「一款產品打天下」，而是一個兼具易用性和實用性的解決方案。

楊冰進一步闡釋了「一體化」的理念：「一體化本質上一個具備關鍵業務負載支撐能力的資料庫，在特殊的專業場景中我們認為還是需要專業資料庫。好比手機解決了大部分問題，但還是會有人買單反、遊戲機，還會有人去電影院。」

究其根本，核心仍然是從客戶的需求和場景出發，做有選擇、有取捨和有價值的一體化。

從18到1000+

從18個用戶到1000＋用戶，楊冰告訴我們，除了內部產品打磨成熟進入新周期後，外部有三個階段的核心變化。

一如同導語中所言，OB在商業化的最開始，選擇了大型可規模化複製的行業，如金融、運營商、政務等，三年內幾乎所有的路都走了一遍，開始出現規模化複製的跡象；二是在2021年將部分內核系統進行了開源，開源生態的培養需要過程，但對客戶數量的貢獻十分明顯，因為客戶沒有商業成本，而且OB的口碑讓客戶敢用於生產；三則是對雲上資源的投入和傾斜，2023年整年，幾乎飽和投入的方式，讓客戶數量有了明顯的增長。

這三個變化代表了三個不同的方向。積累經驗，是2B領域繞不開的過程。楊冰在會上也形象的講到「2B是沒有'魔法'的，都是做資料庫的，不同的場景之間聊天可能都聽不懂。」

在金融行業，全國目前有超過4000家大大小小的銀行，大型機構、小型機構的需求、關注點並不同。大型機構的基礎設施比較好，在性能要求上會比較高，關注點不僅是分布式架構，更是完整的解決方案和技術風險體系，同時大型機構的數據量大、基礎設施也較為多樣化和複雜，這要求OB具備更強的兼容性。

而小型金融機構，首先需要的是資料庫分布式的能力、平滑遷移的能力，無感使用和低成本更為重要，且更依賴於服務和培訓，因此，OB聯合了多家主流銀行應用ISV，有上百人參與到金融行業的交付運維中。

而通過服務各類客戶後積累了較為全面的能力體系，以適配千行百業的各類場景。但楊冰也坦言到：「不是做了金融級資料庫，所有行業都能做。」

首先外部商業化環境中，基礎設施的情況就千差萬別，有些行業是非常傳統的集中式用法，升級確實需要一些時間。另外每個行業都有一些特殊場景，大家看重的性能也不同，比如金融客戶很在意宕機時間和故障修復，嚴格控制在8秒以內，但製造業可能不要8秒，30秒也可以，但是特別看重成本，比如遊戲特別看重秒級回切、可以回檔，不同行業有不同的需求。

「打入一個行業，就要把上上下下的生態都對接一遍，底層能力再好前期也沒用，需要一些時間」，楊冰講道。

但關鍵核心業務負載需要的幾大基本功，在此前的3年、3大行業中得到了嚴酷的打磨。

過硬的基本功，雖然不代表能夠更快，但卻決定了能走多遠。

從生態建設的層面來看，完善的服務商生態也是爆發的基礎之一。2022年，OB發布了「珊瑚計劃」，並已和頭部最流行的100＋ISV打造了340個聯合解決方案，其中有20多個已經在其他行業中進行批量複製。OB的技術能力和產品能力通過合作夥伴和開源，正在進行裂變。

正所謂獨行快，眾行遠。十年埋頭技術，三年商業化探索之後，1000＋客戶體量，才剛剛為OB展開第二章。