img

多模数据库在港落地:六位从业者的技术观察与实践经验

6月12日,香港科技园举办了一场以多模数据库与 AI 工程落地为主题的线下技术交流活动。六位演讲者分别从本地化适配、多模引擎设计、AI 底层存储、迁移实践、工业场景、解决方案架构等不同角度分享了各自的经验和判断。本文整理了各议题的主要内容。


孙丽霞 · 本地化适配测试:流程与方法论

LSCM大湾区科研项目及业务发展总经理
《数据库在本地化适配测试实践介绍》

图片

港澳地区的数据库本地化适配并不只是"换个驱动"那么简单。孙丽霞结合大湾区科研项目的实际经历,梳理了几类高频问题:字符集与排序规则差异、存储过程语法兼容性、驱动层行为不一致,以及合规审计日志格式要求等。

她提到,测试阶段容易被忽视的一个环节是回归覆盖率——迁移后功能看似正常,但边界 case 往往在上线后才暴露。她整理的测试方法论大致分为三层:

  • 环境层:操作系统版本、libc 版本、网络策略是否与原环境一致
  • 功能层:SQL 方言兼容性、存储过程、触发器、视图行为验证
  • 性能层:在目标硬件上跑基准测试,不能直接沿用原平台的调优参数

跨境部署时还需额外关注数据出境合规,尤其是涉及个人信息的业务表,需要在架构设计阶段就确定数据分区策略。


萧少聪 · 一条 SQL 打通四种数据模型

数据系统独立技术顾问、AI语义存储技术专家
《一行SQL横跨关系型、向量型、JSON、图型四大模型》

图片

传统做法是针对不同数据类型分别维护一套存储:关系数据库存业务表,向量库存 Embedding,MongoDB 存文档,Neo4j 存图。这种架构的代价是数据同步链路复杂、查询跨库需要应用层拼接、运维成本成倍增加。

萧少聪演示了在统一多模引擎下,用单条 SQL 完成跨模型联查的写法,大致结构如下:

SELECT
    u.name,
    u.profile -> 'department'        AS dept,       -- JSON 字段
    vec_distance(u.embedding, :query_vec) AS score, -- 向量相似度
    r.relation_type                                  -- 图关系字段
FROM users u
JOIN user_relations r ON r.from_id = u.id
WHERE vec_distance(u.embedding, :query_vec) < 0.3
  AND u.profile @> '{"active": true}'
ORDER BY score
LIMIT 10;

这条查询同时涉及关系表的 JOIN、JSON 字段过滤、向量近似检索和图关系遍历,在单引擎内完成,省去了跨库协调的开销。

他也坦承,这种统一模型在极端性能场景下(比如纯向量检索的亿级 QPS)不一定是最优解,更适合的是混合查询频繁、数据关联复杂、工程团队规模有限的场景。


尹海文 · 数据库作为 AI Agent 的基础设施

金仓KVA、公众号【胖头鱼的鱼缸】主理人
《让数据库成为AI Agent的基础设施架构》

图片

一个能实际跑起来的 AI Agent,背后需要解决四类存储问题:

场景 存储需求 常见方案
向量检索(RAG) 高维向量 + 近似最近邻搜索 pgvector / 专用向量库
对话记忆 会话历史持久化、按 session_id 检索 KV 存储 / 关系表
知识库挂载 文档分块 + 元数据过滤 向量 + JSON 混合存储
工具调用结果 结构化中间结果缓存与回溯 关系表 + 时序记录

尹海文的核心观点是:Agent 的"记忆"和"工具"能力本质上是数据库问题,而不只是模型问题。当前很多 AI 应用不稳定,根源在于存储层设计草率——向量索引没有定期 vacuum、会话表没有 TTL 策略、工具调用结果没有落库导致无法排查。

他演示了一个最简的 Agent 记忆写入结构:

CREATE TABLE agent_memory (
    session_id  UUID,
    turn_index  INT,
    role        TEXT,          -- 'user' | 'assistant' | 'tool'
    content     TEXT,
    embedding   VECTOR(1536),
    created_at  TIMESTAMPTZ DEFAULT now(),
    PRIMARY KEY (session_id, turn_index)
);

-- 检索与当前输入最相关的历史轮次
SELECT content FROM agent_memory
WHERE session_id = :sid
ORDER BY embedding <=> :query_embedding
LIMIT 5;

Matthew Wong · 迁移周期的完整复盘

Automated System Ltd Delivery Manager
《中资数据库最佳实践成功案例分享》

图片

Matthew Wong 带来了香港本地企业在金融、政企、商贸行业的真实迁移经历。他把整个周期拆成四段,并指出每段最容易出问题的地方:

1. 前期评估:不要只评估 SQL 兼容率,要同时评估存储过程复杂度和应用层驱动的行为差异。他遇到过兼容率报告显示 98%,但剩下 2% 全集中在核心交易逻辑里的情况。

2. 迁移割接:建议保留双写阶段至少两周,用数据比对工具持续校验源端和目标端的行数与校验和,而不是只在割接当天做一次全量对比。

3. 上线运维:前三个月的慢查询分布与原系统通常有明显差异,需要重新做执行计划分析和索引调整,不能直接沿用原库的运维脚本。

4. 长期优化:国产数据库的版本迭代周期比海外商业产品快,需要建立内部的补丁评估流程,避免盲目升级引入新问题。

他对比了几项实测数据后指出,综合成本(许可证 + 运维人力 + 迁移工程量)上国产方案通常有优势,但前提是团队有足够的本地化支持渠道。


王丁丁 · 工业场景的数据异构问题

工业互联网数据库专家、公众号【IT 邦德】主理人
《多模+AI双轮驱动,筑牢数智时代的智慧数据底座》

图片

工厂的数据比互联网业务复杂得多,王丁丁列出了一条产线上可能同时产生的数据类型:

传统做法是给每类数据配一套专用系统,最终形成五六个数据孤岛,任何跨类型的分析都需要先做数据集成。他的观点是,多模引擎在工业场景的价值不在于性能极值,而在于减少数据搬运——异常检测模型需要同时读传感器时序和设备拓扑时,不用再写 ETL。

他提到一个预测性维护的查询示例:在关系表里定位"最近三天有异常告警的设备",再关联时序表取振动曲线,最后用向量相似度匹配历史故障案例——这三步在单库内完成,比跨库查询的响应时间低一个数量级。


付义 · 从兼容到融合的产品思路

电科金仓售前支持四部经理、解决方案专家
《不止于兼容,融合多模构筑坚实数智底座》

img

付义的分享切入了一个实际选型时容易模糊的问题:兼容性和融合能力是两件事

兼容性解决的是"能不能迁过来",衡量指标是 SQL 方言覆盖率、驱动适配程度、存储过程转换工作量。这是替换海外商业数据库的门槛,不是终点。

融合能力解决的是"迁过来之后能做什么",涉及多种数据模型能否在同一引擎内协同、AI 推理是否能直接读库而不需要中间层、运维工具链是否统一。他举了一个典型场景:金融风控系统同时需要关系型的交易记录、图模型的资金流向、向量模型的行为相似度,如果三套系统独立维护,实时风控的延迟会卡在数据同步上。

面向港澳市场,他也提到本地化支持响应速度是客户关注的实际问题之一,并就服务体系的设计逻辑做了说明。


圆桌讨论

分享结束后,ICO副总裁 Raymond Yiu、LPS资深技术专家 Steven Chen 与多位嘉宾参与了圆桌环节。讨论没有固定议程,主要围绕几个现场提出的问题展开:

  • 香港企业在选型国产数据库时,最大的顾虑是什么?
  • 本地技术团队的学习成本如何评估?
  • 国产数据库的生态(驱动、工具、第三方集成)目前覆盖到什么程度?

与会者的反馈比较坦率——认可度在提升,但工具链完整性和本地化文档质量仍是落地过程中的实际阻力。

图片

图片

图片

图片


六场分享覆盖了从架构设计到工程落地的不同层面,演讲者的背景差异也带来了不同角度的观察。对于关注多模数据库或国产数据库出海进展的读者,具体的技术细节或许比活动本身更值得关注。

Logo

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地,聚焦技能开发、插件实践与部署教程,为开发者提供可直接落地的方案、工具与交流平台,助力高效构建与落地 AI 应用

更多推荐