近年来，人大金仓的数据库产品受到了外界诸多的关注。做产品，免不了要接受用户的对比和选择，数据库因其行业的自身特点，还有很多开源的技术产品同台比拼，用户因此也会产生诸多疑问，国产数据库相比开源数据库到底如何，今天我们选择数据库的一项核心能力——性能，将金仓KingbaseES和目前业界主流的两种开源数据库MySQL、PostgreSQL进行该能力层面的对比，以期为用户创造更丰富、公平的视角来解读国产数据库当前的发展现状。

为了更易理解和比较，我们采用数据库业界性能评测常用的标准模型TPCC，分别对MySQL、PostgreSQL、KingbaseES在同一环境下进行测试，并对其进行全面极致调优，进而对比其最终的性能表现。TPCC主要用于评测数据库的联机交易处理（偏向OLTP能力），这类系统具有比较鲜明的特点，这些特点主要表现如下：

1、多种事务处理并发执行，充分体现了事务处理的复杂性；

2、在线与离线的事务执行模式；

3、多个在线会话终端；

4、适中的系统运行时间和应用程序运行时间；

5、大量的磁盘I/O数据流；

6、强调事务的完整性要求（ACID);

7、对于非一致的数据库分布，使用主键和从键进行访问；

8、数据库由许多大小不一、属性多样，而又相互关联的数据表组成；

9、存在较多数据访问和更新之间的资源争夺。

采用的测试环境、测试工具和选测版本如下：

硬件配置

类型

配置

数据库服务器

CPU：56核，Intel(R) Xeon(R) Platinum 8280L CPU @ 2.60GHz

内存：187GB

磁盘：1*500GB SSD，2*2T NVMe

操作系统：CentOS Linux release 7.5.1804 (Core)

选测的软件版本及采用的测试工具

软件

版本

MySQL

8.0.26

PostgreSQL

13.1

KingbaseES

V8R6

BenchmarkSQL（测试工具）

5.0

MySQL、PostgreSQL、KingbaseES

调优及评测

我们对MySQL、PostgreSQL、KingbaseES这3个数据库在实际运行中反映出的性能问题，均进行相关性能瓶颈分析，并采用了针对性的调优手段，以使其能够展现最优的性能表现。

01MySQL调优及评测优化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和网络没有压力，怀疑关键瓶颈是数据库内部的资源等待。检查MySQ

发现等待事件中最长的是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有了大幅提升。

图片

02

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现象消失，性能有一定提升

03

KingbaseES调优及评测结果

优化1，IO优化

分析：在高并发场景下影响数据库处理能力性能主要因素有数据库IO消耗、服务器CPU使用效率等因素，且IO优化是数据库优化手段中最常见也是最常用的。KingbaseES数据库优化采用了共享内存优化、wal日志读写策略、IO频率、脏页刷盘策略等多种优化手段以提高高并发场景下的业务处理能力。

优化前性能统计：

图片

优化点：共享内存参数调整、wal日志策略调整、脏页存盘策略等

效果：CPU利用率极大的提升，TPMC也相应得到了提升。

优化后的性能统计：

优化2，等待事件优化

分析：观察此时数据库系统等待事件， ProcArrayGroupUpdate等待事件占据了34%的数据库时间，存在较为严重的性能问题。

优化点：优化事务快照实现方式，提升数据库并发处理能力。

优化前系统top等待事件分析统计：

图片

优化后系统top等待事件分析统计：

图片

效果：通过以上优化前后系统等待事件对比，可以看出数据库系统中ProcArrayGroupUpdate 等待事件在优化前占所有等待事件的34.46%，优化后几乎不占用系统CPU太长事件，较大提升了整体性能。

优化3，绑核提升性能

分析：CPU通用调度模式下，进程容易因为争抢时间片而在不同的CPU核心之间切换，由此带来上下文切换的开销问题，造成性能损耗。

优化点：KingbaseES通过将每个进程均匀的绑定到CPU核心上，在高并发业务压力下节省了进程在多CPU核之间切换带来的开销。

效果：调整之后，性能得到明显提升。

04

经验优化

以上讨论了对三个数据库主要的调优手段和结果，调优后期，分别观察各数据库所在资源情况，CPU利用率上升到70-80%左右，IO和网络无明显压力。评估瓶颈优化的方式投入产出比较低，进一步根据已有经验进行调优方式的确认和细节参数的微调优化。

参考如下确认点：

1. 所有的SQL执行计划都合理，无调整空间

2. 优化IO，使用异步IO、优化脏页刷盘方式

3. 优化热点函数、非必要处理事件

4. 关闭监控系统

效果：CPU利用率略有提升，tpmc也随之略有提高。

05

最终评测结果

基于综上描述的调优操作和评测，分别获得MySQL、PostgreSQL、KingbaseES优化后的性能指标，具体如下：

图片

图片

从结果上可见，在同样的基础环境和测试模型下，人大金仓KingbaseES产品的性能指标明显高于PostgreSQL和MySQL。KingbaseES为何性能上能够表现如此优异，让我们来探究下其内部的优化技术。

贰

浅谈KingbaseES“黑科技”

01

面向NUMA架构多核优化

NUMA的“前世今生”

为了寻求算力上不断新的突破，CPU先是朝着“频率”的方向高歌猛跟进，但随着逐渐受到物理极限的挑战，转为向核数越来越多发展，但由于所有CPU核都是通过共享一个北桥来读取内存，核数的不断增多带来了北桥响应时间的瓶颈问题。于是技术人员另辟蹊径，即将内存平均分配在各个die上，由此CPU核发展进入NUMA（Non-Uniform Memory Access）化时代，如此虽解决了原北桥读取内存的瓶颈问题，但由于NUMA架构下存在CPU访问本地内存的速度要比远端内存的访问速度快1.3--5倍，当CPU的核数越多，这种架构的内存访问的成本开销越大。

图片

NUMA架构发展对数据库的挑战

数据库是高并发，数据访问冲突严重的