一份合同签回来,在系统里通常是这么散开的。
PDF 原件传进对象存储,拿到一个文件路径;客户名称、金额、生效日期这些字段落进业务表,拿到一个自增主键;正文切成几十个文本块,过一遍 embedding 模型进向量数据库,每个块再拿一个向量 ID;合同带履约地点的,坐标进空间库;后续每期回款是一串时间点,进时序库。
一份合同,五个库,五套 ID。
平时看不出什么。直到法务说,这份合同作废了。
一、作废是最难同步的那种操作
业务表里把状态改成"已作废",一个事务,几毫秒。剩下四个库靠异步任务追。
对象存储那份原件不动也无所谓,反正没人直接访问;空间库和时序库的数据没人查,不至于出错。真正会出事的是向量库------那几十个文本块还躺在里面,embedding 是好的,相似度是高的。客服机器人下次被问到相关条款,照样召回、照样引用,而且引用得很自信。
删除比更新难同步,原因在于它不产生新数据。更新至少还能靠"时间戳新的覆盖旧的"兜底,删除没这种便宜可占,你必须逐个确认下游都执行了,而这件事在架构里没有任何一个组件天然负责。
所以"数据孤岛"真正的麻烦,不在于数据分散在好几个地方。分散本身没什么。麻烦的是这几份副本谁都不是权威版本,谁也没有义务跟别人保持一致。偏差出现的时候系统不报错,它只是给出一个过时的答案。
二、烟囱与烟囱之间
各建一套、互不相通,这种架构一般叫"烟囱式"。单看每根烟囱都挑得没毛病:向量检索当然该用向量库,时序聚合当然该用时序库。出问题的地方在烟囱之间。
时间上对不齐。 五个库的写入没有统一的顺序保证。业务表提交了,embedding 队列还堵着;时序库入库延迟三分钟,空间库定时任务一小时跑一次。任何一个跨库的查询,读到的都是五个不同时刻的世界。
事务上兜不住。 金仓那份材料里有一句话说得挺实在:市面上绝大多数向量数据库都是 NoSQL 型的,不支持事务 ACID。这意味着写关系表成功、写向量失败这个组合没有回滚可言。团队于是开始写补偿:失败重试、幂等键、每天凌晨的全量对账。这些代码不产生业务价值,但漏一个分支,数据就悄悄歪了。
查询上拼不起来。 同一份材料把这一条列为行业普遍难题:向量与标量的混合查询,对市面上的向量数据库来说是很大的挑战。落到业务上就是那种最常见的需求------"在未作废、金额大于 500 万、华东区的合同里,找和这段条款语义相近的"。向量在一套系统,标量条件在另一套,只能二选一:先粗召回一万条再回业务库过滤,或者先筛出候选 ID 再拿去向量库比对。前者延迟难看,后者候选集一大就退化成扫描。
人和流程上是散的。 五个库意味着五套备份策略、五套高可用方案、五套权限模型、五份审计日志。安全评审过五遍,合规资质备五份。故障发生时,第一件事不是修,是判断问题出在哪一层。DBA 不熟悉 HNSW 的参数,算法工程师不关心 RPO,中间那段没人负责的地带通常就是事故起点。
这些成本单项都不算大,合在一起是架构复杂度。而架构复杂度不随系统数量线性增长,是按系统之间的连接数增长的。五个库两两相连,最多二十条方向。 
三、把向量放回数据模型层
电科金仓在 KingbaseES(KES)上给出的思路,是不让向量单独立一个门户。
看官方那张 KES 融合数据库架构图,层次分得很清楚。最上面是应用场景层,OLTP、OLAP、HTAP、时序、Stream、AI 并排;往下是数据模型层,向量模型摆在正中间,和关系模型、文档模型、图模型、KV、非结构化数据同处一层;再往下,进程与集群架构层管主备、读写分离、共享存储多写、无共享分布式、存算分离池化和跨多云多地;语言层统一走 SQL 标准,并兼容 Oracle、MySQL、SQL Server、DB2 等多种语法;优化执行层里有 RBO/CBO/AIBO、单元组与向量执行、解释与编译执行、异构硬件加速、密态计算;最底下的数据存取层是行存储、列存储、KV 存储和稀疏矩阵存储,共用一套集群文件系统。
这个排布的意思是:向量不是挂在数据库旁边的一个服务,它就是数据库里的一种数据模型。加上 KES 本身具备的 GIS 与时序处理能力,前面那份合同的五类数据------结构化字段、正文文本、语义向量、履约坐标、回款序列------理论上可以待在同一个库里,共用同一套事务、同一套日志、同一套备份链路、同一套权限和审计。
实现方式上,金仓走的是组件路线:向量能力以插件形式接入,复用 KES 已有的能力和生态,应用侧仍然用熟悉的 SQL 写查询。材料里还提了一句针对性优化------面向向量数据的摄取、读写、存储、插值和聚合做了专门处理,不是简单套一个通用类型上去。 
四、"全部已有数据类型"这几个字
金仓在关键特性表里写了一条:可以与 KES 中全部的已有数据类型进行联合查询。在优势页里又强调了一遍,并且加了个括号------不止标量。
这几个字是整套架构的技术支点,值得掰开看。
市面上支持"混合检索"的向量库,多数指的是向量 + 元数据过滤,元数据通常限于字符串、数值、布尔这些标量。而合同这个场景需要的是:向量条件、关系表的状态字段、JSON 里的条款结构、坐标的空间包含关系、回款时间的区间------五种判断条件写进同一个 WHERE。
条件在同一个执行引擎里,优化器才有机会决定先走哪个索引、把哪个条件下推。条件散在五个系统里,顺序就只能由应用代码硬编码,而应用代码没有统计信息,猜不准哪个条件选择性更高。
这也是金仓拿自己和 Oracle 23ai 对比时的落点。那张对照表里有几处差异值得注意:KES 在稠密向量之外还支持稀疏向量;距离运算支持六种(曼哈顿、欧氏、负内积、余弦、汉明、杰卡德),对方五种;操作符 KES 六个,对方三个;向量可以做等值和大小比较、可以作为 key,对方不支持。最实用的一条是------KES 建立向量索引之后,依然支持新向量的插入与删除,而 Oracle 23ai 建好 HNSW 索引后不支持增删。
回到那份作废的合同:如果索引建完就不能删向量,你要么定期重建整个索引,要么容忍它一直被召回。这不是性能问题,是正确性问题。
对照表里金仓也标了自己的空白项:周围生态集成不支持,Oracle 那边可以直接输入文本、自动转向量再查询的整套流程。这一条对做原型的团队有影响,对已经有自己 embedding 服务的团队影响不大。
五、视频搜索那张流程图值得看两遍
材料里有一张视频搜索的流程图,画得比文字清楚。
入库这一路:准备视频数据集,用 OpenCV 提取关键帧,再用 ResNet50 算出每个关键帧的特征向量,存进去。查询这一路:待查询视频同样过 ResNet50 拿到特征向量,交给 KES_Vector 做相似性搜索。
关键在最后那一小段:命中之后,KES_Vector 与 KES 之间传递的是向量 ID,KES 拿这个 ID 直接关联出对应的业务数据,输出结果。
这段连线之所以重要,是因为它发生在库内。换成分离架构,这里就变成:应用拿到向量库返回的一批 ID,序列化,发给业务库,拼一个 IN (...) 查询,再把两边结果在内存里 join 起来。ID 数量一多,这条路的延迟和内存占用都不好看,而且没有任何事务保证------你拿到的 ID 对应的业务记录,可能在这两次查询之间已经被改了。
智能客服那张 RAG 流程图也是同一个道理。用户问题和历史对话合成独立问题,转成向量,去向量库做相似性搜索,取回相关文档,填进提示模板,连同问题一起交给大模型生成回答;文档入库则是另一条线,格式化文档转纯文本、切块、embedding、存储。整条链路上,向量检索和业务数据的关联点越靠近存储层,需要在应用里维护的状态就越少。
六、向量本身的功课
融合架构成立的前提是向量能力别拖后腿。这份材料给的清单还算具体。
检索:精确检索和近似最近邻检索都支持,精确查询走暴力搜索,近似查询走自研索引。
类型 :单精度、半精度、二进制向量,稠密和稀疏都支持。存储上限方面,稠密单精度和半精度向量最大 16,000 维,稀疏向量支持 16,000 个非零元素,二进制向量上限 83,886,080。索引维度另有一套限制,因为索引里存了向量副本、按 8K 页面设计:FP32 到 2,000 维,FP16 到 4,000 维,二进制到 64,000 维,稀疏向量 1,000 个非零元素。这道限制只作用于索引,表里存储不受此限------这个区分在做容量规划时很容易被搞混。
索引 :IVF_Flat 和 HNSW 都是自主实现的,加了 x64 SIMD 加速。两者怎么选,材料给的判断依据是:内存紧张选 IVFFLAT,它只存聚类质心和聚类内的向量列表,代价是搜索速度与准确性;追求高维空间下的检索速度,或者对召回率要求高,选 HNSW,代价是更高的内存占用,以及 ef_construction 调高之后明显变慢的索引构建。
运行时:支持并行查询,支持索引扫描的定制化扫描,新增或修改数据时索引实时维护。
功能面:全 SQL、自定义存储过程、事务 ACID;向量支持加减乘和拼接运算,支持正则化、切片、取模、取维度数等函数,支持 AVG、SUM 等聚合;可以用表达式索引来索引子向量;可以和浮点数组、整型数组互转。
部署:物理部署、云部署、嵌入应用部署三种形态。
短板也写在材料里,没藏着:目前不支持 GPU 加速。金仓把它连同新索引方法、已有索引性能优化、新增向量类型和计算函数一起放进了后续规划。对多数企业级检索场景,CPU 加 SIMD 够用;做超大规模离线向量处理的团队需要把这一条算进去。
七、少一条 ETL 到底省了什么
"减少数据搬运"这句话说多了会变虚,展开算一下就实在了。
一条跨库同步链路,通常要配齐这些东西:一个调度任务、一套失败重试、一份幂等设计、一个延迟监控指标、一条告警规则、一份定期对账脚本,以及一个"数据对不上时找谁"的人。六个技术件加一个责任人。
合同那个例子里有四条这样的链路。全部收进一个库,减掉的不是四份带宽开销,是二十四个需要有人维护的技术件和四段责任模糊的地带。
跨模型的关联从应用层挪到库内,还顺带解决了两件事:关联发生在同一个事务快照下,不会读到两个时刻的数据;优化器能看见全部条件,有机会选出更好的执行路径。
再往上一层是技术栈本身的收敛。一套备份恢复、一套高可用(实例、集群到多中心)、一套权限与审计体系、一份合规资质,覆盖全部数据类型。采购和安全评审的工作量差异,在大型机构里往往比技术差异更能决定选型结果。
八、这条路什么时候不成立
得把话说全:融合不是万能解。
如果场景是纯向量、规模在百亿以上、几乎不需要标量过滤、也不要求事务,那么专用向量数据库在纯检索性能上仍然有优势,这一点没什么好回避的。融合路线的收益集中在"混合"两个字上------你的查询条件里非向量的部分占比越高,一致性和合规要求越严,这条路越划算。
有意思的是市场本身的走向。金仓引用的 DB-Engines 2024 年 9 月榜单里,包含向量模型的产品共 18 个,排在前五的是 Kdb、Aerospike、Pinecone、Milvus 和 DolphinDB------其中三个是多模数据库,而经常被拿来和 Milvus 并称的三个专用向量库 Chroma、Qdrant、Weaviate,一个都没进前五。榜单口径本身有局限,不必过度解读,但"向量能力正在被并入既有数据库"这个趋势是清楚的。
需要说明的是,这份榜单已经是将近两年前的数据了,拿它论证今天的格局要打个折扣。
九、标准这件事,短期指望不上
材料里关于标准的两页写得比宣传口径坦率,值得转述。
到目前为止,向量数据库没有国际标准。原因不是没人做,是这个品类压根没有统一的产品形态:NoSQL 的、SQL 的、OLTP 的、OLAP 的、搜索引擎出身的都在加向量能力,各家市场定位和侧重点都不同,其中有些产品(材料点名了 ElasticSearch)严格说都不算数据库。没有国际标准,反而如实反映了市场现状。
国内是电子四院组织制定了一份向量数据库标准,参与方包括百度、腾讯、阿里、爱可生和金仓等,内容已经讨论确定,也有厂商参与了测试。金仓对这份标准的自评是:得到四院背书,但缺少该领域标杆厂商参与,改变不了产品形态多样、难以统一的现实;内容相对宽泛,偏向通用向量数据库,除多向量查询外基本覆盖了应有能力,可作设计参考;由于只能作概念性定义,各厂商实现自由度很大,市场碎片化短期内解决不了。
对做选型的人来说,这段话的含义很直接:标签不解决问题,得逐项对能力清单。同样写着"支持向量检索",一边可能是完整的事务、混合查询和多中心高可用,另一边可能只是加了个相似度函数。
十、回到那份合同
那份作废的合同,最后是怎么处理的?
多数团队的做法是在向量库里补一个 is_deleted 字段,检索时带上过滤条件,再写一个定时任务清理残留。能用,但它是在应用层重新发明了一遍"事务里的删除"。发明得好不好,取决于当时那个人有多细心。
融合架构改变的是这件事的归属:作废这个动作本身就是一次数据库操作,向量、正文、字段、坐标、时间序列在同一个事务里一起变更,不需要谁去补一层保证。
值不值得为此换一套底座,取决于你手上有多少份这样的合同,以及有多少条这样的链路。这个数每家不一样,得自己数。