演講實錄 | 楊傳輝：AI 時代，OceanBase 帶來了哪些產(chǎn)品革新？

編者按

11 月 18 日，2025 OceanBase 年度發(fā)布會在北京舉行。現(xiàn)場發(fā)布并開源了 OceanBase 首款 AI 原生混合搜索數(shù)據(jù)庫 seekdb（簡稱 seekdb ）。作為 OceanBase “Data x AI”戰(zhàn)略的關鍵一環(huán)，OceanBase 4.4 一體化融合版本也正式發(fā)布。

在之后的分享中，OceanBase CTO 楊傳輝以“OceanBase：打造 AI 時代的一體化數(shù)據(jù)庫”為題，介紹了 OceanBase 在 AI 時代的產(chǎn)品革新和演進。他表示，在 AI 時代，一體化架構所承載的核心技術能力，只會愈發(fā)重要。在他看來，向量搜索是 AI 數(shù)據(jù)庫的初級階段，而最終，所有向量搜索都會逐步演進為混合搜索 —— 能否支持混合搜索，正是衡量 AI 數(shù)據(jù)庫核心實力的關鍵分水嶺。

以下為演講實錄：

各位來賓、數(shù)據(jù)庫領域的新老朋友，大家上午好。剛剛我們正式發(fā)布并開源了 OceanBase 首款 AI 原生混合搜索數(shù)據(jù)庫 seekdb，也提到了混合搜索這一核心方向。今天我的分享，同樣圍繞 AI 展開，主題是 “打造 AI 時代的一體化數(shù)據(jù)庫”。

相信不少嘉賓在展區(qū)已經(jīng)感受到，這次發(fā)布會和以往有明顯不同 —— 我們帶來了大量 AI 相關的新產(chǎn)品。所以今天的分享，我不會聚焦 TP 或分析 AP，核心想和大家聊聊我們對 AI 時代、混合搜索與 seekdb 的思考，以及近期的開發(fā)進展。

AI時代一體化數(shù)據(jù)庫的變與不變

首先，我們不妨回顧一下數(shù)據(jù)庫技術范式的演進。數(shù)據(jù)庫技術奠基人之一 E.F.Codd 于 1970 年提出關系模型，當時這一模型主要面向交易場景；1993 年，他又提出了面向分析的 OLAP。而最近幾年，業(yè)界涌現(xiàn)的所有新數(shù)據(jù)庫產(chǎn)品，本質(zhì)上都是面向 AI 的 —— 既包括大家熟悉的各類向量數(shù)據(jù)庫，也涵蓋 Supabase等 熱門產(chǎn)品。不難發(fā)現(xiàn)，整個數(shù)據(jù)庫領域的技術范式，正從原本的支撐應用服務，逐步延伸到智能服務的全新階段。

我們注意到，Oracle、MongoDB 等業(yè)界主流數(shù)據(jù)庫，也正紛紛在自身引擎中新增搜索能力，以此適配 AI 原生場景的需求。在 AI 領域有個常見概念叫 AI Ready，而我們認為，AI Ready 必然會向 AI Native 逐步演進。所謂 AI Native，絕非僅做好數(shù)據(jù)準備那么簡單，核心是將模型能力深度集成到數(shù)據(jù)庫中，最終實現(xiàn)數(shù)據(jù)與模型在數(shù)據(jù)庫內(nèi)的原生融合。近期行業(yè)內(nèi)的多起收購事件也印證了這一趨勢 ——MongoDB 收購 Voyage AI、Elastic 收購 Jina AI，核心訴求都是推動數(shù)據(jù)與模型的融合，我們高度認同這一行業(yè)趨勢。

AI 時代的到來，既給數(shù)據(jù)庫領域帶來了巨大挑戰(zhàn)，更孕育著前所未有的發(fā)展機遇。

首先，AI 時代的數(shù)據(jù)庫，數(shù)據(jù)處理量會持續(xù)激增，用戶與租戶規(guī)模也將迎來量級式增長。與此同時，AI 還會給數(shù)據(jù)庫帶來全新的工作負載 —— 我們將其定義為“面向 Agent 的多路混合搜索”。

在 AI 時代，數(shù)據(jù)庫的處理范疇不再局限于結構化數(shù)據(jù)與少量半結構化數(shù)據(jù)，還需要承載更多半結構化乃至無結構化數(shù)據(jù)。這意味著，除了傳統(tǒng)關系模型，數(shù)據(jù)庫還需支持 JSON 處理半結構化數(shù)據(jù)，并為無結構化數(shù)據(jù)構建各類語義索引，比如大家熟知的向量索引、圖索引、全文索引等。在此基礎上，我們更需要一套能覆蓋結構化、半結構化、無結構化數(shù)據(jù)的混合搜索能力。

AI 還帶來了顯著的技術平權效應。過去，數(shù)據(jù)庫主要由專業(yè)人士通過開發(fā)應用程序來使用，而在今天的 AI 時代，即便沒有計算機相關背景，普通人也能借助大模型輕松開發(fā)自己的 Agent。這也意味著，未來數(shù)據(jù)庫的用戶量與租戶數(shù)量，必將實現(xiàn)倍數(shù)級的爆發(fā)式增長。

聊完了 AI 時代數(shù)據(jù)庫的變化，我們更要明確數(shù)據(jù)庫的變與不變。其中一點我堅信不疑：數(shù)據(jù)庫領域不僅不會被取代，在 AI 時代還會變得愈發(fā)重要。

無論 AI 如何迭代演進，數(shù)據(jù)庫的核心基礎能力始終不可或缺：我們?nèi)孕枰煽康臄?shù)據(jù)庫引擎，解決單機、分布式及多云平臺的各類問題；仍需要行存數(shù)據(jù)庫支撐交易場景，列存數(shù)據(jù)庫處理分析需求，更需要強大的 SQL 優(yōu)化器應對 HTAP 混合負載。同時，數(shù)據(jù)庫還需提供豐富的 SQL 功能，助力大家平滑完成從 MySQL、Oracle 等系統(tǒng)的升級。

混合搜索是 AI 數(shù)據(jù)庫的關鍵分水嶺

在 AI 時代，一體化架構所承載的核心技術能力，只會愈發(fā)重要。一提到 AI 數(shù)據(jù)庫，很多人首先想到的是向量搜索，但在我看來，向量搜索只是 AI 數(shù)據(jù)庫的初級階段。最終，所有向量搜索都會逐步演進為混合搜索 —— 能否支持混合搜索，正是衡量 AI 數(shù)據(jù)庫核心實力的關鍵分水嶺。

大家都知道，大模型具備強大的計算能力，但缺乏長期記憶。這就需要數(shù)據(jù)庫為大模型提供支撐：存儲并管理其上下文信息，同時精準輸出大模型所需的上下文。這個過程，也被稱為 “上下文工程”。要做好“上下文工程”，首先需要通過向量搜索、向量嵌入解決 “找相似” 的問題。但 “找相似” 只是上下文工程的一部分，除此之外，還可能需要通過全文搜索實現(xiàn) “找相同”，或借助知識圖譜與圖索引，挖掘全局相關的信息。

“上下文工程”往往還涉及大量元數(shù)據(jù)管理，這就需要依托關系型數(shù)據(jù)庫的能力 —— 通過關系過濾、關系查找縮小檢索范圍。每一路檢索都會產(chǎn)出部分結果，最終要將各路結果融合，并經(jīng)過全局重排序(rerank)，才能為大模型輸出其真正需要的精準結果。這正是混合檢索的核心邏輯。

首先，高性能且功能完備的向量搜索，是多路混合搜索的核心基礎。目前，OceanBase 向量搜索性能已達到業(yè)界開源向量數(shù)據(jù)庫的最優(yōu)水平—— 無論是稠密向量還是稀疏向量，在向量數(shù)據(jù)庫領域主流 benchmark 測試中均表現(xiàn)突出。同時，我們的磁盤向量索引，在構建時間與存儲占用兩方面，也實現(xiàn)了業(yè)界領先。

具備強大的向量搜索能力后，我們進一步實現(xiàn)了向量搜索與全文搜索的深度融合，通過多路搜索顯著提升召回效果。

左側圖示清晰呈現(xiàn)了不同搜索方式的召回表現(xiàn)：僅采用單一搜索路徑（無論全文搜索、稠密向量還是稀疏向量），都難以達到最優(yōu)召回效果；唯有將稀疏向量、稠密向量與全文搜索相結合，才能實現(xiàn)更優(yōu)的召回表現(xiàn)，達成 1+1 大于 2 的協(xié)同效應。

值得一提的是，OceanBase 不僅擁有上述高性能向量搜索能力，還已落地生產(chǎn)級全文搜索功能。更重要的是，這兩大能力均構建于 OceanBase 數(shù)據(jù)庫原生架構之上，天然繼承了分布式架構的彈性擴展特性與對象存儲的高效適配能力。

在 AI 場景中，除了要開展多路搜索，還需妥善管理 AI 場景下的元數(shù)據(jù)。要做好 AI 數(shù)據(jù)庫的元數(shù)據(jù)管理，不僅需要支持元數(shù)據(jù)的實時寫入與事務一致性，還需實現(xiàn)元數(shù)據(jù)檢索結果與多路搜索結果的 SQL 級聯(lián)動。毫無疑問，支持 HTAP 的關系型數(shù)據(jù)庫是更優(yōu)選擇。通過將關系模型與向量、全文、JSON 能力深度融合，OceanBase 最終形成了全面的混合搜索能力。

下面我簡單分享幾個 OceanBase 混合檢索的客戶實踐案例：

貨拉拉基于 OceanBase 混合檢索，搭建了一站式企業(yè) AI 數(shù)據(jù)底座。貨拉拉的 AI 應用場景十分豐富，涵蓋知識庫、AI Coding、Agent 平臺、ChatBI 等。此前，他們曾使用多款不同產(chǎn)品，包括搜索產(chǎn)品 V search 及兩款不同的向量數(shù)據(jù)庫；升級至 OceanBase 后，實現(xiàn)了多產(chǎn)品合一，不僅解決了原有開源組件的穩(wěn)定性問題，還直接復用 OceanBase 的高可用能力，達成 RPO=0、RTO＜8 秒的高標準。

聯(lián)通也是借助 OceanBase 的混合搜索能力，構建了公司級統(tǒng)一知識庫平臺，該場景此前采用 “關系數(shù)據(jù)庫 + 全文向量搜索數(shù)據(jù)庫” 的架構。將兩者融合至 OceanBase 后，在 10 億級向量規(guī)模下，OceanBase 的處理效率達到原全文向量搜索數(shù)據(jù)庫的兩倍以上；同時通過融合關系查找與多路搜索，成功解決了知識庫的元數(shù)據(jù)管理難題，包括精細化權限管控及靈活的用戶間權限共享需求。

螞蟻百寶箱基于混合搜索實現(xiàn)了智能體在線搜索。此前他們曾使用向量數(shù)據(jù)庫、搜索產(chǎn)品及 OceanBase 本身分別管理不同數(shù)據(jù)，最終全部融合至一套 OceanBase 后，不僅幫助客戶統(tǒng)一了技術棧，還將業(yè)務層的多產(chǎn)品融合搜索能力下沉至數(shù)據(jù)庫層，極大簡化了數(shù)據(jù)架構。

AI 時代需要怎樣的數(shù)據(jù)架構？

實現(xiàn) AI 場景下的混合搜索，主要有兩種路徑：

第一種實現(xiàn)方式是從頭開始搭建一個混合搜索的數(shù)據(jù)庫；第二種方式是直接基于關系數(shù)據(jù)庫增加混合搜索的功能。

在我看來，第二種路徑更具優(yōu)勢，核心原因有兩點：1.關系型數(shù)據(jù)庫不管是在功能完備性、易用性還是生態(tài)成熟度上，均遠超其他非關系型數(shù)據(jù)庫；2.支撐 AI 場景，除了要有混合搜索能力，底層還需一套現(xiàn)代數(shù)據(jù)架構。

以 OceanBase 為代表的關系型數(shù)據(jù)庫，已具備成熟的現(xiàn)代數(shù)據(jù)架構 —— 這種架構技術壁壘高，也是 AI 時代數(shù)據(jù)庫的 Foundation。

那么什么是現(xiàn)代數(shù)據(jù)架構？我認為核心包含三個點：

第一個點：現(xiàn)代數(shù)據(jù)架構一定是非常好用的；

第二個點：現(xiàn)代數(shù)據(jù)架構一定是非常靈活的；

第三個點：一定是面向未來能夠支撐 AI 的。

現(xiàn)代數(shù)據(jù)架構的底層核心是一體化架構，用戶想要什么功能，數(shù)據(jù)庫就提供相應的功能，無需根據(jù)功能的不同而選擇不同的存儲產(chǎn)品、學習不同的技術棧。現(xiàn)在的數(shù)據(jù)庫架構非常靈活，在部署模式上，用戶可自由選擇上云、不上云或特定云平臺。

同時，現(xiàn)代數(shù)據(jù)架構也需要能夠支持按需使用。數(shù)據(jù)量小時用小規(guī)格部署，數(shù)據(jù)量增長后無縫擴容，完美適配從初創(chuàng)到規(guī)模化的全階段需求。

更關鍵的是，現(xiàn)代數(shù)據(jù)架構需原生支持 AI 場景。除了前文提到的混合搜索能力，原生多租戶能力也至關重要 —— 因為 AI 時代，數(shù)據(jù)庫的使用者早已不局限于 DBA 或計算機專業(yè)開發(fā)人員，每一個普通人都能通過大模型輕松構建自己的 AI Agent。

一體化架構的核心，我將其總結為 “三多”：多負載、多模態(tài)、混合多云。

• 多負載：一套數(shù)據(jù)庫引擎即可全面支持交易、分析、AI 等各類工作負載；

• 多模態(tài)：兼容多樣化數(shù)據(jù)類型與索引 —— 既涵蓋結構化數(shù)據(jù)的關系模型、半結構化數(shù)據(jù)的 JSON 格式，也支持無結構化數(shù)據(jù)的各類語義索引，比如向量、全文、圖索引等；

• 混合多云：賦予用戶完全的部署自由，可自主選擇上云、不上云或特定云平臺。更關鍵的是，用戶只需使用一套產(chǎn)品，就能實現(xiàn)跨所有公有云、混合云平臺的自動升級，無需額外適配。

目前，OB Cloud 已成為業(yè)界支持公有云平臺最多的云數(shù)據(jù)庫產(chǎn)品，已兼容 7 朵主流云：國內(nèi)涵蓋阿里云、華為云、騰訊云、百度云四大平臺，海外覆蓋 AWS、Azure、GCP 三大平臺。我們的 OB Cloud 已落地 16 個國家和地區(qū)，覆蓋超 60 個地域、240 多個可用區(qū)，無論你身處全球哪個角落、哪個時區(qū)，都能便捷獲取 OB Cloud 一體化云數(shù)據(jù)庫。

同時，依托一體化架構，我們實現(xiàn)了多云及混合云環(huán)境下的用戶體驗一致性，更支持跨云高可用能力。當用戶需要跨云升級時，OceanBase 可全程保障業(yè)務連續(xù)性，確保升級過程中業(yè)務不中斷。

AI 場景的工作負載具有極強的不確定性。AI Agent 這個生態(tài)雖然數(shù)量眾多，但多數(shù)都默默無聞，僅有少數(shù)會迎來爆發(fā)式流量，且這類流量往往具備突發(fā)特性。因此，我們必須提供支持彈性伸縮架構的 Serverless 方案，以靈活應對流量波動。

此外，AI 場景需要管理海量數(shù)據(jù) —— 包含大量長上下文數(shù)據(jù)，既有文本類型，也有多模態(tài)類型。這些數(shù)據(jù)中，大部分屬于冷數(shù)據(jù)，僅近期高頻訪問、用戶重點關注的數(shù)據(jù)為熱數(shù)據(jù)。基于此，我們通過支持對象存儲的冷熱分離方案，高效解決海量數(shù)據(jù)的存儲與管理難題。

螞蟻集團也正基于 OceanBase 開展大模型預訓練工作。為做好大模型預訓練，螞蟻需要將海量網(wǎng)頁內(nèi)容提取至內(nèi)部，再進行網(wǎng)頁的數(shù)據(jù)清洗與標注。這些網(wǎng)頁數(shù)據(jù)中，大部分屬于冷數(shù)據(jù)，但仍有部分網(wǎng)頁更新頻繁，因此我們通過基于對象存儲的冷熱分離方案，高效適配這一需求；同時，數(shù)據(jù)清洗與標注場景的流量具有明顯突發(fā)性 ，當一批網(wǎng)頁數(shù)據(jù)集中涌入時，需要動態(tài)調(diào)度計算資源實現(xiàn)彈性處理，而在這一過程中，就需要用到 OceanBase 的 Serverless 方案。

數(shù)模融合，一個正在被驗證的趨勢

我認為，數(shù)據(jù)與模型的深度融合，必將是未來的核心趨勢。在數(shù)據(jù)庫內(nèi)直接集成模型能力，能大幅降低模型開發(fā)與使用的復雜度。

以我們的混合搜索為例：當文檔進入數(shù)據(jù)庫內(nèi)部后，除了進行數(shù)據(jù)處理外，也需要對文檔做切片、解析、embedding，以及多路搜索。這一過程既用到數(shù)據(jù)處理能力，也集成了模型服務能力，包括 Parse 解析模型、embedding 模型、Rerank 模型等。

為此，OceanBase 支持了“Document in, Data out”，用戶只需將文檔寫入數(shù)據(jù)庫，通過混合搜索，就能一步獲取所需結果，真正實現(xiàn)開箱即用。相比傳統(tǒng)開發(fā)模式 —— 我們需自行尋找各類模型與組件，反復實驗拼湊，有了“Document in, Data out”，用戶真正能開箱即用，大幅降低了 AI 應用的開發(fā)復雜度。

當數(shù)據(jù)庫集成了模型服務之后，OceanBase 也同時提供了 MaaS 平臺。所謂的 MaaS 就是 Model As a Service，提供了后訓練到在線推理服務的全流程管理。MaaS 平臺支持微調(diào)等后訓練，我們也支持對模型做量化，也支持做推理的加速、模型的評測，以及各種算力的調(diào)度、模型的管理等。如今，OceanBase 的 MaaS 平臺已經(jīng)支持了業(yè)界不同場景主流的大語言模型，包括海外和國產(chǎn) GPU。

AI 原生數(shù)據(jù)庫的設計，必然要秉持開源、開放的核心理念。剛才我們已經(jīng)正式發(fā)布了 OceanBase 首款 AI 原生混合搜索數(shù)據(jù)庫 seekdb——基于 Apache2.0 協(xié)議的 AI 原生混合數(shù)據(jù)庫，主要有以下核心能力與優(yōu)勢如下：

首先，seekdb 支持多模混合搜索，僅需一條查詢，就能同時檢索關系、JSON、向量、全文等多種類型的數(shù)據(jù)；其次，它內(nèi)置 AI Function 功能。因構筑于 OceanBase 原生架構之上，所以它也天然繼承了 OceanBase 原生的能力，包括 HTAP混合負載處理、MySQL 高度兼容等能力。

可能有朋友會問，seekdb 是不是 OceanBase 的輕量版？答案是，兩者并不同。它遠比輕量版更輕, 輕上加輕。此前 OceanBase 輕量版最低配置為 2C 8G，而 seekdb 首個版本已支持 1C2G ，未來還會把它的內(nèi)存需求進一步降低至 1G 甚至 500M。這意味著，seekdb 不僅能部署在臺式機、桌面端，未來更可適配各類嵌入式環(huán)境。

seekdb 是基于 Apache 2.0 協(xié)議的開源產(chǎn)品，我們希望與業(yè)界開發(fā)者共同探索，到底什么才是真正的 AI 原生數(shù)據(jù)庫。因為有了業(yè)界開發(fā)者的參與，我相信，seekdb 的迭代速度也必將大幅提升。同時， OceanBase在 AI 的能力上將會跟進 seekdb 能力演進，為大規(guī)模、超大型 AI 應用提供落地能力和支撐。歡迎大家訪問 OceanBase seekdb 的官方網(wǎng)站—— oceanbase.ai，也誠摯邀請現(xiàn)場及線上的開發(fā)者們加入 OceanBase seekdb 的開源社區(qū)共建開放生態(tài)。

OceanBase seekdb 是一款專為開發(fā)者打造的 AI 原生數(shù)據(jù)庫，只需三行代碼，就能快速構建應用，實現(xiàn)關系、JSON、向量、全文的混合搜索。這里給大家舉一個簡單的例子：

第一步，創(chuàng)建一個集合；第二步，在集合中添加文檔，并且可靈活指定文檔的元數(shù)據(jù)；第三步，直接使用 OceanBase 的混合搜索接口，直接獲取最終結果。

今天，我們也正式開源了 OceanBase 的 PowerRAG 產(chǎn)品。PowerRAG 被認為是 OceanBase 基于混合搜索的最佳實踐。PowerRAG 在 RAGFlow 的框架之上構建，有兩個特點。第一個特點，是基于混合搜索做的重新設計；第二個特點，該產(chǎn)品已在螞蟻集團內(nèi)部真實業(yè)務場景中落地應用，具備成熟的企業(yè)級能力。PowerRAG 文檔解析、處理能力，以及最終召回的效果，是具備企業(yè)級能力的，要好于業(yè)界已有的 RAG 解決方案。

同時，今天我們也正式發(fā)布并且開源 PowerMem 解決方案， PowerMem 和 PowerRAG 一樣，也是基于混合搜索的一個解決方案。它兼容 Mem0 接口，幫助開發(fā)者、用戶去管理大語言模型的上下文。同時，PowerMem 的性能在 LOCOMO Berchmark 里達到了業(yè)界開源 Memory 解決方案的 SOTA 水平（State of the Art），歡迎在座的朋友以及線上的開發(fā)者關注和加入 OceanBase 的 PowerRAG 以及 PowerMem 開源社區(qū)。

今天是 seekdb 是發(fā)布的第一天，我們已經(jīng)和業(yè)界產(chǎn)品進行了生態(tài)對接。這里面既包括全球知名的產(chǎn)品 Dify、Qoder，也包括 AI 領域的創(chuàng)業(yè)公司。當然，我相信這些創(chuàng)業(yè)公司在剛開始的時候就選擇 OceanBase 這樣一個能夠解決增長問題的產(chǎn)品，他們未來的增長也一定會有更多的可能。

未來，我相信所有數(shù)據(jù)類的產(chǎn)品都會用 AI 的方式重新改造一遍。ODC 是 OceanBase 面向開發(fā)者的工具，ODC 正式推出 DataPilot。對于 ODC 而言，大家都非常熟悉它的自然語言轉化為 SQL，Text2SQL 的功能。但是，如果采用業(yè)界經(jīng)典的 Text2SQL 的解決方案，會面臨一個很大的問題，那就是準確率永遠都沒有辦法滿足業(yè)務的需求。

Text2SQL 領域有個權威榜單 BIRD-bench，行業(yè)內(nèi)普遍認為，該榜單得分達到 80 分左右后，再想突破就十分困難。而 OceanBase 創(chuàng)新性地采用了 Text2Metrics 解決方案：我們先定義統(tǒng)一指標，對領域術語進行標準化規(guī)范，再通過這些指標約束大語言模型的生成范圍。通過這一方式，我們將自然語言到 SQL 的轉化準確率提升至 90 分以上 —— 目前已達到 92.2%，且在特定業(yè)務場景下，準確率仍有進一步提升空間。要知道，只有達到 90 分以上乃至更高的準確率，自然語言轉 SQL 技術才能真正落地生產(chǎn)系統(tǒng)，具備實實在在的業(yè)務價值。

我們還采用 Agentic AI 理念，對診斷監(jiān)控產(chǎn)品 OAS 進行了全新設計。具體來說，我們采用 Agentic AI Multi-Agent 架構，它有一個主 Agent 負責核心的任務拆解與分配，再將不同細分任務精準下發(fā)給對應的專項 Agent 執(zhí)行 —— 這個架構相信很多在場嘉賓都非常熟悉。通過這一升級，OAS 實現(xiàn)了從查指標、找問題到對話即診斷的跨越。用戶只需通過自然對話，就能全程完成診斷流程，系統(tǒng)還會一步步呈現(xiàn)診斷過程中的詳細信息。這既方便開發(fā)者人工介入干預，也讓 OAS 真正具備了在生產(chǎn)系統(tǒng)中落地應用的實用價值。

今天我們也正式發(fā)布了OceanBase AI Stack 智能一體機。OceanBase 智能一體機最核心的組件是 OceanBase 的一體化架構，支持多模混合搜索的數(shù)據(jù)庫。數(shù)據(jù)庫之上，我們集成了 PowerRAG、Agent 開發(fā)平臺，以及 OceanBase 數(shù)據(jù)領域的 Agent —— 包括之前提到的 ODC DataPilot、基于 Agentic AI 改造的 OAS 等。數(shù)據(jù)庫之下則搭載了 MaaS 平臺，可靈活支持各類模型與算力部署。

OceanBase AI 智能一體機有兩大特點：第一是功能全面覆蓋，從底層的算力，海外或者國產(chǎn)算力支持，到模型、數(shù)據(jù)、RAG，到 Agent 開發(fā)，再到數(shù)據(jù)領域智能體，能完整覆蓋企業(yè)從數(shù)據(jù)底座搭建到 AI 應用開發(fā)的全生命周期需求；第二個特點，就是超高性價比，它定價親民，無需高昂成本，企業(yè)就能直接擁有 OceanBase 這套完善的端到端解決方案。

最后，我們還是回到 OceanBase 的內(nèi)核，我們看看這一次 OceanBase 的內(nèi)核，到底帶來哪些全新的能力？

OceanBase 4.4 版本是面向混合負載的 TP/AP 融合及向量增強 LTS 版本，它融合了 OceanBase 4.2.5 LTS 的 OLTP 能力與 OceanBase 4.3.5 LTS 的 AP 及向量能力，能夠同時兼顧核心系統(tǒng)以及多元化業(yè)務系統(tǒng)對數(shù)據(jù)庫的需求。

在 OLTP 的性能方面，OceanBase4.4 版本相比 4.2.5 有了進一步的提升，有大量主鍵沖突的場景，性能提升 15% 到 42%，回表場景的性能提升 5.7% 到 9.5%，PL 性能提升會更加明顯，對于 UDF 執(zhí)行的性能是提升了 2.3 倍，循環(huán)計算的性能提供了 4 倍，動態(tài)語句的處理性能提升了 3.6 倍，AP 的性能也提到了進一步的提升。相比 4.3.5 LTS，它的數(shù)據(jù)導入性能在 ClickBench 這個場景提升 37%，實時分析性能對于 ClickBench 提升 4%，TPC-H 提升 10%，TPC-DS 提升 13.7%，向量索引的性能也是得到進一步的提升。

向量索引總共有兩種索引方式，IVF 和 HNSW。IVF 的索引提升 15%，HNSW 的性能提升 4%-32%。同時在向量索引上，也針對 ARM 架構進行大量的優(yōu)化，在 ARM 架構，性能有倍數(shù)的提升。

OceanBase 4.4 版本的內(nèi)核能力也做進一步增強。它具備更強的安全能力以及 Oracle 的兼容能力。OceanBase 4.4 版本不僅支持全密態(tài)數(shù)據(jù)庫，還支持聯(lián)邦查詢和數(shù)據(jù)湖的融合，能夠幫助企業(yè)，尤其是金融與政企行業(yè)企業(yè)打通數(shù)據(jù)孤島。

OceanBase 4.4 版本同時支持存算一體架構，以及公有云上的存儲計算分離部署模式，適配多樣化部署需求。更值得關注的是，該版本新增了一項核心能力 —— 實時增量物化視圖。這一功能大幅強化了 OceanBase 的 HTAP 實力：讓一套引擎既能穩(wěn)定支撐 OLTP 核心交易處理，又能通過動態(tài)實時的增量物化視圖，實現(xiàn)多維度的實時分析，實現(xiàn)真正的 HTAP。

結語

各位嘉賓、朋友，AI 時代的浪潮已然來臨。無論你是企業(yè)管理者，還是深耕技術的同行，大家都在思考：如何真正把 AI 用好、用深、用在業(yè)務里。在這樣的背景下，一個開放、靈活、具備多模與混合搜索能力的數(shù)據(jù)庫，正成為企業(yè)邁向 AI 的關鍵基礎。它能幫你高效管理企業(yè)數(shù)據(jù)，更能將數(shù)據(jù)能力與 AI 能力深度融入業(yè)務流程，讓 Data 與 AI 真正落地生根，為業(yè)務創(chuàng)造實實在在的價值。

這就是我的分享，感謝大家一直以來對 OceanBase 持續(xù)的支持。謝謝！

更多企業(yè)的應用實踐，大會中的精彩回放和資料