共计 4155 个字符，预计需要花费 11 分钟才能阅读完成。
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，即XXth 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，通过验证当前即能够通过邮件列表形式和咱们的社区开发者互动。