OpenMLDB 实时引擎性能测试报告
![OpenMLDB 实时引擎性能测试报告](https://static001.geekbang.org/infoq/ee/ee318e7cbc16b5f6ae1dd96fe127d3c3.png)
OpenMLDB 提供了一个线上线下一致性的特征平台。其中,为了支持低延迟高并发的在线实时特征计算,OpenMLDB 设计实现了一个高性能的实时 SQL 引擎。本报告覆盖了 OpenMLDB 实时 SQL 引擎的性能测试,包含了在较为复杂的负载、典型配置下的各种性能指标。
了解更多关于 OpenMLDB
**官网:**https://openmldb.ai/
**GitHub:**https://github.com/4paradigm/OpenMLDB/
实验环境
本次测试一共使用四台服务器进行,其中 OpenMLDB 服务部署在三台服务器,客户端部署在一台服务器,四台服务器使用的硬件配置一致,实验环境如下表格 Table-1 所示。
![](https://static001.geekbang.org/infoq/88/8807d5e2e29faac60cd90736fc540a85.png)
Table-1:实验环境配置
测试负载
测试工具和脚本
本测试所使用的测试工具以及使用说明,可以在我们的 GitHub benchmark 页面下载,对本测试进行复现。
![](https://static001.geekbang.org/infoq/c4/c43d881c653d79d0be774bb5da2e2b30.png)
https://github.com/4paradigm/OpenMLDB/tree/main/benchmark
测试方法
本次测试主要用于展示 OpenMLDB 在不同工作负载和运行环境下的性能表现,因此使用基于参数变化的方法进行测试,来理解不同的参数对于性能的影响:
首先定义一组我们需要研究展示的参数变量,这部分参数可以分为三类:
系统参数:线程数目,是否打开预聚合优化
查询参数:窗口数目,LAST JOIN 个数
数据参数:窗口内数据条数,被索引列的基数(即 cardinality,列数据去重后的唯一值数目)
对于所有参数,确定一组典型情况下的默认参数值,其默认参数值配置详见 Table-2 。其中,预聚合优化一般针对窗口内数据量巨大(比如几百万条的情况)打开优化才有意义,所以其默认配置为关闭。
确定好默认参数以后,对于每一个实验参数,进行一定合理范围内的取值变化,同时保持其他参数默认不变,观察在不同参数下的性能数字和趋势表现,其参数的变化取值范围如 Table-3 。
![](https://static001.geekbang.org/infoq/06/0674974aeec4641abd0b67b63338c370.png)
Table-2:实验参数以及默认值
![](https://static001.geekbang.org/infoq/b7/b79c92f70a4318d9a6f30ed5d4309a3a.png)
Table-3:实验参数取值变化范围
数据集
本次测试基于多个数据表进行,其默认参数下的基准表格建立语句如下。对于某些和表格参数有关的 SQL,部分语句会按照一定的模式进行调整(比如窗口数目,LAST JOIN 数目的变化),在每一个实验下面给出了详细的建表和查询 SQL。
基准表格建立 SQL
其中,数据表内的 String 类型长度为 10 bytes,其余字段为随机生成的数据。
测试 SQL
我们使用一个较为复杂的实际场景中可能使用到的 SQL 进行测试。由于我们的部分实验参数会针对不同的 SQL 负载进行调整(窗口数目,LAST JOIN 表的个数),所以具体 SQL 会有一定的变化。下面的 SQL 表示了在默认参数下的基准查询语句(除了预聚合实验)。对于不同的窗口数目以及 LAST JOIN 数目,相应的 WINDOW
相关,以及 LAST JOIN
相关的语句会相应变化。具体每个实验的 SQL 脚本,可以参照每个实验结果下附上的脚本文件。
默认参数下的基准负载 SQL:
注意,由于目前部分聚合函数(如 **distinct_count**
)在 OpenMLDB v0.5.0 还不支持预聚合优化,因此预聚合优化技术的实验的 SQL 是单独生成的,详见相关实验章节。我们在预聚合完善以后将会更新本份报告。
测试指标
在本次测试中,我们主要使用两种性能指标
延迟(latency):使用业界常用的 top percentile 定义(详见解释 Latency metrics | Cloud Spanner | Google Cloud),图上标记为
TPXX
,即XX
th percentile latency吞吐(throughput):使用
QPS
,即 queries per second,代表了每秒处理的请求数量
测试结果
系统参数
线程数变化
Figure-1 显示了在固定其他默认参数,线程数目变化的情况下,延迟和吞吐的性能表现。可以看到,随着线程的增加,请求延迟都呈现上升的趋势。而明显的上升拐点是当线程数为 20 时,增加线程数目会显著增加请求的延迟。总体来说,延迟均保持在个位数毫秒级别。对于吞吐,增加线程数目可以显著提升吞吐表现,在该较为复杂的场景下可以达到万级别的吞吐。
![](https://static001.geekbang.org/infoq/d9/d932e019615f380ec903391cb4796156.png)
![](https://static001.geekbang.org/infoq/37/3729e3d2b1a55231da495626689c826b.png)
Figure-1: 在线程数目变化的情况下,延迟(上图)和吞吐(下图)的性能表现
数据和查询脚本
该实验使用了基准的表格数据和查询 SQL 脚本(参见章节 “2.2. 数据集” 和 “2.3. 测试 SQL”)。
预聚合优化
预聚合实验配置
如之前所提到,由于预聚合还不能支持所有的聚合函数,因此针对预聚合的测试,我们单独设计了一套查询 SQL 进行测试,相关脚本附上。
其相关的参数设置和变化参数显示在 Table-4 中:
![](https://static001.geekbang.org/infoq/db/dbcc79452fe4ee33ff71cb2253b8eb15.png)
Table-4:预聚合优化实验的参数设置
预聚合实验结果
结果如下图 Figure-2 所示,开启预聚合优化时,其延迟显著低于不开启预聚合的情况,随着窗口内数据条数增多,这样的差距随之变大,整体来说,预聚合技术在长窗口的情形下,对于延迟达到了两个数量级左右的性能提升。注意,由于两者性能差距巨大,以下图片纵坐标均使用了对数坐标。
![](https://static001.geekbang.org/infoq/c9/c96d7357872ec53a2d8a3f295d6a0145.png)
![](https://static001.geekbang.org/infoq/1f/1f85af2a94f54693784a13d2ddf86ab2.png)
![](https://static001.geekbang.org/infoq/90/904daa6602ad3987ebf3ddee990f993a.png)
![](https://static001.geekbang.org/infoq/aa/aa6d9ac4aa8f9e9372481324f32902ee.png)
![](https://static001.geekbang.org/infoq/b7/b78ba47d5bdac6a9e9537adcc05a8ad9.png)
Figure-2: 在窗口内数据条数变化的情况下,延迟性能表现
下图 Figure-3 显示了当在不同的窗口大小下,是否使用预聚合的吞吐性能表现:当窗口内数据行数变多,两种情况的吞吐性能都呈现下降趋势,但是开启预集合技术的吞吐量远远高于不使用的情况,而且当窗口变大时,这样的差距更加明显,超过 200 倍。注意,由于两者性能差距巨大,以下图片纵坐标使用了对数坐标。
![](https://static001.geekbang.org/infoq/60/60756d08375d95d3401162a006198eae.png)
Figure-3: 在窗口内数据条数变化的情况下,吞吐性能表现
查询参数
窗口数变化
Figure-4 显示了不同窗口数量的情况下,延迟和吞吐的性能表现。随着窗口的数目的上升,请求延迟呈现明显的上升趋势,其中,当 top percentile 值为 TP999 时,与其他情形差距更大,但是也都保持在个位数的毫秒级别。对于吞吐,窗口数量增多,吞吐缓慢减少,并呈现不断下降的趋势。
![](https://static001.geekbang.org/infoq/84/84dc05ab8f6055a7c4202531dec0b9dc.png)
![](https://static001.geekbang.org/infoq/1d/1d1d36c84a61f6733ffd93eab18428c7.png)
Figure-4: 在窗口数目变化的情况下,延迟(上图)和吞吐(下图)的性能表现
数据和查询脚本
窗口数不同时,脚本有相应变化,具体代码请参照:
http://openmldb.ai/download/benchmark/num_win_1.sql
http://openmldb.ai/download/benchmark/num_win_2.sql
http://openmldb.ai/download/benchmark/num_win_5.sql
http://openmldb.ai/download/benchmark/num_win_10.sql
LAST JOIN 个数变化
Figure-5 显示了在 LAST JOIN 数目变化时,延迟和吞吐的表现。随着 LAST JOIN 表数量的增加,不同 TP 指标下,延迟都呈现平缓的上升趋势,其中 TP999 与其他指标下的数字有非常明显的差距,但是都在 5 毫秒以内。而随着 LAST JOIN 表数量的增加,吞吐性能稍有下降,但是整体维持在 6 千以上。
![](https://static001.geekbang.org/infoq/f8/f8254f9de743a7f0f00bf325ebb0ddab.png)
![](https://static001.geekbang.org/infoq/b8/b81eef82b422c0862af0abb960a42d65.png)
Figure-5: 在 LAST JOIN 表数目变化的情况下,延迟(上图)和吞吐(下图)的性能表现
数据和查询脚本
LAST JOIN 个数不同时,脚本有相应变化,具体代码请参照:
http://openmldb.ai/download/benchmark/num_lastjoin_0.sql
http://openmldb.ai/download/benchmark/num_lastjoin_1.sql
http://openmldb.ai/download/benchmark/num_lastjoin_2.sql
http://openmldb.ai/download/benchmark/num_lastjoin_3.sql
数据参数
窗口内数据条数变化
Figure-6 显示了在窗口内数据条数变化时,延迟和吞吐的表现。随着窗口内数据条数的增多,延迟都呈现非常明显的上升趋势,但是基本都在 10 毫秒以内。增加窗口内数据条数时,吞吐性能会有较为显著的下降。
![](https://static001.geekbang.org/infoq/14/145d4eaaff821f9bd12900d4e722c9e5.png)
![](https://static001.geekbang.org/infoq/ce/cee2290f1b7fa57a1002eedf8eab233d.png)
Figure-6: 在窗口内数据条数变化的情况下,延迟(上图)和吞吐(下图)的性能表现
数据和查询脚本
该实验使用了基准的表格数据和查询 SQL 脚本(参见章节 “2.2. 数据集” 和 “2.3. 测试 SQL”)。
索引列基数变化
Figure-7 显示了在索引列的基数变化时,延迟和吞吐的表现。随着基数增加,每一种 top percentile 参数下,耗时无明显变化,但是 TP999 的延迟明显较高。同时,吞吐没有明显的变化,QPS 值基本维持在 7000 以上。
![](https://static001.geekbang.org/infoq/ec/ec4de24a82223ef53fc78119445c3c94.png)
![](https://static001.geekbang.org/infoq/d4/d413209ca4e406c7cd53ef0ffb999125.png)
Figure-7: 在索引列基数变化的情况下,延迟(上图)和吞吐(下图)的性能表现
数据和查询脚本
该实验使用了基准的表格数据和查询 SQL 脚本(参见章节 “2.2. 数据集” 和 “2.3. 测试 SQL”)。
联系我们
如果你对上述实验报告内容有任何问题,欢迎在社区渠道和我们取得联系。
GitHub Issues
https://github.com/4paradigm/OpenMLDB/issues
对于严肃的使用者和开发者,关于程序使用过程中遇到的任何问题或者特性诉求,欢迎来我们的项目需求搜基地给我们提出反馈和意见。我们会对每一个反馈的 issue 给出 feedback,并且在项目规划的时候会有效考虑社区需求。
微信使用交流群
关于 OpenMLDB 的任何使用问题,可以在交流群中讨论。
![](https://static001.geekbang.org/infoq/62/62e889d6d224a3de901d84d8b0ab9517.png)
Roadmap
https://github.com/4paradigm/OpenMLDB/projects/10
我们在此汇集了开发历程,对于规划中的 Roadmap,你可以在相关 issues 下参与讨论:
如果你有意愿参与其中已经规划的开发计划,请留言和我们互动,确认以后请认领相关 issue,成为 owner
如果你有特别希望在下一个版本中加入的产品特性,也可以留言和我们进行讨论,确认以后我们将正式加入到 roadmap
Slack
你也可以在 Slack 上我和我们进行实时交流,有关任何的使用或者开发问题。Email
有关任何问题,也可以通过 Email 和我们联系:contact@openmldb.ai
开发者邮件列表
https://groups.google.com/u/3/g/openmldb-developers
我们维护了一个针对开发者的邮件列表,有关开发的重要事项将会在群里通知讨论。如果你有意愿参与 OpenMLDB 的开发,你可以加入我们的 OpenMLDB-Developers Google Group ,通过验证以后即可以通过邮件列表方式和我们的社区开发者互动。
评论