OpenMLDB 提供了一个线上线下一致性的特色平台。其中,为了反对低提早高并发的在线实时特色计算,OpenMLDB 设计实现了一个高性能的实时 SQL 引擎。本报告笼罩了 OpenMLDB 实时 SQL 引擎的性能测试,蕴含了在较为简单的负载、典型配置下的各种性能指标。
理解更多对于 OpenMLDB
官网:https://openmldb.ai/
GitHub:https://github.com/4paradigm/…
实时特色计算平台架构方法论和基于 OpenMLDB 的实际
试验环境
本次测试一共应用四台服务器进行,其中 OpenMLDB 服务部署在三台服务器,客户端部署在一台服务器,四台服务器应用的硬件配置统一,试验环境如下表格 Table-1 所示。
Table-1:试验环境配置
测试负载
测试工具和脚本
本测试所应用的测试工具以及应用阐明,能够在咱们的 GitHub benchmark 页面下载,对本测试进行复现。
https://github.com/4paradigm/…
测试方法
本次测试次要用于展现 OpenMLDB 在不同工作负载和运行环境下的性能体现,因而应用基于参数变动的办法进行测试,来了解不同的参数对于性能的影响:
- 首先定义一组咱们须要钻研展现的参数变量,这部分参数能够分为三类:
- 零碎参数:线程数目,是否关上预聚合优化
- 查问参数:窗口数目,LAST JOIN 个数
- 数据参数:窗口内数据条数,被索引列的基数(即 cardinality,列数据去重后的惟一值数目)
- 对于所有参数,确定一组典型状况下的 默认参数值,其默认参数值配置详见 Table-2。其中,预聚合优化个别针对窗口内数据量微小(比方几百万条的状况)关上优化才有意义,所以其默认配置为敞开。
- 确定好默认参数当前,对于每一个试验参数,进行肯定正当范畴内的取值变动,同时放弃其余参数默认不变,察看在不同参数下的性能数字和趋势体现,其参数的变动取值范畴如 Table-3。
Table-2:试验参数以及默认值
Table-3:试验参数取值变动范畴
数据集
本次测试基于多个数据表进行,其默认参数下的基准表格建设语句如下。对于某些和表格参数无关的 SQL,局部语句会依照肯定的模式进行调整(比方窗口数目,LAST JOIN 数目的变动),在每一个试验上面给出了具体的建表和查问 SQL。
基准表格建设 SQL
CREATE TABLE mt (
其中,数据表内的 String 类型长度为 10 bytes,其余字段为随机生成的数据。
测试 SQL
咱们应用一个较为简单的理论场景中可能应用到的 SQL 进行测试。因为咱们的局部试验参数会针对不同的 SQL 负载进行调整(窗口数目,LAST JOIN 表的个数),所以具体 SQL 会有肯定的变动。上面的 SQL 示意了在默认参数下的基准查问语句(除了预聚合试验)。对于不同的窗口数目以及 LAST JOIN 数目,相应的 WINDOW
相干,以及 LAST JOIN
相干的语句会相应变动。具体每个试验的 SQL 脚本,能够参照每个试验后果下附上的脚本文件。
默认参数下的基准负载 SQL:
SELECT * FROM
留神,因为目前局部聚合函数(如 **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 时,减少线程数目会显著减少申请的提早。总体来说,提早均放弃在个位数毫秒级别。对于吞吐,减少线程数目能够显著晋升吞吐体现,在该较为简单的场景下能够达到万级别的吞吐。
Figure-1: 在线程数目变动的状况下,提早(上图)和吞吐(下图)的性能体现
数据和查问脚本
该试验应用了基准的表格数据和查问 SQL 脚本(参见章节“2.2. 数据集”和“2.3. 测试 SQL”)。
预聚合优化
预聚合试验配置
如之前所提到,因为预聚合还不能反对所有的聚合函数,因而针对预聚合的测试,咱们独自设计了一套查问 SQL 进行测试,相干脚本附上。
/* Create table */
其相干的参数设置和变动参数显示在 Table-4 中:
Table-4:预聚合优化试验的参数设置
预聚合试验后果
后果如下图 Figure-2 所示,开启预聚合优化时,其提早显著低于不开启预聚合的状况,随着窗口内数据条数增多,这样的差距随之变大,整体来说,预聚合技术在长窗口的情景下,对于提早达到了两个数量级左右的性能晋升。留神,因为两者性能差距微小,以下图片纵坐标均应用了对数坐标。
Figure-2: 在窗口内数据条数变动的状况下,提早性能体现
下图 Figure-3 显示了当在不同的窗口大小下,是否应用预聚合的吞吐性能体现:当窗口内数据行数变多,两种状况的吞吐性能都出现降落趋势,然而开启预汇合技术的吞吐量远远高于不应用的状况,而且当窗口变大时,这样的差距更加显著,超过 200 倍。留神,因为两者性能差距微小,以下图片纵坐标应用了对数坐标。
Figure-3: 在窗口内数据条数变动的状况下,吞吐性能体现
查问参数
窗口数变动
Figure-4 显示了不同窗口数量的状况下,提早和吞吐的性能体现。随着窗口的数目的回升,申请提早出现显著的回升趋势,其中,当 top percentile 值为 TP999 时,与其余情景差距更大,然而也都放弃在个位数的毫秒级别。对于吞吐,窗口数量增多,吞吐迟缓缩小,并出现一直降落的趋势。
Figure-4: 在窗口数目变动的状况下,提早(上图)和吞吐(下图)的性能体现
数据和查问脚本
窗口数不同时,脚本有相应变动,具体代码请参照:
http://openmldb.ai/download/b…
http://openmldb.ai/download/b…
http://openmldb.ai/download/b…
http://openmldb.ai/download/b…
LAST JOIN 个数变动
Figure-5 显示了在 LAST JOIN 数目变动时,提早和吞吐的体现。随着 LAST JOIN 表数量的减少,不同 TP 指标下,提早都出现平缓的回升趋势,其中 TP999 与其余指标下的数字有非常明显的差距,然而都在 5 毫秒以内。而随着 LAST JOIN 表数量的减少,吞吐性能稍有降落,然而整体维持在 6 千以上。
Figure-5: 在 LAST JOIN 表数目变动的状况下,提早(上图)和吞吐(下图)的性能体现
数据和查问脚本
LAST JOIN 个数不同时,脚本有相应变动,具体代码请参照:
http://openmldb.ai/download/b…
http://openmldb.ai/download/b…
http://openmldb.ai/download/b…
http://openmldb.ai/download/b…
数据参数
窗口内数据条数变动
Figure-6 显示了在窗口内数据条数变动时,提早和吞吐的体现。随着窗口内数据条数的增多,提早都出现非常明显的回升趋势,然而根本都在 10 毫秒以内。减少窗口内数据条数时,吞吐性能会有较为显著的降落。
Figure-6: 在窗口内数据条数变动的状况下,提早(上图)和吞吐(下图)的性能体现
数据和查问脚本
该试验应用了基准的表格数据和查问 SQL 脚本(参见章节“2.2. 数据集”和“2.3. 测试 SQL”)。
索引列基数变动
Figure-7 显示了在索引列的基数变动时,提早和吞吐的体现。随着基数减少,每一种 top percentile 参数下,耗时无显著变动,然而 TP999 的提早显著较高。同时,吞吐没有显著的变动,QPS 值根本维持在 7000 以上。
Figure-7: 在索引列基数变动的状况下,提早(上图)和吞吐(下图)的性能体现
数据和查问脚本
该试验应用了基准的表格数据和查问 SQL 脚本(参见章节“2.2. 数据集”和“2.3. 测试 SQL”)。
分割咱们
如果你对上述实验报告内容有任何问题,欢送在社区渠道和咱们取得联系。
GitHub Issues
https://github.com/4paradigm/…
对于庄重的使用者和开发者,对于程序应用过程中遇到的任何问题或者个性诉求,欢送来咱们的我的项目需要搜基地给咱们提出反馈和意见。咱们会对每一个反馈的 issue 给出 feedback,并且在我的项目布局的时候会无效思考社区需要。
微信应用交换群
对于 OpenMLDB 的任何应用问题,能够在交换群中探讨。
Roadmap
https://github.com/4paradigm/…
咱们在此会集了开发历程,对于布局中的 Roadmap,你能够在相干 issues 下参加探讨:
- 如果你有志愿参加其中曾经布局的开发计划,请留言和咱们互动,确认当前请认领相干 issue,成为 owner
- 如果你有特地心愿在下一个版本中退出的产品个性,也能够留言和咱们进行探讨,确认当前咱们将正式退出到 roadmap
Slack
https://openmldb.slack.com/jo…
你也能够在 Slack 上我和咱们进行实时交换,无关任何的应用或者开发问题。
Email
无关任何问题,也能够通过 Email 和咱们分割:contact@openmldb.ai
开发者邮件列表
https://groups.google.com/u/3…
咱们保护了一个针对开发者的邮件列表,无关开发的重要事项将会在群里告诉探讨。如果你有志愿参加 OpenMLDB 的开发,你能够退出咱们的 OpenMLDB-Developers Google Group,通过验证当前即能够通过邮件列表形式和咱们的社区开发者互动。