近年来,人大金仓的数据库产品受到了外界诸多的关注。做产品,免不了要接受用户的对比和选择,数据库因其行业的自身特点,还有很多开源的技术产品同台比拼,用户因此也会产生诸多疑问,国产数据库相比开源数据库到底如何,今天我们选择数据库的一项核心能力——性能,将金仓KingbaseES和目前业界主流的两种开源数据库MySQL、PostgreSQL进行该能力层面的对比,以期为用户创造更丰富、公平的视角来解读国产数据库当前的发展现状。
为了更易理解和比较,我们采用数据库业界性能评测常用的标准模型TPCC,分别对MySQL、PostgreSQL、KingbaseES在同一环境下进行测试,并对其进行全面极致调优,进而对比其最终的性能表现。TPCC主要用于评测数据库的联机交易处理(偏向OLTP能力),这类系统具有比较鲜明的特点,这些特点主要表现如下:
1、多种事务处理并发执行,充分体现了事务处理的复杂性;
2、在线与离线的事务执行模式;
3、多个在线会话终端;
4、适中的系统运行时间和应用程序运行时间;
5、大量的磁盘I/O数据流;
6、强调事务的完整性要求(ACID);
7、对于非一致的数据库分布,使用主键和从键进行访问;
8、数据库由许多大小不一、属性多样,而又相互关联的数据表组成;
9、存在较多数据访问和更新之间的资源争夺。
采用的测试环境、测试工具和选测版本如下:
硬件配置:
选测的软件版本及采用的测试工具
MySQL、PostgreSQL、KingbaseES调优及评测
我们对MySQL、PostgreSQL、KingbaseES这3个数据库在实际运行中反映出的性能问题,均进行相关性能瓶颈分析,并采用了针对性的调优手段,以使其能够展现最优的性能表现。
MySQL调优及评测
优化1,调整IO相关配置
分析:初始默认配置下,CPU利用率只有45%左右,大概在8万TPMC,通过分析资源等待情况,判断是IO问题。
优化点:增加数据文件、日志文件的缓存大小,增加配置如下:
效果:通过增加缓存优化了磁盘读写数据,性能提升两倍。
优化2:缓解binlog资源等待
分析:再次观察系统资源情况,CPU利用率上升到50%左右,IO和网络没有压力,怀疑关键瓶颈是数据库内部的资源等待。检查MySQL当前等待事件:
发现等待事件中最长的是binlog,虽然其时间比例在总时间中占比较低,但是数据库内部的等待视图看不到其他明显的问题,所以我们决定调整binlog相关的配置。
优化点:基于上述分析,我们将binglog设置为异步刷新,并且将日志级别设置为row来降低写入量。
效果:执行测试后重新检查等待事件,binlog等待已得到明显改善,tpmC也有了一定的提升。
优化3:自旋锁优化
分析:再次观察系统资源情况,CPU利用率依然在50%左右,IO和网络没有压力,怀疑关键瓶颈是数据库内部的资源等待。但是数据库内部的等待事件列表已经看不出明显的问题,我们转而通过perf来继续查找根因,发现存在ut_delay的热点函数,所以判断是自旋锁相关的使用存在问题:
优化:重新调整自旋锁相关的delay以及loops等参数。
效果:再次测试后发现,ut_delay的热点函数已经消失,tpmc有了大幅提升。
PostgreSQL调优及评测
针对PostgreSQL主要采用了调优手段:
优化1,调整IO相关配置
分析:观察系统资源使用情况,发现有大量磁盘IO事件。当前磁盘读写已成为制约系统性能的首要瓶颈,考虑通过增大共享内存的方式尽量将数据放入内存中进行操作以减小磁盘IO压力。
优化点:增加系统缓存,调整参数配置如下:
效果:TPCC性能指标大幅提升,IO已不再是系统瓶颈。测试过程nmon性能统计:
优化2,commit事务提交优化
分析:观察此时系统资源使用情况,磁盘使用率较高,依然存在优化空间
优化点:优化commit提交。PostgreSQL提供了两个参数commit_delay,commit_siblings。commit_delay是事务提交和日志刷盘的时间间隔。并发的非只读事务数目较多的场景可以适当增加该值,使日志缓冲区一次刷盘可以刷出较多的事务,减少IO次数,提高性能。需要和 commit_sibling配合使用。commit_siblings是触发commit_delay的并发事务数,只有系统的并发活跃事务数达到了该值,才会等待commit_delay的时间将日志刷盘。
免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。