金仓KingbaseES数据库深度解析：从“跟跑者“到“并跑者“的国产数据库突围之路

Lethehong

已于 2025-06-18 19:01:23 修改

阅读量1.1w

点赞数 79

CC 4.0 BY-SA版权

分类专栏： MySQL 文章标签：数据库 KingbaseES 金仓数据库

于 2025-06-17 20:32:13 首次发布

本文链接：https://blog.csdn.net/2301_76341691/article/details/148722781

MySQL 专栏收录该内容

6 篇文章

订阅专栏

🌟 嗨，我是Lethehong！🌟

🌍 立志在坚不欲说，成功在久不在速🌍

🚀 欢迎关注：👍点赞⬆️留言收藏🚀

🍀欢迎使用：小智初学计算机网页IT深度知识智能体

🚀个人博客：Lethehong有一起互链的朋友可以私信我

✅GPT体验码：https://gitee.com/lethehong/chatgpt-share

✅GPT体验码：私信博主~免费领取体验码

写在前面：数据库江湖的格局正在悄然改变

说起数据库，大家第一反应可能还是Oracle、MySQL、SQL Server这些"老外"的产品。确实，这些年来，国外的数据库产品几乎垄断了整个市场，Oracle占据企业级市场的半壁江山，MySQL在互联网领域称王称霸，微软的SQL Server在Windows生态里如鱼得水。

但是，风向正在改变。

中电科金仓（北京）科技股份有限公司成立于1999年，是成立最早的拥有自主知识产权的国产数据库企业，这家低调了20多年的公司，最近几年开始频频出现在各大新闻头条里。近日，金仓数据库KingbaseES V9凭借技术创新、性能优化等方面卓越表现，在关系型数据库类荣获"2024年度技术卓越奖"。

为什么突然之间，大家都开始关注国产数据库了？答案很简单：这三个字，让所有人都清醒了。

从华为被制裁开始，到后来各种技术封锁，大家才发现，原来我们在基础软件领域有这么多的"软肋"。数据库作为信息系统的心脏，如果被人掐住了脖子，那后果不堪设想。

如何驾驭金仓

官网地址： https://bbs.kingbase.com.cn/index

今天就替大家简单的体验一下金仓。

第一步：登录之后，将鼠标移动到“服务于支持”会自动出现下面的选项，咱们点击“体验中心”下面的“KingbaseES在线体验平台”即可进入体验平台。

进来之后，会看到图下的这样页面，会提供一个体验平台兼容模式的选项，大家可自行进行选择。然后咱们继续点击“开始体验”按钮，进入体验。

页面还是很友好，点击复制按钮，右边的输入框就可直接填写，甚至不用我们自己去粘贴，这一点我还是很喜欢的

这篇文章深度聊点不一样的，代码实操部分在告别“卡脖子“！国产数据库金仓全面替代Oracle，从“被卡脖子“到完全自主可控-CSDN博客

这篇文章，大家可以去观看

二十五年磨一剑：金仓的"长征路"

说起金仓，这可不是一个"蹭热点"的新玩家。人家早在1999年就开始干这件事了，那时候大部分互联网公司还没成立呢。

当年创立金仓的那群人，其实有着很强的"理想主义"色彩。他们觉得中国不能永远依赖外国的数据库，总得有自己的产品。但是理想很丰满，现实很骨感。做数据库这件事，真的太难了。

数据库不像做个APP或者网站，几个月就能搞出来。这是一个需要十几年、甚至几十年积累的技术活儿。你要保证数据不丢失、查询够快、并发能力强、兼容性好，每一个要求都是技术上的"珠穆朗玛峰"。

最难的是什么？是生态。

即使你的技术再好，但是没有人用，没有开发者愿意基于你的数据库开发应用，没有企业愿意把核心业务放在你的数据库上，那你就是个"孤岛"。Oracle和MySQL之所以这么牛，不只是因为技术好，更因为它们有庞大的生态圈。

金仓这些年就是在干一件事：一边把技术做扎实，一边慢慢建设生态。

从最初的KingbaseES V1到现在的V9，金仓数据库管理系统KingbaseES V9最新版本KingbaseES V009R001C002B0014正式发布。新版本在兼容性、可用性、性能以及安全性等多个方面进行了全面升级。这20多年，他们就像个"苦行僧"一样，一个版本一个版本地迭代，一个bug一个bug地修复，一个客户一个客户地服务。

技术深度解析：金仓到底有多少"真功夫"

聊了这么多背景，咱们来看看金仓在技术上到底有多少"真功夫"。

MySQL调优及评测

优化1，调整IO相关配置

分析：初始默认配置下，CPU利用率只有45%左右，大概在8万TPMC，通过分析资源等待情况，判断是IO问题。

优化点：增加数据文件、日志文件的缓存大小，增加配置如下：

key_buffer_size=2G
max_allowed_packet=5G
read_buffer_size=2G
read_rnd_buffer_size=2G
sort_buffer_size=2G
join_buffer_size=2G
net_buffer_length=5G
tmp_table_size=16G
thread-cache-size =100
innodb-thread-sleep-delay=0

效果：通过增加缓存优化了磁盘读写数据，性能提升两倍。

优化2：缓解binlog资源等待

分析：再次观察系统资源情况，CPU利用率上升到50%左右，IO和网络没有压力，怀疑关键瓶颈是数据库内部的资源等待。检查MySQL当前等待事件：

发现等待事件中最长的是binlog，虽然其时间比例在总时间中占比较低，但是数据库内部的等待视图看不到其他明显的问题，所以我们决定调整binlog相关的配置。

优化点：基于上述分析，我们将binglog设置为异步刷新，并且将日志级别设置为row来降低写入量。

效果：执行测试后重新检查等待事件，binlog等待已得到明显改善，tpmC也有了一定的提升。

优化3：自旋锁优化

分析：再次观察系统资源情况，CPU利用率依然在50%左右，IO和网络没有压力，怀疑关键瓶颈是数据库内部的资源等待。但是数据库内部的等待事件列表已经看不出明显的问题，我们转而通过perf来继续查找根因，发现存在ut_delay的热点函数，所以判断是自旋锁相关的使用存在问题：

优化：重新调整自旋锁相关的delay以及loops等参数。

innodb-spin-wait-delay=2
innodb-sync-array-size=1024
innodb-sync-spin-loops=30
innodb-spin-wait-pause-multiplier=5
innodb-log-spin-cpu-pct-hwm=100
innodb-log-spin-cpu-abs-lwm=100

效果：再次测试后发现，ut_delay的热点函数已经消失，tpmc有了大幅提升。

PostgreSQL调优及评测

针对PostgreSQL主要采用了调优手段：

优化1，调整IO相关配置

分析：观察系统资源使用情况，发现有大量磁盘IO事件。当前磁盘读写已成为制约系统性能的首要瓶颈，考虑通过增大共享内存的方式尽量将数据放入内存中进行操作以减小磁盘IO压力。

优化点：增加系统缓存，调整参数配置如下

shared_buffers = 60GB

work_mem = 1GB

maintenance_work_mem = 2GB

效果：TPCC性能指标大幅提升，IO已不再是系统瓶颈。测试过程nmon性能统计：

优化2，commit事务提交优化

分析：观察此时系统资源使用情况，磁盘使用率较高，依然存在优化空间

优化点：优化commit提交。PostgreSQL提供了两个参数commit_delay,commit_siblings。commit_delay是事务提交和日志刷盘的时间间隔。并发的非只读事务数目较多的场景可以适当增加该值,使日志缓冲区一次刷盘可以刷出较多的事务,减少IO次数,提高性能。需要和 commit_sibling配合使用。commit_siblings是触发commit_delay的并发事务数,只有系统的并发活跃事务数达到了该值,才会等待commit_delay的时间将日志刷盘。

调整参数如下：

commit_delay = 10
commit_siblings = 16

效果：调整之后，性能有一定的提升

优化3，数据刷盘优化

分析：此时观察系统资源，发现checkpoint进程持续占用CPU，分析日志发现数据库服务器checkpoint频率太高。

优化点：优化checkpoint，减少IO大量读写的次数。增加配置：

checkpoint_timeout = 120min
checkpoint_completion_target = 0.8

效果：增加checkpoint配置后，checkpoint频率过高告警已消失。

优化4，autovacuum优化

分析：大量写入数据之后，发现vacuum进程持续占用CPU

优化点：PostgreSQL数据库自动清理机制，会自动清理过程中出现大量的数据扫描事件，频繁的清理过程反而会带来数据库过多的性能消耗，从而导致正常业务处理资源紧张。因此对自动清理过程进行限制可以在一定程度上提高业务处理性能。增加如下配置：

autovacuum = on
autovacuum_max_workers = 5
autovacuum_naptime = 20s
autovacuum_vacuum_cost_delay = 10
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_scale_factor = 0.02
vacuum_cost_limit = 2000

效果：vacuum进程长期占用CPU现象消失，性能有一定提升