一、那些年我们搭过的烟囱
先说说传统企业IT架构里最常见的烟囱式数据库。什么叫烟囱式？就是每上一个新业务、新需求，就单独搭一套数据库，各搞各的，互不连通，像一根根烟囱一样竖着。
1.1 我见过的架构，一个系统七套数据库
我前几年见过最夸张的架构------一套电商系统，前后用了七种数据库：
- 订单、用户、商品这些核心交易数据放MySQL
- 商品详情、用户评论这些半结构化的存MongoDB
- 购物车、会话、热点数据缓存跑Redis
- 全文检索商品搜索，单独搭了一套Elasticsearch
- 门店地理位置、配送范围计算，用了一套空间数据库
- 日志、监控数据，又搞了一套时序数据库
- 最近搞AI推荐，又加了一套向量数据库
感觉每天的工作就剩下运维了，报各种问题，MySQL主从延迟了去处理一下，MongoDB分片不均了去挪一下，Redis内存满了去清一下，等等这些，像每次出性能问题，各个数据库厂商的技术支持互相甩锅：MySQL的说是MongoDB拖的，MongoDB的说是Redis缓存没做好，Redis的说是底层存储不行。最后的话，还是运维来抗事
1.2 烟囱架构的四大原罪
这些年看下来，烟囱式数据库架构的问题，总结起来就是四大原罪，一个比一个致命。
第一罪：运维成本爆炸
每套数据库都有自己的部署方式、参数体系、监控工具、备份策略。你得懂MySQL的主从复制，还得懂MongoDB的分片集群，还得懂Redis的持久化机制，还得懂ES的分片副本......
人的精力是有限的，一个DBA能精通两三种数据库就不错了，七八种根本顾不过来。最后就是什么都懂一点，什么都不精，出了问题只能瞎试。
人力成本、学习成本、工具成本，加起来是一笔巨大的开销。很多企业没算过这笔账，以为数据库本身免费就省钱，其实运维成本才是大头。
第二罪： 数据孤岛 严重
数据散在各个库里，互不相通。用户基本信息在MySQL，用户行为日志在MongoDB，用户画像标签在Redis，用户地理位置在GIS库。
想做一个完整的用户视图？对不起，你得从各个库里把数据捞出来，在应用层拼起来。数据同步、格式转换、字段映射，一大堆麻烦事。
数据不一致更是家常便饭。同一个用户，MySQL里的手机号是一个，MongoDB里的又是另一个，Redis缓存里的还是旧的。到底哪个是准的？没人说得清。
第三罪：资源浪费严重
每套数据库都得单独配服务器、配存储、配网络。MySQL一套机器，MongoDB一套机器，Redis又一套机器。
但实际情况呢？MySQL白天忙，MongoDB晚上批量写入的时候忙，Redis高峰期忙，低谷期又闲着。资源没法共享，峰谷没法互补，大量计算和存储资源都浪费了。
我算过一笔账，很多企业的数据库服务器，平均CPU利用率不到20%，存储空间利用率不到30%。花了买十台机器的钱，实际只用了两三台的能力。
1.3 AI时代，烟囱架构彻底走到头了
如果说以前烟囱架构还能凑合着用，那到了AI时代，这套玩法彻底玩不转了。因为AI应用需要的数据类型太多了。
我今年接触的好几个搞AI应用的团队，都卡在了数据基础设施这一关。算法模型不是问题，大模型调用不是问题，问题是底层数据散在各个地方，根本没法高效地喂给模型。
这就是为什么我越来越觉得，融合数据库是AI时代的必然趋势。把多种数据模型统一到一套引擎里，用一套架构管所有数据，这才是AI时代该有的数据库形态。
二、初识金仓KES融合架构：从MongoDB迁移说起
这次去制造业客户那里，本来只是个MongoDB迁移项目。
客户的MongoDB集群用了快六年，三个分片节点，存了十几TB的设备日志和传感器数据。问题越来越多：运维复杂、查询慢、和关系型数据打通困难、做AI分析还要再导一遍数据。
他们一开始的想法很简单：找个性能更好的文档数据库替换掉MongoDB就行。
结果我给他们看了金仓KES的方案，他们的技术总监看完第一反应是："还有这种操作？"
2.1 什么是KES-AI时代融合数据库架构
简单说，金仓KES的融合架构，就是在同一个数据库引擎里，同时支持多种数据模型。
关系型数据、文档型数据、向量数据、GIS空间数据、全文检索......这些以前需要好几套数据库才能搞定的数据类型，在金仓KES里，一套引擎全部搞定。
注意，不是在一个数据库产品里塞了好几个独立的引擎，那种叫"多引擎拼盘"，本质还是烟囱。
金仓KES是真正的一体化存储，底层共享同一套存储引擎、同一套事务机制、同一套优化器、同一套运维体系。各种数据模型只是上层的不同接口，底层是打通的。
这意味着什么？
意味着你可以在一条SQL里，同时关联查询关系表、文档集合、向量数据、空间数据，而且这些查询在同一个事务里，保证ACID一致性。
意味着你不用再搞什么数据同步、ETL、数据管道，所有数据就在一个库里，天然就是一致的。
意味着你只需要一套运维体系、一套监控、一套备份，运维成本直接砍一大截。
2.2 第一次看到文档引擎的时候，我是怀疑的
说实话，最开始听说金仓KES有文档引擎，能兼容MongoDB的协议，我是持怀疑态度的。
我见过太多所谓的"兼容"，表面上语法差不多，实际用起来到处是坑，性能差、功能不全、语法不兼容，最后迁移完还得改一大堆代码。
所以这次迁移，我特意挑了客户最复杂的一个业务模块来做验证------设备数据采集模块，用了MongoDB的聚合管道、索引、事务，还有不少MongoDB特有的语法。
我心想，要是这个模块能0代码迁过去，那才是真的兼容。
结果让我挺意外的。
我们把MongoDB的连接地址改成金仓KES的文档引擎地址，应用代码一行没改，启动、运行、查询、写入......居然全跑通了。
我当时还不太信，特意找了几个复杂的聚合查询对比了一下结果，数据完全一致，性能甚至比原来的MongoDB还快一些。
客户的开发负责人当时说了句挺实在的话："我本来以为至少要改两周代码，结果半天就切过去了？"
2.3 0代码修改迁移到底是怎么做到的
很多人会好奇，0代码修改迁移MongoDB，这是怎么做到的？
其实原理不复杂。金仓KES的文档引擎，在协议层面兼容了MongoDB的驱动协议。
也就是说，你的应用原来用MongoDB的官方驱动连接，现在不用换驱动、不用改代码，只需要把连接地址改成金仓的地址，就能直接连上去用。
三、深度拆解：KES一体化存储到底融合了什么
聊完了迁移的直观感受，我们往深了挖一挖，金仓KES的一体化存储，到底融合了哪些数据模型？每一种是怎么实现的？实际用起来怎么样？
我结合这次项目的实际使用体验，给大家一个个讲。
3.1 关系型引擎：底子最扎实的基本功
作为一个传统关系型数据库出身的产品，金仓KES的关系型引擎底子是最扎实的。
ACID事务、SQL标准支持、索引优化、存储过程、触发器......这些传统关系数据库该有的能力，金仓都有，而且做得很成熟。
毕竟是做了这么多年的商用闭源数据库，在关系型这块，稳定性和性能都是经受过政企核心系统考验的。
这次项目里，客户的生产工单、设备台账这些结构化数据，原来就是在MySQL里的，我们也一起迁到了金仓的关系引擎里。
迁移过程很顺利，SQL兼容性很高，大部分SQL不用改就能跑。性能方面，复杂查询的优化器做得不错，比原来的MySQL快了不少，尤其是多表关联的报表查询，提升很明显。
3.2 文档引擎：MongoDB的平替，还能和关系表打通
文档引擎是这次迁移的主角，也是我感受最深的一个模块。
前面说了，协议级兼容MongoDB，应用0代码就能迁过去。这个我就不再重复了。
我重点说说文档引擎和关系引擎打通这件事，我觉得这才是融合架构真正厉害的地方。
什么叫打通？就是你可以用 SQL 直接查询文档集合 ，也可以在文档查询里关联关系表。
举个例子，设备数据存在文档集合里，设备台账存在关系表里。以前你要查"某车间所有设备的最新传感器数据"，得先从关系表查出车间的设备列表，再去文档库查每个设备的数据，应用层拼起来。
现在呢？一条SQL就搞定了，直接关联查询文档集合和关系表，数据库层面就给你拼好了。
而且这一切都是在同一个事务里的。
以前你要同时更新关系表和文档数据，得搞分布式事务，麻烦得要死，还不一定能保证一致性。
现在呢？都在一个库里，同一个事务，该提交提交，该回滚回滚，ACID天然保证。
这才是融合的真正价值------不是简单地把两种数据模型塞到一个产品里，而是让它们真正打通、真正融合、真正能互相查询、真正能在同一个事务里保证一致。
3.3 向量引擎：AI时代的标配，不用再单独搞向量数据库
这两年AI火了，向量数据库也跟着火了。
很多团队搞AI应用，上来就先搭一套向量数据库，把文本转成embedding存进去做语义检索。
可向量数据库单独一套，又多了一个烟囱，又多了一套运维，又要搞数据同步，又要保证一致性。
金仓KES把向量引擎也做进了融合架构里。
你可以直接在金仓里建向量字段、建向量索引、做相似度查询，跟普通的字段没什么区别。
而且向量数据和关系数据、文档数据都在一个库里，天然打通。
比如你做一个智能客服的知识库，FAQ的基本信息存在关系表里，原文存在文档字段里，向量embedding存在向量字段里。
用户提问的时候，先做向量相似度检索，找到最相关的几条FAQ，再关联查询关系表和文档字段的信息，一起喂给大模型。
整个过程一条SQL搞定，都在一个库里，都在一个事务里，不需要跨库、不需要同步、不需要额外的向量数据库。
这次客户也在规划做设备故障的智能诊断，打算用金仓的向量引擎来存故障案例的embedding，以后设备出问题了，直接做相似度检索找相似案例。
不用再单独搭一套向量数据库，省了不少事。
3.4 GIS引擎：空间数据也能一起管
还有一个很多人想不到的------金仓KES还内置了GIS空间数据引擎。
地理位置、空间坐标、路径规划、区域计算......这些以前得单独用一套空间数据库才能搞定的事，现在金仓里直接就能做。
这次客户的项目里，就有设备地理位置管理的需求。以前设备坐标存在MongoDB里，算个距离、查个范围内的设备，特别麻烦，性能也差。
迁到金仓之后，直接用GIS字段存坐标，建空间索引，各种空间查询、空间计算直接用SQL就能做，又快又方便。
而且设备的空间数据和设备的台账数据、传感器数据都在一个库里，关联查询特别方便。
3.5 不止这些：全文检索、时序、JSON......
除了上面说的这几个，金仓KES的融合架构里还有不少其他的数据模型支持。
比如全文检索，不用再单独搭ES了，数据库里直接建全文索引、做全文搜索；
比如时序数据处理，物联网、监控场景的时序数据也能高效存储和查询；
比如JSON类型支持，半结构化数据直接存、直接查。
当然了，不是说每一种都能完全替代对应的专用数据库。特别极端的场景、特别大的量级，专用数据库肯定还是有优势的。
但对于绝大多数企业级应用来说，金仓KES的这些多模能力，完全够用了。
关键是，用一套数据库搞定80%的场景，比用八套数据库搞定100%的场景，成本要低得多，运维要简单得多，一致性要好得多。
四、多集群架构：不止融合，还要高可用和弹性
融合架构解决了数据孤岛和运维成本的问题，那业务连续性和弹性扩展呢？
这就得说说金仓KES的多集群架构了。
4.1 传统主从架构的痛点
以前的数据库高可用，大多是主从架构------一主一从或者一主多从，主库挂了从库顶上。
这种架构用了很多年，但问题也不少：
- 主库挂了切换有延迟，业务还是会断一会儿；
- 读写分离要在应用层做路由，麻烦得很；
- 扩容只能垂直扩，加CPU加内存，上限很低；
- 主库压力大的时候，从库同步也会慢，数据延迟越来越大。
对于核心业务系统来说，这些问题都是不可接受的。
4.2 金仓的多集群架构是怎么回事
金仓KES的多集群架构，简单说就是多个数据库节点组成一个集群，共同提供服务。不是简单的主从，而是真正的分布式集群架构。
就像这次客户的项目，我们就给他们搭了三节点的多集群架构，原来的MongoDB是三节点分片副本集，运维起来特别麻烦，分片均衡、数据迁移、节点故障处理等等很多问题，换成金仓的多集群之后，运维简单多了，集群状态一目了然，节点故障自动恢复，扩容也方便。
4.3 业务连续性的真实体验
我们做压测的时候，故意把一个节点给停了，想看看集群的容错能力。然后应用那边完全根本就没感受到，请求照常处理，响应时间也没什么波动。后来我们去监控上看了下，那个节点的流量自动切到了其他节点上，整个过程很短很短。然后那个运维当时就说，这要是我们原来的MongoDB，挂一个节点起码得忙半小时。
这就是多集群架构的价值------业务连续性有保障，运维省心，扩容方便。对于核心业务系统来说，这一点太重要了。
五、融合架构到底能省多少钱
5.1 硬件成本
原来客户的架构，这里一共是14台服务器
- MySQL：3台服务器（1主2从），每台32核64G，2TB SSD；
- MongoDB：6台服务器（3分片，每分片1主1从），每台32核64G，4TB SSD；
- Redis：3台服务器（1主2从），每台16核32G，512G内存；
- GIS数据库：2台服务器，每台16核32G，1TB SSD。
换成金仓KES多集群架构之后，就6台，就可以搞定所有数据类型
- 金仓集群：6台服务器，每台32核64G，4TB SSD。
就像原来的每套数据库都有自己的峰谷，有的白天忙，有的晚上忙，资源没法互补，而现在的话都在一个集群里，资源池化了，峰谷互补，整体利用率高了很多，而且少了八台服务器，机房机位、电费、网络设备，这些也都省了，博主大概估算了一下，光是硬件成本，就省了一半多了。
5.2 运维成本
原来的架构，至少需要两个专职DBA，分别管不同的数据库，还经常忙不过来。
现在一套数据库，一个DBA就能管过来，而且工作量还比以前小。
一个DBA的年薪是多少？大家心里都有数。少养一个人，一年就省几十万；少养两个人，就是上百万。
这还没算培训成本、工具成本、出故障的损失成本。
5.3 隐性成本
这个就不好用钱直接衡量了，但我觉得价值最大。
以前数据散在各个库里，不一致是常态，业务部门天天来找，说这个数不对那个数不对，IT部门天天擦屁股。
现在所有数据都在一个库里，天然一致，再也不用对数据了。
业务部门放心，IT部门省心，这种价值是没法简单用钱算的。
还有开发效率。以前开发一个新功能，得考虑数据存哪个库、怎么同步、怎么关联，光架构设计就得讨论好几天。
现在不用想了，都在一个库里，想用什么模型用什么模型，直接关联、直接查询，开发效率高了不止一倍。
六、迁移实战经验：从MongoDB到金仓KES的完整流程
聊了这么多架构和概念，最后给大家来点实在的。结合这次MongoDB迁移的实际经验，给大家讲讲完整的迁移流程和注意事项，以后你们自己迁的时候可以参考。
6.1 第一步：评估和选型
迁移之前，先做评估。
- 你的业务用了MongoDB的哪些功能？是不是都是常用功能？
- 数据量有多大？QPS有多高？性能要求是什么？
- 有没有什么特别偏门的用法、特别复杂的聚合？
评估完了，再看金仓的文档引擎能不能满足需求。
一般来说，常规的CRUD、索引、聚合管道、事务，这些都没问题。
特别复杂的、特别底层的操作，可能需要做一些验证。
这次客户的评估，我们花了两天时间，把他们最复杂的二十个查询拿出来做了验证，全部通过，性能还优于原来的MongoDB，这才决定迁。
6.2 第二步：搭建环境和数据迁移
环境搭建很简单，金仓的安装部署有标准化的工具，跟着文档走就行。
多集群架构的搭建也不复杂，配置好节点信息，初始化集群，很快就能搭好。
数据迁移有几种方式：
- 全量迁移：用迁移工具把MongoDB里的数据全量导到金仓；
- 增量同步：全量迁完之后，再同步增量数据，保证两边数据一致；
- 双写过渡：迁移期间应用同时写两边，切流之后再停掉旧的。
具体用哪种方式，看你的业务情况。
停机时间窗口大的，直接全量迁移最简单；不能停机的，就得做增量同步或者双写。
这次客户的设备数据，因为可以凌晨停写，我们就用了全量迁移的方式，几个小时就迁完了。
6.3 第三步：应用切换和验证
数据迁完之后，就可以切应用了。把应用配置里的MongoDB连接地址，改成金仓文档引擎的地址，重启应用就完事了。代码一行不用改，这是最爽的。
切完之后，一定要做全面验证，所有功能点都跑一遍，看看有没有问题，并且抽样对比两边的数据，确保一致之后，再跑一下压测，看看性能是不是满足要求。
6.4 第四步：优化和调优
金仓有自己的优化器和参数体系，迁过来之后，可以根据业务特点做一些针对性的调优，比如索引优化、参数调整、SQL改写等等。
很多时候，调优之后，性能还能再上一个台阶。
这次客户的系统，迁过来之后默认配置就比原来快了，我们又做了一轮索引优化和参数调优，整体性能又提升了30%左右。
客户的技术总监说，这相当于免费升了一级硬件。
七、个人感悟与全文总结
最早的时候，大家都用关系数据库，什么数据都往里面塞。
后来数据类型越来越多，关系数据库不够用了，就开始分，各种NoSQL、NewSQL、专门数据库冒出来，越分越细，越分越多。
分到最后，大家发现不对了，烟囱太多、运维太苦、一致性太难、成本太高，于是又开始往合的方向走。
融合数据库、多模数据库，就是这个"合"的产物。
AI时代的到来，更是加速了这个"合"的进程。
AI需要的数据类型太多了，关系、文档、向量、图像、音频、视频......你不可能每一种都搞一套数据库，然后在上面搭个超级复杂的融合层。
必须有一个统一的底座，一套架构管所有数据，这就是融合数据库的历史使命。
金仓KES的融合架构，是在AI时代的新需求下，走出了自己的路。
多模一体化、协议级兼容、多集群架构、向量引擎内置......这些东西，不是简单抄就能抄来的，是需要真正的内核研发实力的。