谈谈人大金仓数据库去年接了一个系统迁移的评估客户那边要求把核心业务库从 Oracle 换成国产数据库原因大家都懂许可证成本、信创要求、自主可控每一项都绕不开。当时摆在我面前的选择其实不少人大金仓、达梦、OceanBase、GaussDB 这些都有团队在用。我花了大概两周时间把金仓完整跑了一遍又把一个中等规模的 Oracle 库迁了过去这篇文章就是那段时间的实操记录和事后复盘。先说结论人大金仓KingbaseES给我的整体感觉是国产数据库里Oracle 兼容性做得最认真的一家。它不是简单套一层 PG 的壳再抄几个 Oracle 函数而是从语法、数据类型、存储过程、系统视图到开发习惯都做了一套完整的 Oracle 兼容模式。对于大量存量 Oracle 系统来说这直接决定了迁移成本是改几行配置还是重写一遍业务。这篇文章不吹不黑就讲讲我实际部署、迁移、踩坑过程中的真实体验给正在做数据库选型或者准备迁移的同学一个参考。1. 为什么大家都在重新打量人大金仓1.1 国产数据库的格局与金仓的定位国产数据库这几年冒出来很多但真正能在关键业务系统里扛事的其实就那几家。人大金仓KingbaseES是这里面资历最老的一批最早可以追溯到上世纪九十年代末由中国人民大学一批数据库领域的老师发起底子是国产863项目的研究成果。后来商业化运作现在属于中电科旗下。它和达梦经常被放在一起比较两者在信创市场里是直接的竞争对手。但从技术路线上看两者走的路线不太一样。达梦早年参考了 Oracle 的架构有自己的执行引擎和存储引擎兼容 Oracle 的力度也很强。金仓 KingbaseES 的内核则基于 PostgreSQL 发展而来在上面做了一层非常厚实的 Oracle 兼容层。这两条路线各有各的好处达梦在底层定制上更自由金仓则站在 PG 这个成熟内核的肩膀上在高并发、复杂查询、扩展生态这些方面有着天然优势。拿我自己的体验来说金仓给我的感觉更像是一个学会说 Oracle 方言的 PostgreSQL。你写惯了 Oracle SQL在金仓里基本可以无缝切换而你如果懂 PostgreSQL调优它的参数也不会觉得陌生。这种混合气质在国产数据库里其实挺讨巧的因为它同时吃到了两个生态的红利。1.2 金仓最核心的卖点Oracle 兼容模式金仓最核心的卖点是它的 Oracle 兼容模式。这一点我觉得怎么强调都不过分因为对于国内大量存量系统来说Oracle 的占比实在太高了。金融、电信、政务、能源这些行业的核心系统跑在 Oracle 上的比例相当惊人。现在政策要求国产化替代最现实的问题就是怎么把跑了好多年、代码动都不敢动的 Oracle 系统搬过来如果国产数据库的 SQL 语法和 Oracle 差得十万八千里那这个迁移成本就是天文数字。写好的存储过程要重写嵌在业务代码里的 SQL 要逐条改报表系统的查询脚本要重调想想就让人头大。金仓的 Oracle 兼容模式就是为了解决这个问题设计的。开启兼容模式之后它会在语法解析、数据类型、内置函数、系统视图、PL/SQL 行为等多个层面模拟 Oracle 的行为。不是说只支持几个常用的函数而是把 Oracle 开发者日常依赖的那些特性都覆盖到了这部分我会在下一节详细拆解。1.3 什么类型的项目更适合选金仓根据我这段时间的观察和使用体验金仓最适合的场景有三类。第一类是存在大量存量 Oracle 系统的替换项目。你有一个跑了好多年的 Oracle 库里面几十个存储过程、几百张表、几千条复杂 SQL要迁到国产库金仓绝对是第一梯队的候选。它的兼容层能帮你省掉大量改造工作有些系统甚至只改个连接串就能跑起来。第二类是政府和央国企的信创项目。这个不用多说金仓在党政、军工、能源这些领域的入围资质和落地案例都很全各种必要的认证和适配证明都是齐的走采购流程的时候会省很多麻烦。第三类是原本就在 PostgreSQL 生态里的新系统。如果你的应用本身就是基于 PostgreSQL 开发的那迁到金仓几乎是无感的它甚至还能提供一些 Oracle 兼容特性让你用得更顺手属于典型的向下兼容。反过来如果你的系统是 MySQL 系的金仓就不是最优选择了下面我会细说原因。2. 金仓与 Oracle 的兼容性到底能省多少事2.1 兼容性不是空话从 SQL 语法到 PL/SQL很多数据库厂商说兼容 Oracle实际也就是兼容个数据类型和几个函数一跑复杂的 PL/SQL 就露馅。金仓在这块做得算是比较深入的。先说 SQL 语法层面。Oracle 特色的语法比如ROWNUM伪列、CONNECT BY层次查询、MERGE INTO合并语句、MINUS集合操作在金仓的 Oracle 兼容模式下都是直接支持的。我之前把一个 Oracle 库里的报表查询拿过来跑里面有用CONNECT BY PRIOR做的树形结构查询在金仓里直接执行通过连改都没改。这要放在普通的 PostgreSQL 或者 MySQL 上光是层次查询就得费一番功夫用递归 CTE 重写。再说 PL/SQL。Oracle 的存储过程、函数、包Package、触发器这些在迁移中最让人头疼的部分金仓做了专门的兼容处理。它支持 PL/SQL 的语法风格包括DECLARE、BEGIN...END块、EXCEPTION异常处理、游标循环、%TYPE和%ROWTYPE属性这些。我实际迁移过一个带包的项目包里有十几个存储过程和函数互相调用还有PRAGMA EXCEPTION_INIT这种比较冷门的写法金仓也都支持。2.2 数据类型映射与隐式转换数据类型的兼容是迁移的基础这块金仓做了一张比较完整的映射表。常用的NUMBER、VARCHAR2、DATE、CLOB、BLOB都能找到对应的类型。比如NUMBER对应到 PostgreSQL 的NUMERICVARCHAR2对应VARCHAR高精度、可变长度这些语义基本保持一致。这里有个细节值得说一下Oracle 的VARCHAR2(char)默认是按照字节长度计算的而 PG 的VARCHAR(n)是按字符算的。金仓在处理这个差异时会根据参数配置来调整语义保证迁移过来的表不会因为中文字符导致字段长度不够、插入报错的问题。这个小坑我后面会专门讲。还有SYSDATE、DUAL这种 Oracle 开发者每天都在用的东西金仓也都在兼容层里实现了。你可以直接写SELECT SYSDATE FROM DUAL;不会报错。2.3 存储过程、触发器、包迁移的实际情况为了验证兼容性的成色我专门找了一个业务逻辑比较复杂的 Oracle 库做迁移测试。那个库里有一个比较典型的订单审批流程涉及十几张表、五个存储过程、两个包、三个触发器存储过程里有用到动态 SQL、自治事务、异常链传递这些特性。迁移过程比我想象的顺利。官方提供的迁移工具KDTSKingbase Data Transition Suite能自动把大部分 PL/SQL 代码转成金仓的语法自动转换率大概在百分之七八十。剩下需要手工调整的主要是两类一类是用了 Oracle 特有系统包的地方比如DBMS_SCHEDULER就是一个典型的例子这个目前需要用金仓自己的调度功能来替代另一类是非常规的语法写法比如某些隐式游标属性在复杂嵌套逻辑里的行为差异。触发器方面金仓支持BEFORE/AFTER INSERT UPDATE DELETE这些常规类型也支持INSTEAD OF触发器。我测了行级触发器里的:NEW和:OLD引用行为和 Oracle 基本一致。需要注意WHEN条件的写法有一点点差异但迁移工具会帮你转好。2.4 兼容性边界在哪里说完了好的也得说说边界。金仓的 Oracle 兼容模式虽然做得不错但也不是万能的有几个地方我实际测下来是存在差异的。首先是 Oracle 的CONNECT BY层次查询金仓虽然支持但在一些极端场景下比如循环检测、SIBLINGS排序行为可能和 Oracle 不完全一致。我建议迁移的时候把这类查询重点验证一遍不要想当然。其次是 Oracle 的分析函数金仓在常用函数上ROW_NUMBER()、RANK()、DENSE_RANK()、LAG()、LEAD()兼容得不错但如果你用了比较冷门的分析函数或者写了很复杂的窗口定义还是需要实际跑一下看结果对不对。还有 Oracle 的DBMS_OUTPUT.PUT_LINE这类调试输出在存储过程里大量使用的话迁移后日志输出格式会有所不同。最后是性能问题。兼容层本质上是在 PG 内核之上做了一层翻译某些复杂的 Oracle SQL 写法在金仓里可能无法生成最优执行计划。我遇到过一个很复杂的多表关联查询在 Oracle 上走 HASH JOIN 只要几十毫秒迁到金仓后优化器选择了 NESTED LOOP跑了几秒才出来。后来手动调整了查询 Hint 才算恢复正常。这一点大家务必做好心理准备语法兼容不代表性能也完全一致迁移后一定要做一轮完整的 SQL 性能回归。3. 从下载到初始化Docker 环境下跑起金仓的实测记录3.1 环境准备与镜像获取要做测试验证最方便的方式就是用 Docker 快速拉起一个实例。金仓官方提供了 Docker 镜像这一点比很多老牌国产数据库要友好得多省去了漫长的安装过程。我的测试环境是一台 8 核 16G 的 CentOS 7.9 服务器Docker 版本 20.10。拉取镜像的命令很简单docker pull kingbase/kingbase-es:v8需要注意金仓的 Docker 镜像不是拉下来就能直接用的得先准备 License 文件。你可以去金仓官网申请试用 License也可以找厂商销售要。没有 License 的话数据库服务会启动失败。这个环节建议大家提前准备好省得拉完镜像卡在起库阶段。拿到 License 后我把它放在了/opt/kingbase/license.dat这个路径下方便后续挂载到容器里。3.2 初始化参数与常用配置启动容器的时候需要关注几个关键参数。我用的是这样的启动命令docker run -d \ --name kingbase-test \ -p 54321:54321 \ -e DB_MODEoracle \ -e DB_USERsystem \ -e DB_PASSWORDkingbase123 \ -v /opt/kingbase/license.dat:/home/kingbase/license.dat \ -v /opt/kingbase/data:/home/kingbase/data \ kingbase/kingbase-es:v8这里有两个参数值得单独说明。第一个是DB_MODE。金仓支持oracle、pg、mysql三种兼容模式默认为oracle。我是来测 Oracle 兼容性的所以显式指定为oracle。如果你要测其他模式的兼容性改这个参数就行。第二个是数据目录的挂载。我把宿主机的/opt/kingbase/data挂载为容器内的数据目录这样即使容器删了数据也不会丢方便后续反复测试。端口方面金仓默认端口是54321要记得把宿主机的防火墙放通这个端口否则客户端连不上。3.3 客户端连接与基础验证容器启动后用系统自带的ksql命令行工具验证一下连接docker exec -it kingbase-test /home/kingbase/kingbase/bin/ksql -U system -d test输入密码后成功进入了命令行。试一下之前说的 Oracle 兼容特性SELECT SYSDATE FROM DUAL;输出正常返回了当前时间。再试一下ROWNUMSELECT ROWNUM, name FROM users WHERE ROWNUM 5;结果正常。基础验证通过说明 Oracle 兼容模式确实生效了。3.4 一个需要注意的坑字符集我在初始化的时候就遇到了一个很典型的坑默认字符集的问题。第一次建库的时候我没指定字符集结果建出来的数据库是UTF8编码这个本身没问题。但当我从 Oracle 迁移数据时源库是ZHS16GBK编码迁移工具在读取数据时出现了中文乱码的情况。解决方案是在建库时显式指定字符集。金仓支持GBK、UTF8等多种编码如果源库是 GBK那我建议建库时也用 GBK或者统一用 UTF8 然后在迁移工具里做编码转换。我当时图省事重建了实例指定为GBKCREATE DATABASE test WITH ENCODING GBK LC_COLLATE zh_CN LC_CTYPE zh_CN TEMPLATE template0;重新导入后乱码问题消失了。这里给新手一个建议在建库之前一定要先确认源库的字符集不要图省事用默认值不然后面迁移时各种乱码问题会让人怀疑人生。4. 从 Oracle/MySQL 往金仓迁数据完整链路实操4.1 迁移前评估与对象梳理迁移这件事最忌讳的就是上来就动手。动手之前一定要先做一次彻底的评估搞清楚你到底有哪些对象要迁。我习惯把评估清单分成五类表结构包括表、字段、约束、索引、分区、注释这些是迁移的基础。数据各表的数据量、大字段、特殊类型比如 RAW、XMLTYPE。逻辑对象视图、序列、存储过程、函数、包、触发器、物化视图。权限与用户角色、用户、对象授权、同义词SYNONYM映射。应用侧SQL 语句、ORM 映射、连接配置、定时任务Job。这份清单不只是给自己看的也是后续和业务方确认迁移范围的依据。我当时就是把清单整理出来发给项目组一项项和业务负责人确认这个表还有没有在用那个存储过程能不能停掉顺便还清理掉了一批僵尸对象省了不少迁移量。4.2 用官方迁移工具 KDTS 还是手工脚本金仓提供了一个图形化的迁移工具 KDTS安装在 Windows 或 Linux 客户端上都能用。它的工作模式很简单配好源库连接和金仓目标库连接选择要迁移的对象点开始就能跑。我实际用下来的感受是KDTS 在表结构、数据、序列、视图、常用约束这些常规对象上迁移成功率很高基本能做到一键迁移。但在存储过程、触发器、包这些复杂对象上自动转换率大概在七到八成剩下两成需要手工处理。所以我的建议是表结构和数据用工具迁复杂逻辑对象务必人工 review 一遍。工具转出来的代码虽然能跑但有时候逻辑会变味。比如 Oracle 的NVL函数在金仓里能直接兼容但某些DECODE嵌套很深的地方工具可能会转成比较冗余的CASE WHEN逻辑虽然等价可读性和性能都需要再看。4.3 典型 SQL 差异改造实录除了对象迁移应用侧 SQL 的兼容性改造也是重头戏。这里我挑几个实际遇到的高频差异大家以后迁移大概率也会碰到。分页查询差异Oracle 经典的分页写法是三层嵌套 ROWNUMSELECT * FROM ( SELECT t.*, ROWNUM rn FROM ( SELECT * FROM orders ORDER BY create_time DESC ) t WHERE ROWNUM 100 ) WHERE rn 80;这段 SQL 在金仓 Oracle 兼容模式下可以直接跑。但如果你的代码里写的是 MySQL 风格的LIMIT 80, 20在金仓的 Oracle 模式下是不认的需要改成SELECT * FROM orders ORDER BY create_time DESC LIMIT 20 OFFSET 80;或者统一用标准的FETCH FIRST 20 ROWS ONLY。这取决于你应用代码里的 SQL 风格迁移前最好统一口径。字符串拼接Oracle 用||拼接字符串这个金仓兼容模式支持SELECT first_name || || last_name FROM employees;但是如果你原来用的 MySQL 的CONCAT()函数在金仓 Oracle 模式里也是支持的不过要注意参数数量。CONCAT在 Oracle 里只吃两个参数多层拼接需要嵌套MySQL 可以传多个参数。如果你迁移的是 MySQL 系的 SQL建议把所有CONCAT(a, b, c)改成CONCAT(CONCAT(a, b), c)避免踩坑。NVL和IFNULLOracle 的NVL(expr, default)金仓直接支持。MySQL 的IFNULL在金仓里也能用但不是标准函数建议统一改成COALESCE或者NVL省得以后维护的人精神分裂。TO_DATE/TO_CHAR这两个函数金仓支持度和 Oracle 基本一致格式串如YYYY-MM-DD HH24:MI:SS也兼容良好。不过我遇到过一个小坑Oracle 对两位年份RR的解析规则和金仓有细微差异如果代码里用了TO_DATE(..., RR-MM-DD)这种老式格式迁移后最好专门验证一下边界年份的解析结果。4.4 数据校验与业务回归数据迁完之后千万别急着宣布迁移完成。数据校验和业务回归这一步一定要做扎实。我的校验方法是三层第一层是行数校验。每张表在源库和目标库分别SELECT COUNT(1)对比数量是否一致。数据量特别大的表用并行方式数这个不难。第二层是抽样校验。对每张表随机抽几十条记录逐字段对比。我用 SQL 做了个差集查询用主键关联把不一致的记录捞出来。这里要特别注意大字段比如 CLOB、BLOB因为它们最容易在迁移过程中出问题。第三层是业务回归。这是最花时间也最重要的一步。把应用的典型业务链路完整跑一遍从登录、查询、下单、审批到报表输出结合之前梳理的评估清单逐项确认。我当时拉着业务方把所有核心流程都走了一遍前前后后花了三天确实发现了一个触发器逻辑问题——工具转换时把WHEN (NEW.status P)的时机弄错了导致状态流转异常。这种问题只有通过业务回归才能发现纯靠数据校验是查不出来的。5. 那些文档里不会写的坑语法细节与运维注意事项5.1 空字符串与 NULL 的处理差异这个坑我觉得有必要单独拿出来说因为它在所有从 Oracle 迁到其他数据库的项目里几乎都会碰到而且特别隐蔽。Oracle 有一个臭名昭著的特性空字符串会被当成NULL处理。也就是说INSERT INTO t (name) VALUES ()之后你查询name IS NULL会返回真name 永远查不到任何记录。PostgreSQL 则严格区分空字符串和NULL就是NULL就是NULL。金仓在 Oracle 兼容模式下做了特殊处理模拟了 Oracle 的行为。但问题来了如果你在金仓的 PG 模式下操作比如某些管理系统直接用了 PG 模式建库那空字符串和NULL就是分开的。这就容易造成同一套代码在不同模式下行为不一致。我的建议是在迁移前先和开发团队确认业务代码里有没有依赖空串等于 NULL这个 Oracle 特性的地方如果有迁移时要么统一改代码要么让 DBA 把金仓的兼容参数调成符合 Oracle 行为的模式。5.2 大小写敏感一个长期存在的认知盲区Oracle 在没有引号的情况下表名和字段名会被自动转为大写。PostgreSQL 则是先转小写。这个差异导致了很多人在迁移后遇到表不存在的错误。举个实际的例子Oracle 里你建了张表CREATE TABLE Student (...)在 Oracle 里这张表的真实名称是STUDENT因为没加引号你就建了个大写的表。迁移到金仓后如果保持 Oracle 兼容模式金仓也会模拟这个行为把名称处理成大写你现有的 SQL 不用改。但如果你在金仓里用 PG 模式新建表按习惯写了CREATE TABLE Student那这张表实际存储的名字是小写student。这时如果应用代码里写的是SELECT * FROM STUDENT就会因为找不到表而报错。处理办法有两种一是统一约定所有建表语句都用小写代码里也用小写二是从 Oracle 迁移过来的表保持大写语义不动让金仓的兼容层去处理。我个人的建议是既然要迁到金仓就趁机把大小写敏感的问题彻底规范化所有新写的 SQL 都统一用小写旧代码里依赖大写的逻辑重点排查。5.3 主备同步与备份恢复生产环境肯定要考虑高可用和容灾。金仓支持物理流复制和逻辑复制两种主备同步机制这一点继承了 PostgreSQL 的优良传统。物理流复制和 PG 的原生流复制使用方式很像需要在主库配置wal_level replica、创建复制用户、设置pg_hba.conf允许备库连接然后备库通过pg_basebackup拉取初始数据再配置 standby 模式。我按照 PG 的经验在测试环境搭了一主一备整个流程走下来没有遇到什么障碍。备库支持只读查询还能在主机宕机后手动提主日常运维基本足够。备份恢复方面金仓提供了sys_backup工具功能类似 Oracle 的 RMAN支持全量、增量和归档日志备份支持恢复到指定时间点PITR。我用它做过一次全量备份加增量恢复的演练整个流程还算顺利。这里给个建议新上的金仓环境备份恢复的演练一定要做不要等到生产事故了才第一次尝试恢复流程。数据库这种系统平时不练兵战时必掉链子。5.4 性能调优的几个切入点金仓数据库性能调优的思路和 PostgreSQL 基本一脉相承关键参数也就那么几个shared_buffers、work_mem、effective_cache_size、maintenance_work_mem、wal_buffers等等。拿一个 16G 内存的物理机举例我一般习惯这样配置参数建议值说明shared_buffers4GB约内存的 25%不宜过高work_mem64MB排序和哈希操作使用复杂查询可调高maintenance_work_mem1GB建索引、VACUUM 等维护操作使用effective_cache_size12GB告诉优化器系统可用缓存有多少max_connections200按应用实际并发连接数调整和 Oracle 相比金仓 / PG 系数据库有一个特点work_mem是每个排序或哈希操作独立分配的如果你同时跑了 100 个复杂查询每个都用 64MB那内存很快就会被打爆。所以这个参数要结合并发量谨慎设置不要拍脑袋给个很大的值。另外金的统计信息收集用ANALYZE命令和 PG 一致。我遇到过一次查询计划走偏的情况跑一下ANALYZE就好了。迁移后的大表第一次查询前务必先收集统计信息不然优化器对数据分布一无所知很容易选错执行计划。6. 什么人适合上金仓选型建议与最终心得6.1 金仓适合哪些场景不适合哪些场景聊了这么多技术细节最后说说选型层面的事。我见过不少团队在选型时只看功能清单忽视自身的实际情况最后落地阶段到处碰壁。根据我这段时间的使用经验适合用金仓的团队通常具备几个特征第一业务系统主要是 Oracle 存量或者需要深度兼容 Oracle 语法。这是金仓的主场。你在 Oracle 生态积累的代码、经验、运维习惯大部分都能平移过来。第二团队对 PostgreSQL 体系有一定了解。因为金仓的内核就是 PG如果你团队里的 DBA 懂 PG那么日常运维、参数调优、问题排查都轻车熟路。哪怕之前主要搞 Oracle只要愿意学习 PG 的运维思路上手金仓也不会太难。第三项目对信创合规有明确要求需要走国产化采购流程。反过来如果你是下面的情况金仓就不一定是最优选择一是你的系统是 MySQL 系的。金仓虽然提供 MySQL 兼容模式但它不是主力和原生 MySQL 的生态环境读写分离方案、中间件、工具链还是有差距。这种情况不如考虑 TiDB、OceanBase 这种更贴 MySQL 生态的方案。二是项目追求极致的 PostgreSQL 特性。如果你天天用 PG 的 JSONB、数组类型、GIN 索引、扩展插件这些高级特性直接用原生 PostgreSQL 体验会更好。金仓的 PG 模式虽然也能用但毕竟多了一层封装某些冷门特性的支持度不会比原生 PG 更快。三是团队没有专职 DBA全靠开发兼职运维。这种情况我建议优先选择云数据库产品让云厂商帮你承担运维压力。金仓这类商业数据库虽然也有技术支持但内部细节仍然需要一定专业知识来兜底。6.2 团队需要具备什么能力迁移到金仓之前团队的能力建设一定不能落下。我结合自己带项目踩坑的教训总结了三项必备能力。第一是 SQL 改写能力。不要求每个人精通 PL/SQL但至少要能看懂 Oracle 的存储过程和函数知道哪些写法需要改造。最常见的差异分页、字符串拼接、日期函数、空值处理团队里至少要有一个人能快速识别并给出标准改法。第二是性能调优能力。金仓的执行计划查看方式和 Oracle 很像都是 EXPLAIN。PG 系的执行计划输出格式比 Oracle 更直观一些但优化思路是通用的。团队里至少要有一个人能看懂执行计划会识别全表扫描、嵌套循环、哈希连接这些基本操作不然遇到慢查询就两眼一抹黑。第三是数据校验能力。迁移过程中数据一致性是最容易出问题的环节。团队需要掌握 COUNT、抽样比对、主键冲突检测这些基本方法并且在迁移前就设计好校验方案而不是等迁移完了才临时想怎么验证。6.3 我个人用下来的整体评价最后聊聊我个人的真实评价不吹不黑。人大金仓 KingbaseES 是国产数据库里我个人比较看好的一款。它的综合成熟度、Oracle 兼容性、生态配套迁移工具、运维工具、官方文档在国产库里都属于第一梯队。尤其是 Oracle 兼容层这个核心卖点确实解决了很多存量系统迁移的大难题。但它也不是万能的。它的上限是被 PostgreSQL 内核锁定的你不能指望它跑出比原生 PG 更炸裂的性能它的 Oracle 兼容层也不是百分百完美复杂逻辑迁移后必须仔细回归它的生态和工具链还在持续完善中一些周边能力中间件、监控、运维平台不如 Oracle、MySQL 这些老牌数据库成熟。我的建议是不要被国产化这个词绑架也不要用能用的标准来要求它。在关键系统上使用一款数据库之前请务必用生产标准去做完整的测试验证——主备切换演练做过没有备份恢复流程跑通过没有性能压测数据达标没有这些问题有了确定的答案你才真正具备了说可以上生产的底气。就我的实测感受来说金仓这个数据库是值得你花时间去了解和评估的。它能走多远一方面看厂商自己的迭代速度另一方面也看社区和用户的反馈推动。作为技术人保持开放的心态把每款产品放在真实的业务场景里去检验比在网上听人云亦云要靠谱得多。