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），在各平台上运行的查询基于并发性及其他平台特点进行过调整，并非完全相同，以获得各平台的优测试结果。编号 | 查询内容 | InfluxData采用的平台对比 | 数据集时间跨度 |
1 | 计算1台主机在指定1小时内，每分钟的各指标大值 | InfluxDB vs Cassandra | 1天 |
2 | 计算1台主机在指定12小时内，每分钟的各指标大值 | InfluxDB vs Cassandra | 1天 |
3 | 计算8台主机在指定12小时内，每分钟的各指标大值 | InfluxDB vs Cassandra | 1天 |
4 | 计算1台主机在指定1小时内，每分钟的各指标大值 | InfluxDB vs ElasticSearch | 4天 |
5 | 计算1台主机在指定1小时内，每分钟的各指标大值 | InfluxDB vs MongoDB | 6小时 |
6 | 计算1台主机在指定8小时内，每分钟的各指标大值 | InfluxDB vs OpenTSDB | 4小时 |
与笔者以前在其他博文中描述的测试不同，本次笔者通过一台客户端生成kdb+测试用例，并将其提交至kdb+服务器上，以获得更为的性能比较结果，并在测试中引入网络延迟因素。
笔者在三类规模各异的硬件平台上通过kdb+执行了查询1-5，其中包括树莓派、MacBook Pro及配置相对适中的服务器。具体硬件配置及InfluxData所采用的硬件配置见表2。 | | | | | |
| | | | | |
| | | | | |
| 3.2Ghz 四核 E5-2667V3 Xeon （20MB缓存） | | | | |
| 3.6Ghz 四核 E5-1271V3 Xeon （8MB缓存） | | | | |
查询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对外公布的原始测试结果。图1 kdb+、InfluxDB及MongoDB每秒查询处理量由于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。来源 https://mp.weixin.qq.com/s/tGQbPnxnGvjOKiw8iCDHhA
