最近我们得知，Apache IoTDB 多项性能表现位居 benchANT 时序数据库排行榜（Time Series: DevOps）性能排行第一名！（榜单地址：https://benchANT.com/ranking/database-ranking）
benchANT 位于德国，是一家专门做云设施和数据库性能评估的测试机构。在用户对数据库选型很难找到以性能、功能表现为参考基准榜单的情况下，benchANT 致力于在统一的硬件资源和系统配置下对各类主流数据库系统做性能测试，并依据各项指标进行排名。
benchANT 时序数据库排行榜的评估标准基于 TSBS 基准测试套件的 DevOps 场景，在统一的 AWS（Amazon Web Services，是亚马逊公司提供的一套云计算服务）环境中进行测试，并得出了 IoTDB 的写入吞吐、存储占用、查询延迟等性能结果。
那么，这些结果是在什么样的测试环境下得出的？测试过程又应该是什么样的？最终的性能结果是排行榜上面的样子吗？
既然 TSBS 是开源的测试工具，我们决定用这套标准化测试工具进行反推，尝试还原出 benchANT 时序数据库排行榜测评数据的“产出”过程！
此篇会总结榜单的数据对比结果，并介绍 benchANT 排行榜的背景与写入、查询测试环境。下篇我们将展示我们复现的命令集脚本与 IoTDB 建模。
1 结论总结
基于 benchANT 排行榜的评估结果与其提供的测试环境、条件，Apache IoTDB 团队试图还原了 benchANT 排行榜针对 Apache IoTDB 性能与成本指标的测试流程，并与 benchANT 排行榜中囊括的其他时序数据库，InfluxDB、TimescaleDB、QuestDB 等的数据表现进行了对比。
在写入、查询与存储性能方面，Apache IoTDB 均表现优异。Apache IoTDB 的写入吞吐量（Write Throughput）通过导入 2,617,920,000 个数据点所需的耗时计算得到，测试结果可达到 363 万点/秒，与 benchANT 排行榜中的 InfluxDB、TimescaleDB 、QuestDB 对比，IoTDB 的写入吞吐量最多是其 6.9 倍，最少也可达到 1.4 倍。
Apache IoTDB 的查询延迟（Read Latency）通过查询“1 个设备的 1 个测点在 1 个小时内按照 1 分钟进行分段聚合的值”这一场景计算得到，测试结果可达到 2 毫秒。与 benchANT 排行榜中的 InfluxDB、TimescaleDB、QuestDB 对比，IoTDB 的查询响应速度最多是其 96.5 倍，最少也可达到 3 倍。
Apache IoTDB 的存储占用（Storage Comsumption）通过在查询测试结束时记录存储空间占用得到，测试结果可达到仅占用 2 GiB。与 benchANT 排行榜中的 InfluxDB、TimescaleDB、QuestDB 对比，IoTDB 的存储占用最低是其 1/35。
同时，benchANT 排行榜中使用读取吞吐量（Read Throughput）/ 月成本（Monthly Costs），计算出的成本效益（Operations Per Cost），也就是代表“每一美元能够置换多少的读取性能”，进而评估时序数据库的投入性能比。在这一指标中，Apache IoTDB 与排行榜中的 InfluxDB、TimescaleDB、QuestDB 对比，成本效益最多是其 22.2 倍，最少也可达到 1.4 倍，在使用性价比上也存在优势。
2 背景介绍
benchANT 是国际知名的数据库评测机构，以可靠、独立及透明的方法对各种数据库进行性能评测。
benchANT 榜单收录了常见的关系型数据库、NoSQL 数据库、NewSQL 数据库及时序数据库等，通过使用固定的测试负载、相同的测试机器来保证测试结果的公平性。
当前 benchANT 收录了如下三种测试场景：
"CRUD: General Purpose"：该场景主要测试数据库 CRUD 操作的性能，使用的测试工具为 YCSB。benchANT 在该场景测试了 MySQL、PostgreSQL 及 Cassandra 等数据库在不同负载下的性能对比（读写延迟、吞吐等指标）。
"OLTP: Mix"：该场景主要测试数据库在事务方面的性能，使用的测试工具为 Sysbench。benchANT 在该场景测试了 MySQL 及 PostgreSQL 等数据库在不同负载下的性能对比（每秒执行的事务数量、查询延迟等指标）。
"Time Series: DevOps"：该场景主要测试时序数据库的读写性能，使用的测试工具为 TSBS，TSBS 是 Timescale 开源的一款时序数据性能基准测评工具，它提供了时序数据生成、数据导入、查询生成、查询执行等功能，并可以自动化统计测试的结果。Apache IoTDB 参与的评测便属于该类别，benchANT 针对时序场景的测试均基于相同的硬件资源和测试负载，性能评估使用的指标具体如下：
WRITE THROUGHPUT：写入吞吐，单位时间内处理的写入数据点数量，该数值越高表明数据库写入性能越高。
READ THROUGHPUT：查询吞吐，单位时间内处理的查询请求的数量，该数值越高表明数据库处理查询请求的能力越强。
READ LATENCY：查询延迟，单个查询的响应时间，该数值越低表明数据库处理单个查询的速度越快。
STORAGE CONSUMPTION：存储空间占用，记录测试运行过程中的磁盘平均使用量。
MONTHLY COSTS：月度开销，仅与使用的AWS机器费用有关。
OPERATIONS PER COST：成本效益，记录单位开销内能够执行的操作数量，该数值越高表明数据库的成本效益越大。
3 测试环境
3.1 写入性能测试
benchANT 的测试选取了 TSBS 中的 DevOps 场景，该场景模拟了服务器运行时的监控数据，每个运行的服务器（设备）均采集 9 大项监控指标（cpu、diskio、disk、kernel、mem、net、nginx、postgresl、redis），其中每项指标下采集不同的测量值，以 cpu 为例，cpu 指标下记录了 10 个测量值，分别为 usage_user、usage_system、usage_idle、usage_nice、usage_iowait、usage_irq、usage_softirq、usage_steal、usage_guest 和usage_guest_nice。9 大项监控指标一共会记录 101 项测量值。
benchANT 生成的测试数据集便基于上文所述的 Devops 场景，共生成 1000 个设备（服务器）、数据范围为 3 天（2022-07-25T00:00:00Z ~ 2022-07-28T00:00:00Z）、数据采集间隔为 10 秒，所以一共包含 1000 * 3 * 24 * 60 * 6 * 101 = 2,617,920,000 个数据点。benchANT 榜单里的写入吞吐，便是通过导入 2,617,920,000 个数据点所需的耗时计算得到。
数据写入阶段包含大量的可调参数，参数不同，数据库的性能也可能有很大不同。为保证测试的公平性，benchANT 测试采用的关键参数如下：
"workers": benchANT用于数据导入的并发客户端数量，当数据库部署在 2C8GB 实例时，该值设置为 50；当数据库部署在 4C16GB 实例时，该值设置为 100。
"hashWorkers": 控制数据的写入转发规则，当该值设置为 true 时，可以保证相同设备的数据均由同一个客户端进行写入，保证了数据库服务端不会接收到乱序数据；当该值设置为 false 时，则每个设备的数据都会由随机的客户端进行写入，数据库服务端会接收到一定程度的乱序数据。benchANT 在时序场景下的测试，针对所有数据库的测试该值均设置为 false。
"batchSize": 单次写入包含的数据点数量，针对所有时序数据库的测试该值均设置为 1000。
3.2 查询性能测试
在数据导入阶段完成后，benchANT 会执行查询性能测试，查询测试用例依然由 TSBS 工具生成，针对 DevOps 场景，TSBS 提供了"single-groupby-1-1-1"、"single-groupby-1-1-12"等多种查询类型，而在 benchANT 的测试框架里，目前只基于最具代表性的"single-groupby-1-1-1"查询类型进行评测。
"single-groupby-1-1-1"查询类型表示的含义是“查询 1 个 metric 中的 1 个 host 在 1 个小时内按照 1 分钟进行分段聚合的值”，针对该类型的 IoTDB 查询示例 SQL 语句为：
SELECT MAX_VALUE(usage_user) FROM root.cpu.host_1 GORUP BY ([2022-07-25 00:00:00, 2022-07-25 01:00:00), 1h)在 benchANT 的测试中，一共生成了 100000 个"single-groupby-1-1-1"类型的查询语句，每个查询语句会从Metric "CPU"下的1000个设备里随机选择1个设备、从"2022-07-25T00:00:00Z"至"2022-07-28T00:00:00Z"的时间区间内随机选择1个小时作为查询条件。执行完 100000 次查询后，记录整个查询阶段的查询吞吐、查询延迟信息。
查询测试中的关键参数是"workers"，表示执行查询测试时并发客户端的数量，该参数与数据写入时指定的"workers"参数保持一致。
3.3 benchANT 运行环境
为保证公平性及可复测性，benchANT 针对数据库的测试均运行在 AWS EC2 上，通过标准化的流程一键评测并生成测评结果。其中针对时序场景的测试，benchANT 通过 Scaling 属性进行区分不同的测试规模，该属性描述了实例规格和测评数据库集群规格的对应关系，集群 small（即 1 节点）+ 实例大小 small = xSmall scaling，集群 small （即1节点）+ 实例大小 medium = small scaling。其中 small, medium 实例的配置如下：
如下图所示：
在 xSmall scaling 下，benchANT 客户端使用 AWS EC2 c5.4xlarge 实例，客户端机器的规格为 16 核 32GB；IoTDB Server 使用 AWS EC2 m5.large 实例，Server 的规格为 2 核 8GB，IoTDB 的部署形态为 1ConfigNode 1DataNode。
在 small scaling 下，benchANT 客户端使用 AWS EC2 c5.4xlarge 实例，客户端机器的规格为 16 核 32GB；IoTDB Server 使用 AWS EC2 m5.xlarge 实例，Server 的规格为 4 核 16GB，IoTDB 的部署形态为 1ConfigNode 1DataNode。
通过构建不同的规模，可以更全面的评测数据库在不同资源下的性能表现。需要说明的是，benchANT 是第三方国外评测机构，其在时序测试场景下构建了 xSmall 与 small 两种规模，这两种规模均非大规模集群，在我们实际的测试中，随着机器规格的提升，IoTDB 对机器资源的调度可以更加精细、具有更大的发挥空间。
在接下来的章节，我们将重点介绍基于以上 benchANT 场景，我们复现的测试步骤，分析并对比 Apache IoTDB 及其它时序数据库的性能表现。具体的命令集脚本以及建模方法详见第二弹，敬请关注！
更多内容推荐：
• 了解如何使用 IoTDB 企业版
