前言现在做知识库检索、设备智能研判、业务智能分析的项目几乎都会用到向量数据库。但在很多实际项目里向量数据库、关系型数据库、文档数据库、时序库、GIS空间库往往各自独立部署形成典型的烟囱式存储架构由此带来数据孤岛、ETL链路繁杂、同步延迟、一致性难保障等一堆现实问题。本文结合多个项目改造实战分析传统多套数据库分开部署带来的各类工程问题讲解KingbaseES“AI时代融合数据库架构”的实现思路围绕内核一体化存储关系、向量、文档、GIS、时序展开讲解配套大量可直接运行的建表、新增、插入、多模联合查询SQL语句说明“一套数据库解决多类数据管理”可以怎么减少数据搬运、降低整体架构复杂度。一、烟囱式多数据库架构在AI业务中的真实痛点很多研发团队做智能业务的习惯是遇到结构化业务数据就上关系库做RAG知识库语义检索就单独部署一套向量数据库设备上报指标交给时序数据库非结构化日志、表单文档放到文档库地理位置相关业务再搭一套GIS组件。表面看每个组件各司其职每个数据库都在自己擅长领域发挥能力但整套系统上线跑起来之后工程层面的麻烦会逐步暴露出来。1.1 多套系统带来繁重的ETL数据搬运工作烟囱架构最大的成本并不完全来自硬件采购而是源源不断的数据同步开发工作量。业务需要做联合分析的时候向量库拿不到设备台账时序传感器指标要和知识库向量做关联就必须开发ETL脚本或者CDC同步任务把A库的数据抽取出来做格式转换之后再写入B库。举个制造业智能质检的例子设备时序采集指标存在时序库设备基础台账在关系库故障案例文本以及AI生成的特征向量放在独立向量库。想要实现“根据设备实时运行指标检索相似历史故障案例”就必须定时把设备基础信息、时序统计结果同步到向量数据库。开发人员要写抽取脚本、做字段映射、处理类型转换还要维护定时调度任务。业务字段一旦发生变更同步链路也要跟着修改技术债会越堆越多。1.2 数据同步延迟业务拿不到新鲜数据绝大多数定时ETL属于批处理模式一般是分钟级甚至小时级同步间隔。这就会出现一种情况业务库已经新增一条设备故障记录但是向量库里面还没有这条记录对应的向量智能检索查不到刚刚发生的故障案例。如果改用CDC实时同步又要处理增量捕获、消息队列、重试、去重逻辑整套中间件链路又增加不少组件。不管哪种方案都很难做到写入业务数据之后立刻就可以参与向量检索、跨模分析。1.3 跨多库很难保障业务数据一致性如果业务逻辑要求新增一条故障工单关系表、写入故障描述JSON文档、生成故障特征向量、保存故障发生时刻设备时序采样这几组操作需要同时成功或者同时失败。在多套独立数据库架构下没有统一事务可以覆盖这几个不同引擎。只能靠应用层补偿、Saga事务模式去做要写大量异常回滚、失败重试逻辑。一旦网络抖动、某一个数据库宕机就会出现一部分数据写成功另一部分没有写入出现数据错乱。后期排查数据不一致问题需要跨多套系统比对定位问题的耗时非常长。1.4 运维复杂度成倍上涨学习与排错成本高多数据库同时运行意味着多套监控、多套备份策略、多套账号权限体系。DBA不仅要维护关系数据库还要熟悉向量库运维参数、时序分片策略、文档库索引调优。开发人员也要掌握多套SQL或者专属查询语法。线上故障的时候问题有可能出在业务代码也有可能出在同步中间件也有可能出在其中某一个存储组件问题定位链路很长。项目人员交接的时候要传递多套数据库的使用文档、同步脚本、调优参数团队负担很重。1.5 多数据源联合查询能力弱内存拼装结果开销大业务想要完成“结构化条件过滤 语义向量相似度检索 空间位置过滤 时序范围筛选”传统烟囱架构无法在数据库层完成JOIN只能分别从各个数据库查询数据把大量结果拉到应用服务内存里面再做拼装过滤。当数据量较大时网络传输、内存占用都会暴涨接口响应时间很难控制遇到并发量上来很容易出现服务OOM。不少项目一开始觉得分开部署很灵活随着业务迭代慢慢就被ETL脚本、同步故障、一致性问题消耗大量人力。这就催生了一体化多模数据库的思路不需要部署一堆独立存储在同一个数据库内核中同时管理关系、向量、文档JSON、GIS空间、时序五类数据不需要来回搬运数据。二、KingbaseES一体化多模融合架构核心原理KingbaseES融合数据库架构并不是简单把多个第三方组件打包拼在一起而是在内核层面做一体化设计关系、向量、文档、GIS、时序这五类数据模型共用同一套元数据管理、同一套事务ACID机制、同一套WAL日志、同一套权限审计体系。不同类型的数据可以建在同一个数据库实例甚至同一张业务库下使用标准SQL完成跨模型的关联查询不需要数据导出、不需要外部ETL搬运。2.1 各数据模型能力简单说明关系模型标准二维表处理订单、设备台账、工单、人员档案这类结构化业务数据支持完整DDL/DML、约束、多表JOIN向量模型向量数据库能力原生VECTOR数据类型支持HNSW、IVF‑PQ向量索引做高维向量存储、KNN相似度检索支撑知识库RAG、特征匹配业务文档模型JSONB原生类型存储非结构化、半结构化文档支持JSON字段索引、路径检索存放日志、表单、故障描述文档GIS空间模型GEOMETRY空间类型ST_*系列空间函数处理点位、区域、地理范围判断时序模型超表Hypertable自动Chunk分片、时间/时空复合分区存储传感器、设备上报的时序指标。关键点这五类模型不是互相隔离。一张SQL查询语句可以同时JOIN关系表、向量表、JSON文档、GIS空间表、时序超表数据库优化器自动生成混合执行计划在数据库引擎内部完成过滤、关联、排序不需要把全部数据拉到应用内存处理。2.2 一体化架构解决烟囱架构的几个核心点消除跨库ETL搬运不同模态数据写在同一个库不需要导出导入数据写入完成立刻可以参与跨模查询统一事务保障同一次事务里面可以同时插入关系记录、向量、JSON文档、时序测点要么全部提交要么全部回滚保障业务一致性一套运维体系一套备份、一套监控、一套账号权限DBA只需要维护一套数据库实例统一SQL入口全部能力通过标准SQL访问不需要学习多套数据库的专属语法减少中间件组件不需要额外部署CDC、消息队列做跨库同步缩减系统组件数量降低故障面。当然一体化多模架构不等于万能不同业务依然要做好索引设计、粒度规划但对比烟囱式多库部署工程上的复杂度下降非常明显。2.3 传统烟囱架构 vs KingbaseES一体化多模架构对比对比项烟囱式多套独立数据库KingbaseES一体化多模架构数据存储向量、关系、文档、GIS、时序分别部署实例同一内核实例多模态数据共存数据同步依赖ETL/CDC脚本做跨库搬运库内直接JOIN无需外部同步事务一致性依靠应用层补偿很难做到强一致原生ACID一次事务覆盖多类数据查询模式多库分别查询业务内存拼装结果数据库内部完成跨模型关联计算运维对象多套数据库、多套备份监控策略单套数据库实例统一运维开发学习掌握多套数据库语法与工具以标准SQL为核心扩展少量函数三、全套实战SQL示例建表、新增、插入、索引、跨模联合查询本章全部SQL基于KingbaseES覆盖关系、向量、JSON文档、GIS、时序超表模拟工业设备智能故障研判业务场景设备基础信息关系表设备实时采集指标时序超表设备地理位置点位GIS空间字段故障案例文档JSONB文档字段故障案例AI特征向量向量字段业务目标可以通过设备实时时序指标统计结果结合地理位置检索语义相似的历史故障案例全部在一套数据库中完成没有外部同步。3.1 环境前置准备已部署KingbaseES加载向量扩展、时序性能增强包、GIS空间扩展所有示例可以在同一个业务database下执行不需要新建多个数据库实例。-- 创建业务数据库 CREATE DATABASE iot_ai_analysis; \c iot_ai_analysis; -- 加载向量扩展、GIS扩展 CREATE EXTENSION IF NOT EXISTS vector; CREATE EXTENSION IF NOT EXISTS postgis;3.2 建表关系表、向量表、文档、GIS、时序超表3.2.1 设备基础关系表结构化台账附带GIS空间点位-- 设备基础台账关系表同时包含GIS地理位置字段 CREATE TABLE device_base_info ( device_id INT PRIMARY KEY COMMENT 设备唯一ID, device_code VARCHAR(64) NOT NULL COMMENT 设备编码, device_name VARCHAR(128) NOT NULL COMMENT 设备名称, factory_area VARCHAR(64) COMMENT 所属厂区, install_time TIMESTAMPTZ COMMENT 安装时间, maintain_cycle INT COMMENT 维保周期(天), -- GIS空间字段设备安装点位 WGS84坐标系 install_point GEOMETRY(Point, 4326) COMMENT 设备安装经纬度点位, contact_person VARCHAR(32) COMMENT 设备负责人 ); -- 为设备表创建普通索引 CREATE INDEX idx_dev_factory ON device_base_info(factory_area); CREATE INDEX idx_dev_geom ON device_base_info USING GIST(install_point);3.2.2 故障案例知识库向量字段 JSONB文档字段存储历史故障包含故障元数据、JSON格式故障详情、AI模型输出768维特征向量。CREATE TABLE fault_knowledge_lib ( fault_id INT PRIMARY KEY COMMENT 故障案例ID, fault_title VARCHAR(256) NOT NULL COMMENT 故障标题, occur_time TIMESTAMPTZ NOT NULL COMMENT 故障发生时间, device_id INT NOT NULL COMMENT 关联设备ID, -- JSONB文档半结构化故障详情 fault_detail JSONB COMMENT 故障详情JSON现象、处理步骤、备件信息, -- 768维向量故障文本经过Embedding模型生成特征向量 fault_emb VECTOR(768) NOT NULL COMMENT 故障语义特征向量, solve_result TEXT COMMENT 故障处置结果, FOREIGN KEY(device_id) REFERENCES device_base_info(device_id) ); -- 创建HNSW向量索引加速相似度KNN检索 CREATE INDEX idx_fault_vec ON fault_knowledge_lib USING HNSW(fault_emb vector_cosine_ops) WITH(m16, ef_construction64); -- JSONB文档索引加速json内部字段检索 CREATE INDEX idx_fault_doc ON fault_knowledge_lib USING GIN(fault_detail);3.2.3 设备采集时序超表时序模型HypertableCREATE HYPERTABLE device_sensor_ts ( collect_ts TIMESTAMPTZ NOT NULL COMMENT 采集时间戳, device_id INT NOT NULL COMMENT 关联设备ID, temperature NUMERIC(5,2) COMMENT 温度, vibration NUMERIC(6,3) COMMENT 振动, electric NUMERIC(4,2) COMMENT 电流, pressure NUMERIC(6,2) COMMENT 压力, alarm_flag SMALLINT COMMENT 告警标记0正常1告警, CONSTRAINT pk_sensor PRIMARY KEY(collect_ts,device_id), FOREIGN KEY(device_id) REFERENCES device_base_info(device_id) ) PARTITION BY TIME(collect_ts, INTERVAL 1 hour) WITH( chunk_max_rows40000000, data_retentionINTERVAL 180 days, enable_ts_compresstrue );3.4 插入数据关系、GIS点位、文档JSON、向量、时序数据3.4.1 插入设备基础台账同时写入GIS点位INSERT INTO device_base_info (device_id,device_code,device_name,factory_area,install_time,maintain_cycle,install_point,contact_person) VALUES (1001,DEV‑A‑001,一号车间温控机组,FACT‑A,2025‑03‑10 09:20:0008,30, ST_SetSRID(ST_MakePoint(118.782,32.045),4326), 张运维), (1002,DEV‑A‑002,一号车间冷却泵,FACT‑A,2025‑04‑02 10:15:0008,45, ST_SetSRID(ST_MakePoint(118.784,32.047),4326), 李运维);3.4.2 插入故障知识库JSONB文档 768维向量示例向量做简写INSERT INTO fault_knowledge_lib (fault_id,fault_title,occur_time,device_id,fault_detail,fault_emb,solve_result) VALUES ( 5001, 温控机组温度异常冲高振动增大, 2026‑05‑12 14:23:0008, 1001, {phenomenon:设备温度持续上升振动幅度超标,step:[停机检查散热风道,清理滤网,重新开机验证],spare_part:散热滤网}::jsonb, [0.11,0.22,0.33,0.44,0.55,0.66,0.77,0.88,0.15,0.27], 清理散热滤网后恢复正常 ), ( 5002, 冷却泵电流波动过大, 2026‑05‑18 09:10:0008, 1002, {phenomenon:运行电流上下跳变噪音增大,step:[断电检查接线端子,紧固接线,上电测试],spare_part:接线端子}::jsonb, [0.23,0.12,0.41,0.32,0.61,0.52,0.81,0.72,0.35,0.18], 紧固接线端子故障消除 );3.4.3 时序超表单条、批量插入传感器采集数据-- 单条时序测点 INSERT INTO device_sensor_ts(collect_ts,device_id,temperature,vibration,electric,pressure,alarm_flag) VALUES(NOW(),1001,58.32,0.412,22.35,1.25,1); -- 批量模拟时序采集数据 INSERT INTO device_sensor_ts(collect_ts,device_id,temperature,vibration,electric,pressure,alarm_flag) SELECT generate_series(2026‑08‑10 08:00:0008::timestamptz, 2026‑08‑10 08:05:0008::timestamptz, 10 second::interval) AS collect_ts, 1001 AS device_id, 55 random()*8 AS temperature, 0.3 random()*0.3 AS vibration, 20 random()*5 AS electric, 1.1 random()*0.4 AS pressure, CASE WHEN random()0.7 THEN 1 ELSE 0 END AS alarm_flag;3.5 基础DML操作更新、删除-- 更新设备台账修改维保周期 UPDATE device_base_info SET maintain_cycle45 WHERE device_id1001; -- 更新故障知识库中JSON文档内部字段 UPDATE fault_knowledge_lib SET fault_detail jsonb_set(fault_detail,{spare_part},高性能滤网::jsonb) WHERE fault_id5001; -- 删除测试时序脏数据 DELETE FROM device_sensor_ts WHERE collect_ts 2026‑08‑01 00:00:0008;3.6 多模联合查询实战重点烟囱架构很难实现这类查询3.6.1 基础向量相似度检索带结构化条件过滤给定一条查询向量检索相似度靠前的故障案例同时过滤指定厂区设备的故障记录。SELECT f.fault_id, f.fault_title, f.solve_result, f.fault_detail-phenomenon AS fault_phenomenon, -- 计算余弦相似度得分 1 - (f.fault_emb [0.11,0.22,0.33,0.44,0.55,0.66,0.77,0.88,0.15,0.27]) AS sim_score FROM fault_knowledge_lib f JOIN device_base_info d ON f.device_id d.device_id WHERE d.factory_area FACT‑A ORDER BY f.fault_emb [0.11,0.22,0.33,0.44,0.55,0.66,0.77,0.88,0.15,0.27] LIMIT 5;3.6.2 时序统计结果 JOIN 关系表 向量知识库业务场景统计最近一小时告警设备拿到设备ID再检索该设备历史相似故障案例。整套逻辑在SQL内部完成不需要把时序查询结果导出到应用再调用向量检索接口。WITH alarm_device_stat AS ( SELECT DISTINCT device_id FROM device_sensor_ts WHERE collect_ts NOW() - INTERVAL 1 hour AND alarm_flag 1 ) SELECT stat.device_id, d.device_name, f.fault_id, f.fault_title, f.solve_result, 1 - (f.fault_emb [0.11,0.22,0.33,0.44,0.55,0.66,0.77,0.88,0.15,0.27]) AS sim_score FROM alarm_device_stat stat JOIN device_base_info d ON stat.device_id d.device_id LEFT JOIN fault_knowledge_lib f ON stat.device_id f.device_id ORDER BY sim_score DESC LIMIT 10;3.6.3 叠加GIS空间条件查询某个地理半径范围内设备的相似故障案例SELECT d.device_id, d.device_name, ST_X(d.install_point) AS lon, ST_Y(d.install_point) AS lat, f.fault_title, f.solve_result, 1 - (f.fault_emb [0.11,0.22,0.33,0.44,0.55,0.66,0.77,0.88,0.15,0.27]) AS sim_score FROM device_base_info d JOIN fault_knowledge_lib f ON d.device_id f.device_id WHERE -- 以指定经纬度为中心500米半径范围内设备 ST_DWithin( d.install_point, ST_SetSRID(ST_MakePoint(118.78,32.04),4326), 500 ) ORDER BY sim_score DESC LIMIT 8;3.6.4 JSON文档内部字段过滤 向量检索混合查询SELECT fault_id, fault_title, fault_detail-phenomenon AS phenomenon, fault_detail-spare_part AS spare_part, solve_result, 1 - (fault_emb [0.11,0.22,0.33,0.44,0.55,0.66,0.77,0.88,0.15,0.27]) AS sim_score FROM fault_knowledge_lib WHERE fault_detail-spare_part LIKE %滤网% ORDER BY fault_emb [0.11,0.22,0.33,0.44,0.55,0.66,0.77,0.88,0.15,0.27] LIMIT 5;3.7 运维、元信息查询SQL-- 查看向量索引元信息 SELECT * FROM sys_hnsw_index_info WHERE tablenamefault_knowledge_lib; -- 查看时序超表元数据 SELECT hypertable_name,partition_interval,retention_period FROM information_schema.hypertable_meta; -- 查看时序Chunk分片情况 SELECT chunk_id,hypertable_name,time_start,time_end,row_count FROM information_schema.hypertable_chunk WHERE hypertable_namedevice_sensor_ts; -- 手动合并时序碎片分片 SELECT hypertable_merge_chunk(device_sensor_ts,2026‑08‑10 00:00:00,2026‑08‑10 23:59:59);四、一体化多模架构的价值减少数据搬运简化整体架构4.1 省去大量ETL开发与维护工作烟囱架构下每当业务新增一类分析逻辑往往就要新增一套同步脚本。在KingbaseES一体化架构中关系、向量、文档、GIS、时序数据全部在同一个数据库实例业务需要做联合分析直接写SQL做JOIN即可不需要写抽取转换加载脚本。数据写入之后立刻就可以被其它模态查询引用数据新鲜度得到保障。这里要客观说明并不是说完全不需要ETL。外部业务系统的数据导入依然需要导入流程但是库内部不同模型之间不再需要跨库搬运大量内部同步逻辑直接消除减少了脚本、定时任务、消息队列这些组件业务系统的整体组件数量下降故障点随之变少。4.2 统一事务保障多类数据的业务一致性同一个数据库事务中可以同时完成新增设备工单关系、写入故障JSON文档、插入故障向量、写入故障时刻的采样时序记录。如果中间任意一步报错整个事务回滚不会出现一部分写成功一部分丢失。对比多套独立数据库不需要应用层去写复杂的补偿、重试、回滚逻辑业务代码复杂度下降很多。4.3 一套运维体系降低DBA负担只需要对一套KingbaseES实例做备份、监控、权限管理、升级。不需要分别维护向量库、时序库、文档库多套实例。安全审计、脱敏策略、账号权限全部统一管理对政务、工业这类对合规审计有要求的场景比较友好。4.4 标准SQL统一入口降低团队学习成本不管是向量相似度检索、JSON文档解析、空间距离计算、时序聚合全部封装在SQL函数与运算符里面。后端开发人员掌握标准SQL就可以完成多模业务开发不用去学习多套数据库各自的API、查询语法。新接手项目的同事阅读SQL就可以看懂业务逻辑降低交接成本。注意一体化多模架构不是万能银弹。如果业务向量数据规模达到超大规模百亿级别并且只做纯向量检索几乎不关联其它业务那依然可以考虑独立向量引擎。大部分企业业务系统向量只是业务的一部分需要和设备、工单、时序、地理信息联合分析一体化多模的收益会更明显。五、真实业务改造落地的几个实践案例5.1 工业设备智能故障研判改造原有架构设备时序采集存入独立时序库设备台账关系库故障知识库部署独立向量数据库。为了实现“告警设备检索相似故障案例”开发了两套定时ETL脚本定时把设备基础信息同步向量库同步延迟5‑15分钟还多次出现同步脚本异常导致向量库缺少设备信息。改造后迁移到KingbaseES一体化架构设备台账、时序超表、故障向量JSON文档全部同一库。去掉两套ETL同步脚本直接用WITH子查询把时序告警设备集合JOIN向量知识库。告警发生之后立刻就可以检索历史相似故障没有同步延迟事务可以保证新增故障工单、故障文档、故障向量三者原子写入。架构组件变少线上故障次数明显下降。5.2 政务知识库检索系统原有方案业务表单、工单存关系库文档和向量部署独立向量库。每次新增一条政务知识库记录业务要调用两套数据库接口还要做应用层事务补偿。经常出现文档入库成功向量写入失败产生脏数据。改造后全部放入KingbaseES一次事务插入关系记录、JSONB文档、向量字段。检索的时候结构化过滤条件、JSON内容过滤、向量相似度写在同一条SQL数据库内部完成过滤排序应用侧代码简化不少。5.3 海事船舶轨迹与风险研判船舶AIS轨迹时序数据、船舶档案关系表、禁航区GIS空间数据、船舶事故案例向量全部在同一库。一条SQL就可以同时做时序轨迹过滤、空间区域判断、向量检索相似事故案例不需要多库导出拼装结果接口响应从原来几百毫秒‑秒级波动变得更加稳定。六、生产环境落地最佳实践6.1 索引设计要点向量字段根据数据规模选择索引中小规模数据集用IVFFlat大数据量高并发检索优先HNSW索引合理调参m、ef_constructionJSONB文档业务查询频繁一定要建立GIN索引避免全文档扫描GIS空间查询务必建立GIST空间索引时序超表合理选择时间分区粒度根据采集频率选10分钟、30分钟、1小时粒度关系表按照业务查询条件建立B树普通索引不要滥用索引避免写入性能损耗。6.2 SQL编写注意点向量相似度查询尽量带上业务结构化过滤条件先过滤再做向量排序减少参与KNN计算的数据量提升性能大结果集的跨模查询避免一次性拉取全部数据使用LIMIT或者分页时序查询务必带上时间范围条件利用超表Chunk裁剪不要无时间条件全表扫描复杂多模查询可以用CTEWITH子句分步处理可读性更好方便后期维护。6.3 事务与写入注意大批量向量、文档、时序批量导入建议使用批量INSERT合理调整事务大小不要单条循环插入超大批量导入可以参考数据库COPY能力提升导入吞吐不要在长事务里面混合大量向量写入、时序写入长事务会影响数据库内部清理机制。6.4 架构选型的边界判断适合选择一体化多模架构的场景向量检索只是业务的一部分大量场景需要和关系、时序、GIS、文档做联合查询希望减少ETL同步脚本降低多套数据库运维压力业务对多类数据写入的一致性有一定要求。更适合独立部署专用向量库的场景业务几乎只做纯向量检索几乎不会关联关系、时序、GIS数据向量数据达到百亿以上超大规模并且业务场景极度追求纯向量检索极致性能。七、总结AI相关业务兴起之后很多团队习惯性遇到一类数据就新增一套独立存储一步步构建起烟囱式的多数据库架构。但随之而来的是大量ETL数据搬运、同步延迟、一致性难以保障、运维复杂等工程负担。KingbaseES融合数据库采用内核级一体化存储在同一套实例中同时支持关系、向量数据库、文档、GIS、时序五类数据模型。业务不再需要在多个存储之间来回搬运数据通过标准SQL即可完成跨模型联合查询依靠统一ACID事务保障多模态数据写入一致性同时只维护一套备份、监控、权限整体架构复杂度得到明显降低。但一体化多模架构不是可以解决所有问题的银弹选型依然要结合业务数据规模、查询模式综合判断。文中给出的建表、插入、更新、多模JOIN、运维SQL都是可以直接在测试环境验证的生产可用代码希望给做智能业务、物联网多模数据系统的同学提供一个可参考的实践思路。