比年来，人大金仓的数据库产品受到了外界诸多的关注。做产品，免不了要接受用户的对比和选择，数据库因其行业的自身特点，还有很多开源的技术产品同台比拼，用户因此也会产生诸多疑问，国产数据库相比开源数据库到底如何，今天我们选择数据库的一项核心本领——性能，将金仓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个数据库在实际运行中反映出的性能问题，均进行相关性能瓶颈分析，并采用了针对性的调优本领，以使其可以或许展现最优的性能表现。
01
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有了大幅提升。
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架构发展对数据库的挑战
数据库是高并发，数据访问冲突严重的软件体系，其需要大量利用大规模共享内存，面对NUMA架构，就不可制止在运行过程中去访问远程内存了，在不干预情况下，数据库内部历程会在CPU的核之间飘移，当线程运行时从一个核飘移到一个新的核上运行时，原先访问的数据布局再次访问时就涉及远端访问，从而导致访问时延增加。
由此可见，虽然CPU的NUMA技术发展带来了自身本领的大幅提升，但上层软件能否有效利用，才能真正决定算力释放的效果，纵观IT技术栈，只有硬件、操作体系、数据库软件都要深度适配 NUMA架构，才能充分发挥出NUMA的优势。因此人大金仓数据库产品KingbaseES作为企业级的商用数据库，为了资助用户更高效地利用多核算力，提升数据库的响应速率，进行了针对性的优化。
线程绑核，低落访问时延
防止线程飘移，让其实现CPU核的就近访问，这是低落访问时延的关键，因此采用将线程可以或许固定到详细的核上运行的方法。KingbaseES利用配置参数设定，利用操作体系设置亲和性接口达到将线程绑定到详细NUMA节点上的效果。
同时，KingbaseES是一个客户端服务器布局，客户端和服务器是通过网络通信来进行交互，网络是一个频繁的操作，并也会占用CPU，因此还需思量将网络中断和业务处理进行区隔制止相互干扰，以是也对网络中断进行了绑核操作，并和后台业务线程绑核进行区分，这样能进一步提升利用服从，低落内耗。
NUMA化数据布局改造，减少跨核访问
KingbaseES因业务处理需要，涉及很多对全局性数据布局的操作，如WALInsertLock、PGPROC等，在NUMA架构下，优化前，此类数据布局存放在共享内存中，当出现高并发访问，访问竞争剧烈时，就会存在对其跨核访问，形成访问远端内存的局面，造成性能消耗。
根据以上问题，联合KingbaseES内部操作逻辑特点，并基于前文所述的线程绑核优化，我们进行了更深层更针对性的优化，即将操作频繁的的全局性数据布局按照NUMA节点的数量切分为多组，并分别在对应的NUMA节点上申请内存，当某线程需要操作相关数据布局，可访问自己所绑定的NUMA节点上本地内存的相关数据布局内容，减少了跨核的远端访问，提升了访问服从。
02
高并发冲突环境下的并发控制算法调整，减少单点瓶颈
原模式下，每个数据库链接都会维护几个存储当前状态的布局，每当事件需要获得快照时，申请共享历程锁，遍历全部历程。快照需要记录包罗当前正在运行的最大事件id、下一个将要开始的事件id，以及这二者之间正在运行的全部事件和子事件id列表。基于此，在可见性判定时可知，低于最小事件id的事件已竣事，而大于最大事件id的事件视为正在运行，二者之间的事件态则需要根据列表判定。在高并发时，对全部历程进行遍历的时间变长，并且由于历程锁在很多场景下需要独占，例如下图所示的事件竣事，大量并发历程相互之间的干扰愈加不可忽视，快照获取过程成为占比最高的部门。有鉴于此，如何最大水平的减少锁，成为解决问题的关键。
根据内核事件管理体系状态信息的分布特点，我们重新设计了数据布局，采用事件位图方式展现事件状态。如下图所示，在事件开始时利用独占历程锁设置事件状态位图，竣事时仍然利用独占历程锁消除事件状态位图，而在获取快照时也仍然利用共享事件锁，但此时不再需要遍历历程状态。此设计使状态数据变得非常紧凑，可以或许快速获取事件状态，大幅低落共享锁的持有时间。
TPCC测试中，利用200并发终端压测，单独验证跟踪查看该方案最终测试结果，快照获取过程在整个运行期间的从占比6%以上，低落到0.2%以下。在不同平台上，tpmC均有不同幅度的提升，其中Intel平台大约20%，鲲鹏920平台约有5-6%。
寄语
国产数据库蛰伏40年，人大金仓从第一代创办人坚信“中国也应有自己的数据库”之初心，到现在第三代金仓人面对国表里社会形势的变革，能扛起国产数据库承载核心业务应用的大旗，这一起走来，我们克服了很多困难，也得到了诸多客户的支持与肯定。未来，人大金仓将继续砥砺前行，不断提升用户对我们的信心，为中国数据库正名。 | 
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
