5 月 17 日，OceanBase 在第三屆開發者大會上宣佈一體化架構再升級，全新推出“共享儲存”產品。
這是繼今年 3 月推出單機版資料庫後，OceanBase 放出的又一個“大招”產品。這款產品在業內首個實現了物件儲存與事務型資料庫（TP）深度整合，也使得 OB Cloud 成為業界首個在 TP 場景下支援物件儲存的多雲原生資料庫。
它以 OceanBase 根自研的一體化架構實現對物件儲存（如 Amazon S3、阿里雲 OSS、等）的深度支援，可將生產資料持久化落地於物件儲存，創新構建存算一體與分離架構，不僅大幅提升雲上資料儲存的彈性擴充套件能力，更使 TP 負載的儲存成本最高降低 50%。
具體來講，這款產品將資料持久化從雲盤遷移至物件儲存，透過“雲盤 + 物件儲存”的混合方案，實現計算與儲存的解耦。計算層可按需彈性擴充套件，儲存層具備更高的容量彈性與成本優勢，物件儲存只需保留單副本，即可實現資料的高可靠性；同時利用其跨可用區共享能力，保障同城多 AZ 環境下的資料高可用性，為海量資料場景提供更優的成本與效能平衡。
為什麼 OceanBase 會在這樣的時間點上推出這款產品？
那就要從當前大模型時代，資料處理和管理所面臨的痛點說起。
先來看幾組資料。
據 IDC 預測，2028 年全球 GenAI 市場規模將達 2842 億美元，佔 AI 市場投資總規模的 35%，五年複合增長率達 63.8%；聚焦中國，GenAI 市場規模將於 2028 年超過 3000 億美元，佔 AI 市場總規模的比例將從 2024 年的 18.9% 增至 2028 年的 30.6%， 五年複合增長率為 51.5.%。
如此大規模的市場，產生的資料也一定是海量的。
IDC Global DataSphere（全球資料圈）最新報告顯示，2028 年全球新生成資料量規模將達到 393.9ZB（含消費者資料和企業資料）。其中，企業資料規模和增速尤為凸顯，IDC 預計，2028 年全球資料圈企業份額佔比將擴大至 80.5%，即 317.1ZB，2023-2928 年年複合增長率高達 30.2%。
海量資料雖蘊含巨大價值，但也給企業的資料儲存、管理和分析工作帶來嚴峻挑戰。傳統儲存架構面對如此量級的資料，讀寫效能下降，儲存成本大幅增加，資料管理難度呈幾何倍數增長。
此外，隨著 GenAI 技術的成熟，企業亟需能夠高效儲存和分析文字、影像、音訊、影片等異構資料的新一代資料庫，要求其具備智慧化的儲存最佳化和即時計算能力。
更嚴峻的是，隨著企業全球化發展和資料價值挖掘需求的增長，跨雲資料整合面臨嚴峻挑戰。不同雲平臺間的資料格式和介面差異導致遷移工作複雜且成本高昂，不僅需要專業人力進行格式轉換和介面適配，還需承擔持續增加的網路傳輸費用。這些現實需求倒逼資料庫技術持續革新，這也是 OceanBase 打造“共享儲存”產品的根源所在。
回望 OceanBase 15 年的自主研發歷程，始終是市場需求驅動技術演進的最佳實踐者。
一直以來，OceanBase 始終踐行一體化的技術戰略。到目前為止，OceanBase 已經完成了兩次重大技術迭代，目前正邁向第三次架構升級：
第一次重大迭代是 2016 年釋出的 1.0 版本，該版本實現了所有節點的可讀可寫能力，突破了傳統分散式資料庫在讀寫許可權方面的限制，為 OceanBase 奠定了高可用、高併發的技術基礎。
第二次重大迭代是 2020 年釋出的 4.0 版本，當時 OceanBase 創新性地提出了“單機分散式一體化架構”，在一套系統中同時實現了分散式系統的擴充套件性和單機資料庫的功能與效能。這一突破性設計使得 OceanBase 被開發者社群親切地稱為“成年人的資料庫”——因為成年人不做選擇，既要分散式卓越的擴充套件效能，又要單機極致的事務處理能力。
而如今，OceanBase 正在進行第三次技術架構升級，重點構建多雲原生能力。這一升級包含三個關鍵方向：跨雲平臺的一致性體驗、跨雲高可用與容災能力、面向多雲的儲存計算分離架構。
這一演進將進一步增強 OceanBase 在複雜雲環境中的適應能力。
據 OceanBase CTO、AI 戰略一號位楊傳輝透露，OceanBase 還在持續耕耘 SQL+AI 的能力，包括自研向量引擎、混合檢索，以更好地應對 AI 時代資料處理的需求。
既然市場需求驅動了 OceanBase“共享儲存”產品的誕生，那這款產品有哪些特別之處？
據 OceanBase 產品部總經理楊志豐介紹，該產品的核心亮點包括：
-
面向海量資料的極致價效比，基於共享儲存的架構設計，使 OceanBase 在保持強一致性和事務效能的同時，實現海量資料場景下的極致價效比，儲存成本最高降低 50%。
-
面向 Serverless 的雲原生彈效能力，儲存和計算資源獨立彈性伸縮，按量付費。支援 Serverless 式的資源排程，實現儲存不動、計算可彈的能力。
-
多雲原生，全面支援 Amazon S3、阿里雲 OSS 等主流雲平臺及相容 S3 協議的物件儲存，為企業在多雲、混合雲環境下構建統一的資料基礎設施提供更多可能。
值得一提的是，這款產品和很多業內已有的共享儲存版本有一些差異。為了彌補物件儲存在延遲上的短板，OceanBase 構建了一套多層快取體系，透過冷熱分層 + 命中率最大化的設計，可把物件儲存的影響控制在最低限度。
它的整個架構分為三層：
底層是物件儲存基座層：相容 S3 介面，支援多雲物件儲存（如 AWS S3）及私有化部署方案（如 MinIO），用於儲存低頻訪問的大容量資料。
第二層是本地持久化快取層：獨立部署三副本日誌服務，提升訪問效率，解決物件儲存隨機讀慢的問題，並且這種單日誌服務可支撐多叢集執行，為共享儲存架構補上關鍵一環。
最上層是記憶體快取層：承載最熱點資料，確保關鍵事務毫秒級響應；支援靈活部署（如高可用場景 2 副本，普通場景 1 副本）。
OceanBase共享儲存產品演示圖
這樣設計最終取得的效果如何？
OceanBase 技術團隊針對典型分析處理（AP）場景進行了專項效能評測，包括 ClickBench、TPCH、TPC-DS 等業界標準基準測試。
測試結果顯示，在基於物件儲存的共享儲存架構下，OceanBase 的效能損耗控制在 0.3%～1.7% 的極低範圍內。相較於該架構在 AP 場景下帶來的顯著收益（包括儲存成本的大幅降低和彈性擴充套件能力的提升），這一微小的效能折損對於絕大多數業務場景而言都是完全可以接受的。
基於以上特點，這款共享儲存產品能解決什麼問題？
簡而言之，是為了解決 shared-nothing 架構在彈性和成本方面的瓶頸。
資料庫技術的演進始終與儲存介質革新緊密相連。從 HDD 到 SSD，再到 NVM，每次介質升級都推動了資料庫架構的創新，釋放出更大效能潛力。共享儲存架構允許多節點訪問同一儲存資源，雖節省空間並確保一致性，但面臨 I/O 爭用等瓶頸。
而物件儲存是一種新的資料儲存方法，它將資料儲存為“物件”，每個物件包含資料本身、與之相關的元資料以及唯一的識別符號，通常用於儲存大規模非結構化資料，例如影像、音訊、影片、文件和日誌檔案等，因其高可靠、低成本、可無限擴充套件等特性，在雲計算快速發展的今天，被廣泛應用於企業儲存備份、歸檔和資料湖等場景。
然而，在事務型資料庫（TP）的生產資料場景中，物件儲存一直未被普及。
這背後的原因，並非是物件儲存技術不成熟，而是在於主流資料庫對低延遲、高效能有極致追求，普遍採用緊耦合的存算一體架構，因此依賴本地磁碟或雲盤，無法支援物件儲存的應用。這一情況下，雖然資料庫的交易效能得到保障，但也帶來了雲上擴縮容不靈活、儲存冗餘度高且成本過高等問題。
而 OceanBase 這款產品，正是在效能無損的同時，開創性實現了對物件儲存與 TP 業務的深度整合。
事實上，物件儲存並不是什麼新鮮事，業界已有眾多支援多雲架構的面向物件儲存的資料庫解決方案，但遺憾的是，它們更多停留在 HTAP、備份、冷資料場景中， 一直未被應用於 TP 資料庫的生產場景中。
以知名的 Snowflake 為例，它雖然支援 OLAP 場景，卻因難以實現低延遲和即時寫入無法滿足 OLTP 需求。
OceanBase 之所以能實現基於物件儲存並將其落地在 OLTP 生產環境中，背後依賴的是深度的技術創新和極高的工程複雜度。
首先，是快取架構上的創新。OceanBase 透過構建多級快取架構解決了效能問題，包括記憶體快取、本地持久化快取、分散式快取和物件儲存四層，專為 TP 場景設計。
在傳統 shared-nothing 架構中，熱點資料主要依賴記憶體快取。在 share storage 共享儲存產品下，OceanBase 增加了本地持久化快取 + 分散式快取，有效承接物件儲存的訪問延遲問題。無論是快取物件儲存讀出的資料、預讀預熱機制，還是快取資料在節點間的資料同步機制，均確保了 TP、AP、KV 多種負載下的效能與容災恢復能力（記憶體快取：承載最核心、最熱點的資料，本地快取 + 分散式快取：為共享儲存架構補上關鍵一環，物件儲存：無限容量的冷資料歸宿）。
其次，OceanBase 使用自研的基於物件儲存的 LSM-Tree 引擎，天然適配“只追加、不修改”的物件儲存特性，避免覆蓋寫，降低寫放大和衝突機率，提升 IOPS 利用效率。
同時，在物件儲存天然為大塊順序 I/O 最佳化、小 I/O 效能差且超過 1 萬 IOPS 容易被限流的前提下，OceanBase 透過聚合小 I/O、非同步寫入、讀寫路徑最佳化、併發控制等深度工程手段，極大緩解了 TP 場景下頻繁事務訪問對底層儲存帶來的壓力。
第三，OceanBase 透過獨有的持久化快取彈性伸縮能力，進一步解決了 TP 場景下熱點資料隨業務波動而動態變化的問題。相比業界普遍的固定快取策略，OceanBase 的本地快取空間可隨負載自動擴縮，保障高併發讀寫的同時降低資源成本。
此外，在日誌架構方面，OceanBase 也實現了重大重構。在原有 Share Nothing 三副本架構中，日誌服務分佈在每個副本內部，而在共享儲存產品中，OceanBase 將日誌服務單獨抽象出來，形成獨立的服務模組。這一設計不僅帶來了更穩定的日誌 I/O，還實現了日誌的跨叢集共享，進一步降低了儲存成本，提高了資源利用率，實現更好的效能、更好的彈性和更低的成本。
在 Serverless 架構方面，OceanBase 支援透過 Spot 節點顯著降低計算成本。以 AWS Lambda 的 Spot 實踐為例，最高可節省約 70% 的計算資源開銷。在架構設計上，OceanBase 將 Compaction、DDL、備份恢復等重 I/O 操作拆分為非同步後臺任務，計算節點保持本地無狀態，從而具備更強的自動彈性與跨叢集排程能力，真正實現從架構層面對雲原生的深入適配。
最後，OceanBase 對物件儲存的訪問鏈路進行了全鏈路的適配和最佳化——從 I/O 排程機制、快取命中率、預取策略，到跨可用區的副本同步機制，全面壓低延遲波動。即使面對毫秒級響應壓力的 OLTP 業務，依然可以保持穩定的事務執行能力。
正是這些技術難點的逐一突破、這些工程能力的系統構建，使 OceanBase 成為目前業內唯一能夠在 OLTP 場景下穩定執行物件儲存的雲資料庫。
在 TP 負載下，OceanBase 共享儲存產品在保障強一致性的同時，儲存成本降至原有的 1/2；在 AP、AI 及多模相關負載下，支援大規模分析和離線任務的同時，儲存成本最高降低至原來的 1/10，打造面向海量資料的一體化資料底座。
楊志豐表示，OceanBase 共享儲存產品在雲上可被應用於多種典型業務場景，尤其適合海量資料、冷熱資料特徵明顯、對成本敏感的業務場景，包括典型 TP、歷史庫及備份庫，時序類業務、HBase 相容類業務、流水型業務系統、OLAP 業務等。具體來說：
在典型 TP、歷史庫及備份庫等場景中，可透過將熱資料快取 SSD、全量資料存物件儲存，在降低儲存成本的同時確保歷史資料查詢效能。
在時序類業務中，典型的特徵是資料隨著時間熱度遞減，包含但不限於 IoT、智慧製造、智慧出行等場景，例如智慧電動車、電動腳踏車、智慧樓宇系統等會定期上傳大量裝置監控資料。這些資料通常寫入頻繁，但查詢主要集中在短期內，具備明顯的熱度衰減特徵。共享儲存結合自動冷熱識別與本地熱資料快取機制，既保障了寫入效能，也控制了長期儲存成本。
在 HBase 相容類場景中，在提供冷熱分離能力的基礎上強化事務處理與一致性保障，為 KV 業務提供平滑遷移方案。
在流水型業務系統中，透過智慧快取機制滿足高頻寫入、短期查詢和長期留存需求。
技術總要回歸到商業本質。楊志豐表示：“在 AGI 時代，這款產品對大模型應用開發的核心價值在於：透過創新的共享儲存架構，實現了海量資料的高效管理與成本最佳化，為 AI 時代的資料處理需求提供了可擴充套件、高性價比的解決方案。”
同時，楊志豐判斷，將有越來越多的廠商開始研發基於物件儲存的事務處理（TP）資料庫系統，特別是分散式 TP 資料庫領域。他的判斷主要基於兩點：
從行業示範效應來看，OceanBase 實踐並驗證了這一技術路線的可行性，能為業界提供了可參考的案例。目前，這款共享儲存產品在 OceanBase 內部測試的各項效能指標都表現優異，更加增強了 OceanBase 對這一技術路線落地的信心。
從行業認知層面看，以往很多從業者並非沒有想到這個方向，只是對實際落地效果存疑。隨著 OceanBase 的這次成功實踐，這種疑慮或許能夠消除。
畢竟，總有人要先吃螃蟹。