kdb+性能比较

Hugh Hyndman是Kx公司工业物联网解决方案负责人，这是他写的一篇关于kdb+性能比较的文章。主要结论为：kdb+具有超越其他数据库一至两个量级的性能表现，例如，kdb+比Cassandra快20倍以上，比ElasticSearch快440倍，比MongoDb快38倍，InfluxDB快33倍，比OpenTSDB快123倍等。原文链接为https://kx.com/wp-content/uploads/2020/11/KdbTransitive-Comparisons-1.pdf。

KDB+ 性能比较
（基于传递性的Kdb+性能对比测试）

2018年5月15日
Hugh Hyndman

2017年夏天，笔者写过一篇关于在树莓派（Raspberry Pi）上运行kdb+的博文，文章主要讨论了利用InfluxData公开发布的性能测试方法生成、存储测试数据，并运行一系列用于性能测试的查询。鉴于kdb+的优异表现，笔者得出结论，认为kdb+是用于小平台或边缘计算的不二之选。
在此基础上，笔者个人感觉为了Kx社区应当进一步进行研究：对InfluxData提供过性能测试文档的所有产品（Cassandra, ElasticSearch, MongoDB以及OpenTSDB），在树莓派以外的多种硬件配置上与kdb+进行性能对比测试。
这项测试的难点在于，笔者并没有时间逐一安装、配置各项工具（更别说是在树莓派上进行了）。因此笔者打算另辟蹊径，采取一种基于传递性的测试方法：如果a的值大于b，而b的值大于c，则a的值一定大于c。
基于以上逻辑，并原封不动地接受InfluxData提供的性能测试结果的话，笔者认为，仅需在笔者自己的硬件配置上进行测试，并将测试结果与InfluxData的结果进行对比，即可得出kdb+与其他工具的性能比较结果。此外，由于在InfluxData自己的测试中，InfluxDB的表现大大优于其他数据库，若kdb+能够超越InfluxDB的表现，那么根据传递性，kdb+会成为本次测试中最快的数据库。
本文总结了笔者开展性能测试所采用的数据、查询及硬件环境，及最终的测试结果。

数据

本文采用的原始数据取自标准服务器环境在24小时中产生的系统及应用指标，涉及CPU、内存、硬盘、硬盘I/O、内核、网络、Redis、PostgreSQL及Nginx九个维度。在不同测试中，上述数据取自100至1000台服务器，时间跨度为4小时至4天。
所有的原始数据集均通过每10秒采集100项指标产生，数据规模相对较小（kdb+可以轻松支持万亿级别的数据量），各数据集规模为1.5亿至8.5亿个数据点。由于数据集规模小，笔者并未通过分布式存储和分区来利用kdb+内生的高效并行计算。

查询
表1总结了InfluxData运行的性能测试查询，及笔者为对比性能在kdb+上相应运行的查询。请注意，由于本次测试的对象并不全是时间序列数据库（例如Cassandra, MongoDB和ElasticSearch），在各平台上运行的查询基于并发性及其他平台特点进行过调整，并非完全相同，以获得各平台的最优测试结果。

与笔者以前在其他博文中描述的测试不同，本次笔者通过一台客户端生成kdb+测试用例，并将其提交至kdb+服务器上，以获得更为精确的性能比较结果，并在测试中引入网络延迟因素。

硬件
笔者在三类规模各异的硬件平台上通过kdb+执行了查询1-5，其中包括树莓派、MacBook Pro及配置相对适中的服务器。具体硬件配置及InfluxData所采用的硬件配置见表2。

查询6的硬件配置与前述查询1-5有所不同，因为InfluxData与OpenTSDB的性能对比测试查询在Amazon Cloud的双核m4.xlarge EC2样例上执行。笔者在kdb+上执行查询6时也采用了同样的样例配置。

测试结果

下表总结了kdb+与其他数据库平台的性能测试结果对比，kdb+查询共在树莓派、MacBook Pro及三种相似配置（使用单核、4核、8核进行查询）的Kx Server上执行。最右三列描述了kdb+相较于InfluxDB及其他平台究竟提升了多少倍的计算效率。

以查询6为例，若kdb+比InfluxDB快32.5倍，而InfluxDB比OpenTSDB快3.8倍，则根据传递性，可以认为kdb+比OpenTSDB快123倍。

注：表中数值单位为各平台每秒钟处理的查询数量

将查询结果可视化，能够更直观地展示上述数据。图1展示了在kdb+、InfluxDB和MongoDB上运行查询5的结果，蓝色为笔者得到的测试结果，最右两列为InfluxDB对外公布的原始测试结果。

由于kx 4核服务器的配置与InfluxDB服务器最为相近，我们可以采用4核服务器的结果进行对比。在查询5中，kdb+每秒可以处理107810次查询，MongoDB每秒可以处理2614次查询，kdb+相较于MongoDB有41.2倍的效率提升。其他查询的效率对比见附录。（详见原文，译文此处略去）

总结
Kdb+以世界最快的时间序列数据库而闻名。我们有些工业级用户的系统以kdb+作为支持，每秒可以处理3000万个传感器读数，每天存储超过10TB的压缩数据——在这一切发生的同时，数据库还在同时进行数据查询、复杂事件处理（CEP），并处理数据输入流。
需要承认的是，InfluxData所公布的性能测试方法并不能准确模拟现实中的物联网应用，测试用到的数据库数据结构精简、数据规模小、数据查询逻辑简单。由于技术框架的选择十分重要，而经销商又常会对其产品的处理性能夸大其辞，Kx公司选择用有说服力的数据量、现实的数据负载，以及复杂的多表连接查询来向客户证明，依据产品处理海量数据的性能进行技术选型的重要性。这是检验广告宣传是否贴合实际，以及技术是否真正能够服务于业务的唯一准确方法。任何试图避开上述检验手段的解决方案，其自身就应当被淘汰。
很显然，本文给出的结论并不能构成一次科学、独立客观的kdb+产品性能的检验，但kdb+具有超越其他时序数据库一至两个量级的性能表现这点，值得读者停下来稍作思考。
读者若希望就kdb+性能进一步获取更为严肃的讨论，可参见Mark Litwintschik基于十亿出租车载客数据开展的性能测试(http://tech.marksblogg.com/billion-nyc-taxi-kdb.html)。
读者若希望获取完全独立且经过审计的性能测试结果，STAC性能测试委员会提供了一系列对比低延时、高数据量技术的测试，kdb+在这些测试中表现良好。STAC网址：https://stacresearch.com。

注：作者Hugh Hyndman是Kx公司工业物联网解决方案负责人，工作地位于多伦多。Hugh的工作集中于高性能大数据计算领域，致力于通过引入Kx公司提供的技术，为企业客户的软件系统与产品赋能。

说明：本文经授权转载自微信公众号kdbcnbook。