1. 为什么说 26ai 不是一次常规版本升级最近不少搞数据架构的朋友都在翻 Oracle 26ai 的资料我手里这套用 35 张架构图讲 Oracle AI Database 26ai 技术架构的图册也被不少人传过。老实说我第一次看到版本号从 23ai 跳到 26ai 时第一反应是大概又在云上加了几个 AI 功能给自治数据库补点新特性然后再换一个名字。等我把 35 张图一张张过完才意识到这代产品改的不只是功能清单而是数据库本身的定位。26ai 这个名字可以拆成两段理解26 对应产品发布的时间节奏延续云数据库每年一个大版本的做法ai 则是明确告诉你这一代把 AI 当作数据库的一等公民来设计。注意这里说的不是数据库旁边加一个 AI 服务而是把 AI 相关的数据形态、计算方式、推理流程直接塞进数据库内核。说直白一点以前做智能应用普遍是数据库存数据外面再用 Python、向量库、模型服务拼一条流水线。26ai 想做的事是让数据库自己理解向量、自己执行推理调用、自己管理模型生命周期甚至让优化器在规划 SQL 执行计划时把是否走向量索引也当成一个普通的成本选项。这篇文章是上篇核心任务只有一个带大家按图纸顺序把前 20 张图逐组过一遍。我之所以坚持按图序讲是因为整套架构图分了几个层次先看全局定位与部署形态再看存储与查询内核最后才是 AI 平台与自治运维。前 20 张把数据库这个底座讲透后面的模型接入、安全策略和多云扩展放到下篇单独展开更合适。你可以把这篇文章当成一份看图笔记。我不会把 35 张图的内容全部复述一遍而是挑每张图里真正影响架构决策的细节把背后的为什么讲清楚。适合正在做数据库选型、准备把业务改造成 AI 原生应用、或者单纯想理解现代数据库往哪里走的读者。哪怕你暂时没有用 Oracle 的计划里面关于向量检索、融合查询、模型推理进数据库这些设计对其他数据库产品也有很强的参照价值。2. 35 张图的正确打开方式先抓住看图顺序2.1 先分清三组视角再开始逐张看图架构图最怕一上来就盯着某一张细节猛看结果被存储结构图上的小方块搞晕。我拿到这套图册后先做了一件事把图号写在便签上按内容分组。整套 35 张图大致可以分成三组视角第 1~5 张是全局视角讲产品定位、版本能力总览、部署形态以及数据库AI放在一起后的整体分层。第 6~16 张是内核视角围绕存储、内存、查询引擎、优化器展开这一组是上篇的重点。第 17~35 张是平台视角模型接入、推理路径、自治运维、安全与多云扩展。前两组的思路很清晰先回答数据库自己有什么变化再回答AI 能力以什么姿态进来。如果跳过存储和查询直接看模型接入你会误以为 26ai 只是给数据库套了一个模型网关那就把最核心的部分漏掉了。2.2 上篇图注速查表前 20 张图到底在讲什么我把上篇要讲的前 20 张图整理成了一张速查表方便你对照着看图号核心内容看图时重点关注1~2产品定位与版本能力总览26ai 强调AI 原生数据库而不是 AI 增强3~5部署形态与整体分层云、本地、混合架构下的组件边界6~7持久化存储与数据文件布局AI 数据类型如何与行存、列存共存8~10内存与列式存储、向量索引向量索引的构建与更新路径11~13融合查询引擎SQL、全文、向量、图查询如何统一14~16优化器与执行引擎向量相似度搜索怎么进成本模型17~18模型接入与推理路径模型注册、推理调用在数据库内部如何流转19~20自治运维与 AI 诊断系统如何用 AI 做故障预测和参数调优表格是个索引不是结论。后面每一节我会把其中真正的设计关键拆开说。2.3 看图时最容易踩的坑把逻辑架构当成物理拓扑看架构图有个常见误解以为图上的每个方框都对应一台服务器或一个进程。实际上这套图里的绝大部分是逻辑组件比如查询引擎、向量索引、模型推理服务它们可能运行在同一个数据库进程组里也可能分布在多个实例上具体取决于部署形态。你要是把逻辑架构当成物理拓扑就会问出融合查询引擎是不是单独部署了一个集群这种问题然后自己把自己绕晕。还有一个坑是忽略图的边界。很多图只画了 26ai 自己内部的东西模型服务可能来自外部大模型 API也可能来自你自建的推理服务。图上往往用一条虚线表示外部依赖有人没注意虚线边界以为数据库把私有化大模型也包进去了后面谈成本和安全的时候就会产生误判。3. 从存储与计算底座看起03-10 张图背后的设计逻辑3.1 AI 数据类型不是简单的新增一种字段图 6 到图 7 展示的是存储层的变化。过去的 Oracle 数据库有 NUMBER、VARCHAR2、CLOB、JSON 这些数据类型到了 23ai 引入了 VECTOR 类型26ai 在存储层把 VECTOR 相关的布局做得更系统化了。VECTOR 字段在逻辑上就是一个数组但物理存储要考虑的问题比想象中多是行存还是列存向量要压缩吗相似度计算时要读满整个向量还是可以做裁剪图 6 里画的数据文件布局我理解核心思路是向量的原始值和向量派生出的索引结构分开存放。原始值跟着主表走索引结构放进专门的索引段。这样做的直接好处是事务提交、回滚、备份恢复这些传统机制不需要为向量做颠覆性改造向量数据可以沿用数据库成熟的一致性保障。你不需要自己在应用层维护向量表和业务表的一致性这在以前用外部向量数据库时是个大麻烦。3.2 内存列式存储与向量索引的配合图 8 到图 10 连续三张实际上在讲同一个性能故事查询时数据从哪里来、索引怎么加速。In-Memory 列式存储已经不是新东西但在 AI 场景下它多了一个很重要的用途——批量向量相似度计算。行存适合点查询和事务处理但在从 1000 万条记录里找出跟某条向量最相似的前 10 条这种场景里行存的访问效率不如列存。列存把一列的数据紧凑地放在连续内存里CPU 可以顺序扫描再配合 SIMD 指令做距离计算吞吐量会好看很多。向量索引则是另一个加速手段。图 10 里给出了两条路径精确搜索走暴力扫描近似搜索走索引。注意这里的设计取舍数据库没有强制你必须建索引才能用向量搜索。对小数据量全表扫描配合列存完全够用数据量上来了可以选择 HNSW 这类近似索引。这个可选性很重要因为它意味着你不需要为了测试一个 Demo 就去建索引、调参数可以先用最简单的方式跑通业务再根据规模逐步上索引。3.3 为什么把向量索引进内核而不是旁边挂一个插件这是我在读图过程中觉得最值得展开的设计决策。市面上不少数据库选择把向量检索做成外部组件 回调的方式比如通过 FDW 或者自定义函数去调用独立向量库。26ai 图里的做法是让向量索引变成数据库的普通索引类型。这意味着什么代价和计划是统一建模的。优化器知道有向量索引存在它可以根据数据分布、查询条件、WHERE 过滤强度决定是直接走向量索引还是先用过滤条件缩小范围再算相似度还是干脆全表扫。不是每个查询都适合走向量索引比如你有 1000 万条数据但过滤条件能先把范围缩小到 100 条那直接算相似度可能更快。只有把向量索引放进优化器的成本模型里才能自动化地做这种判断。一致性也是统一管理的。向量索引随事务更新随备份备份随恢复恢复。你在外部向量库里写入了数据往往还要写一套同步任务遇到数据不一致半天排查不出来。放进内核之后这套复杂度被数据库吸收了对应用开发者来说是实打实的减负。4. 融合查询引擎11-16 张图里最值钱的设计4.1 SQL、向量、全文、图查询凭什么能揉在一起图 11 到图 13 展示的融合查询引擎是整个上篇里我最想让大家认真看的部分。传统认知里SQL 擅长结构化数据全文检索归搜索引擎管向量相似度是向量库的活图查询又属于图数据库。把这些揉到一个查询引擎里难点不只是都能用而是在一个 SQL 里能用。图上传递的信息是融合查询引擎以 SQL 为统一入口把不同类型的算子都实现成 SQL 表达能力的一部分。比如在 SELECT 子句里调用 VECTOR_DISTANCE 函数算相似度在 WHERE 里加一个全文 CONTAINS 条件在 ORDER BY 里同时按相似度和业务属性做排序。这听起来像语法糖但背后要实现的是统一的类型系统和执行计划。举个例子一个很典型的 RAG 场景用户要查性能好且评价接近某个描述的产品。传统做法是把结构化过滤价格、库存、全文检索评价文本、向量检索描述语义分开调用三个系统再在应用层做过滤、拼接、排序最后还得自己处理各个系统返回结果集的页码问题。融合查询引擎要做的是让这一整条链路在数据库内部完成应用只需要提交一条 SQL拿回一个结果集。4.2 混合搜索不是简单的取交集图 12 里专门有一块讲混合搜索Hybrid Search。我见过不少人对混合搜索的理解是把向量搜索结果和全文搜索结果做一个交集。真实情况复杂得多。语义搜索可能返回 A 结果关键词搜索返回 B 结果两者的相关性置信度不在一个量纲你怎么合并排序图上画了一条融合排序的路径先把各路的候选集都捞出来然后用一个可配置的权重公式做 RRFReciprocal Rank Fusion或者加权得分融合最后统一排序。这个细节说明产品团队很清楚混合检索的难点不在召回而在融合排序。权重怎么调、阈值怎么设都需要业务实测不是 SQL 写出来就能拿到好效果。4.3 优化器如何估算向量相似度成本图 14 到图 16 是优化器和执行引擎的内容。数据库优化器最擅长的是估算行数和代价但向量距离计算的代价模型与传统谓词完全不同。假设一个查询要算每个候选向量和目标向量的余弦相似度然后再取 top 10优化器需要估算的是候选集多大每条向量的维度多高走 HNSW 索引的 IO 成本是多少如果同时有文本过滤条件过滤率大概是多少图上这几个参数我理解分别对应数据分布统计直方图扩展、向量维度信息、索引类型选择、过滤谓词的成本权重。真正实现的时候一定比图上画的复杂但这个方向是对的——把 AI 查询当成一类普通查询来优化而不是当成特殊通道。这样维护成本更低也更容易预测性能。5. AI 平台层与自治运维17-20 张图在講什么5.1 模型推理服务怎么进入数据库看到第 17、18 张图才进入真正的 AI 平台部分。图上展示的模型接入方式不是简单地在数据库里内置一个开源模型而是提供了一个模型抽象层。模型可以来自三处数据库内置的小模型、你注册进来的开源模型通过 ONNX 等格式、以及远程大模型 API。对 SQL 开发者来说它们统一表现为一个函数调用。这个设计解决了一个很实际的问题你的业务不需要被模型供应商绑架。你可以先用远程大模型 API 跑通应用等业务量上来、或者数据安全要求变严之后把模型替换成本地推理服务SQL 层的调用方式不用推倒重来。反过来也一样本地小模型效果不理想可以切回远程大模型。数据不落地的推理路径是图 18 的重点。当你在一条 SQL 里调用 AI 函数处理某一行数据时数据流经内存、进入模型推理、返回结果整个过程不需要把数据导出到数据库外部。对数据管控严格的环境来说这是相比数据库外部 AI 服务方案最根本的优势。5.2 自治数据库的能力在 AI 时代有了新内涵图 19 到图 20 开始进入自治运维的部分。老版本里的自治数据库重点在自动备份、自动打补丁、自动调优。26ai 的图里自治能力多了一条关键链路用 AI 诊断数据库自身的运行状态。图上有一个很有意思的闭环数据库运行时采集指标和日志AI 服务分析异常模式如果是参数问题就自动调整如果是容量问题就建议扩容如果是 SQL 性能问题就生成索引建议。这个闭环和外部监控工具的本质区别在于25 系版本就能自动做不少诊断但 26ai 强调把诊断经验直接沉淀在数据库代码里而不是靠外部运维人员读取告警再决策。5.3 资源隔离与 AI 工作负载治理AI 查询和传统 OLTP 跑在同一个数据库里最大的隐患是资源争抢一个向量搜索批量任务可能把 CPU 吃满导致线上交易变慢。图 20 旁边的小图讲的正是这个问题的解法通过资源管辖区Resource Manager把 AI 工作负载放进独立配额池。我在实际调优时最怕的也是这类问题。AI 场景经常有跑批式的向量化任务比如每晚把新增文档全部过一遍 embedding这类任务和交易查询并发没有隔离就是事故现场。架构图上把 AI 工作负载单独画成一个池子说明设计上已经默认这种隔离是基线能力而不是事后补丁。6. 看图时容易忽略的细节安全模型与应用改造6.1 推理数据不落盘不等于没有日志审计第 17、18 张图虽然讲了推理路径不经过外部服务但别忽略数据库本身是有完整审计体系的。AI 函数调用一样会产生 SQL 执行记录、访问日志、以及数据变更记录。你在图上看到数据不出域应该联想到的是能审计、能追溯、能限权。对应用开发者来说这意味着 AI 功能的权限管理使用数据库原有体系控制即可不需要额外建一套授权系统。我在实际项目里看到过因为AI 调用算不算数据访问没定义清楚导致的安全漏洞业务方以为推理服务只是传一句文本过去不会留存输入结果外部模型服务商在日志里存了所有 prompt。26ai 这种以内置推理为核心的路径至少在权限和审计上能跟现有数据库体系对齐少很多扯皮。6.2 AI 工作负载的存储与算力成本要算两笔账看图和实际做方案之间差着一本成本账。向量存储本身要占用空间向量索引要占用内存模型推理需要 CPU 或 GPU 资源。图 8 到图 10 只画了性能路径没有画资源配额。你自己规划容量时要把这几项单独列出来原始向量数据维度 × 行数 × 每个分量的字节数再算上压缩率。向量索引HNSW 的图结构通常比原始向量占空间更大图里的参数会显著影响内存。图 8~10 里没有直接展示索引内存占用但你要清楚这是大头。推理资源本地模型推理和远程 API 的成本模型完全不同。本地模型要预留 CPU/GPU远程 API 则是按调用量付费两者都需要纳入架构决策。6.3 应用的改造路径不需要一步到位很多人看到新版本有向量索引、有 AI 函数就准备推翻原有架构重写。架构图册里没有明说但这个产品定位已经暗示了一条渐进式路径你完全可以先把一个检索模块从外部向量库迁移到数据库里其他部分不动跑稳之后再逐步把全文搜索、图关系查询并进来。同时SQL 作为统一入口也意味着行为变化对应用是局部性的不用把整个数据访问层换掉。拿我参与过的一个知识库项目举例。最初架构是关系库里存文档元数据、外部向量库存切分后的向量业务侧同时查两个库再在服务端合并结果延迟高而且经常出现两边数据不一致。后来把向量字段加进主表把原本外部向量库的写入逻辑全部去掉应用代码改动集中在 DAO 层查询耗时反而降了。现在看到 26ai 这组图我会更倾向于让这种融合发生在数据库内部而不是应用层拼装。7. 上篇读图笔记之外留给下篇的问题和自己的看图习惯这套架构图我读了两遍上篇对应的前 20 张图讲到这里最大的感受是数据库厂商终于不把 AI 当外挂功能了而是把它当成数据库原生的能力矩阵来做。但正因为能力铺得很开真正落到项目里时问题也会更立体模型怎么选型、推理性能怎么压测、多模型之间的排序权重怎么调、多云部署下数据如何同步这些都需要拿具体业务数据来验证。架构图给出的是边界和路径不是答案。我自己的看图习惯是第一步先给整套图做分组索引第二步逐个组件追问它解决什么问题、为什么需要存在、边界在哪第三步再倒回去看全局图确认组件之间怎么协作。这套方法比按顺序从头读到尾更容易形成体系化理解。下篇再接着拆后十几张图重点是模型接入的完整链路、安全策略、多云与本地化部署的差异以及 AI 工作负载的资源管理细节。如果你正在评估把 AI 能力放进数据库内部这条路上篇提到的融合查询、向量索引、推理数据不出域这三个点值得先在实际场景里做个最小验证。