1. 前言
本报告蕴含了根底测试局部内容，并依据具体的场景，减少了局部扩大测试场景，以便更加全面、精确地出现两款数据库产品在不同利用场景下的查问性能体现。
1.1 硬件环境
为便于大家复现该测试，咱们在 Microsoft Azure 云服务上搭建了测试环境。测试中用到了两台服务器，别离部署客户端和服务器，客户端与服务器通过云服务的内网连贯。
两台服务器的具体配置如下。
操作系统均为 Ubuntu 20.10 Linux。应用的 Go 版本为 1.16。
1.2 软件装置
TDengine 2.1.7.2 社区版，能够在涛思官网下载。也能够通过 clone GitHub 上的代码自行编译生成。该版本的 git 的信息如下：
community version: 2.1.7.2 compatible_version: 2.0.0.0
gitinfo: c6be1bb809536182f7d4f27c0d8267b3b25c9354
InfluxDB 1.8.4（因为该性能测试框架最高只能适配到 1.8 版本，所以这里选取了 InfluxDB 1.8 版本进行比照），能够在 InfluxData 官网下载。
1.3 运行脚本生成查问用数据
1.3.1 装置筹备
部署完 TDengine、InfluxDB 与 Go 语言环境，确保两台服务器的数据库也连贯失常应用失常（建库删库写入查问性能均需测试，建库之后立刻删除，如有问题立即排查）
此外，在测试中应该留神以下几点（TDengine 的默认配置文件为 /etc/taos/taos.cfg）：
1）fsync 的设置要放弃同步，InfluxDB 默认是无延时的 fsync，须要批改 TDengine 的这两个参数：walLevel=2，fsync=0 能力达到雷同的配置环境。后续的所有测试均是在这个设置条件下实现。
2）TDengine 的客户端要把 maxSQLLength 开到最大 1048576。
3）客户端服务器要装置 TDengine 的客户端。（留神：bulk_load_tdengine 编译须要依赖 TDengine 客户端）
1.3.2 从 GitHub 取下代码, 在客户端服务器执行：
git clone https://github.com/taosdata/t…
1.3.3 筹备编译环境，生成写入程序，timeseriesdatabase-comparisons 的根目录为工作目录：
cd timeseriesdatabase-comparisons/build/tsdbcompare/
./compilation.sh
1.3.4 切换到 build/tsdbcompare 目录下，产生测试数据汇合并写入数据库。
在 build/tsdbcompare 下执行./writ_to_server.sh -a “test217”
本次测试的服务端 hostname 是 ”test217″，./writ_to_server.sh -h 能够查看对应参数:生成数据参数（总记录数 =（t-e)243600/ i * s）
i : 数据距离，默认 10s
s : 样本数量，默认 100
t : 数据起始工夫，默认 ’2018-01-01T00:00:00Z’
e : 数据终止工夫，默认 ’2018-01-02T00:00:00Z’
g : 是否生成数据，默认 1（1：生成数据，0：不生成数据）
T : TDengine 的默认数据目录门路，默认为 ”/var/lib/taos”
I : InfluxDB 默认数据目录门路，默认为 ”/var/lib/influxdb”写入参数
b：batchsize(默认 5000）
w : workers(默认 16）
n : TDengine 写入形式 (false:cgo,true:rest, 默认 false)
a : TDengine 和 InfluxDB 的 hostname 或者 ip 地址，默认为 127.0.0.1如果心愿自定义更多参数值，能够查看 write_to_server.sh 脚本代码
1.3.5 生成查问文件，并进行查问测试，在 build/tsdbcompare 下运行脚本：
./read_all.sh -a “test217”
脚本参数和 write_to_server.sh 统一。
2. 测试运行
运行该测试要求敞开 TDengine 系统日志，而后主动执行脚本即可。
在不同的场景之间切换时，会重启数据库后盾服务（Influxd/taosd），并革除 Linux 零碎的全副缓存。
3. 比照测试后果
本大节阐明运行测试脚本取得的比照测试后果，并对后果进行了初步的剖析。
对于测试后果，所有的响应是测试脚本自动记录的工夫，即该工夫并不是单次查问执行的响应工夫，而是实现 1,000 次反复查问最初取得的工夫。须要阐明的是，因为整个测试持续时间较长，测试取得的数据并非同一个时刻。不同的工夫，测试程序运行过程中会受到云服务器所能施展的最大性能影响，取得的后果数据能看到有轻微的抖动，然而整体趋势是统一的。
100 台设施模仿生成的 1 天的数据集，在 TDengine 中生成了 900 个子表，每个设施距离 10 s 生成一条数据，总记录数是 7,776,000。
1,000 台设施在 TDengine 中生成了 9,000 个子表，每个设施距离 10 s 生成一条记录，总记录数是 77,760,000。
测试次要包含四个测试场景，别离是：
- 场景一：通过标签过滤随机筛选出 8 个工夫线后，取其中的最大值。
- 场景二：随机选取 1 h 工夫区间，通过标签随机筛选出 8 个工夫线，取其中的最大值。
- 场景三：随机选取 12 h 的工夫区间，通过标签随机筛选出 8 个工夫线，应用 10 min 作为一个工夫窗口，获取每个工夫窗口的最大值。
- 场景四：随机选取 1 h 工夫区间，通过标签过滤随机筛选出 8 个工夫线，应用 1 min 为一个工夫窗口，获取每个工夫窗口的最大值。
通过测试后果能够看出：整体来看，TDengine 在多种场景下（单线程、多线程）的性能均优于 InfluxDB。在极少的几个状况下，TDengine 与 InfluxDB 的差别十分小。在更多的场景下，TDengine 领有数倍的性能劣势，局部场景的性能劣势能达到 40 倍。
3.1 100 台设施数据集查问后果比照
本局部出现的是，在 100 台设施上模仿 1 天的数据生成的后果集上，运行测试程序所取得的性能比照测试后果。
图 1. 100 台设施数据集上的查问后果比照
由图 1 能够看到，在所有的场景中，只有第三个测试场景单线程的时候 TDengine 查问响应工夫超过 InfluxDB，其余的场景均优于 InfluxDB，并且局部场景（场景二）下其查问性能有着 40 倍的微小劣势。具体的测试响应数据见附录表 1。
图 2. 不同场景下调整查问线程取得最终响应工夫
在 1,000 个设施上测试结果显示出 TDengine 依然展现出较大的性能劣势，即便局部绝对于 InfluxDB 较慢的场景（多线程场景下的场景四），其差距也十分小。而当先的局部，则依然有微小的性能劣势，最高的性能差达到近 20 倍，具体的查问响应数据见附录表 2。
3.2 扩大测试
在上述的两个规范测试之外，咱们基于现有的数据汇合设计了一系列扩大测试，以期更全面精确地评估两个数据库产品在不同场景下的性能体现。在以下测试中，咱们只应用 cgo 的运行测试后果。
3.2.1 标签筛选量对查问性能的影响
调整过滤 host 的数量，设定并行执行的 work 为 16，应用 1,000 个设施的数据汇合执行全副查问，所取得的后果如下表所示。查问响应工夫单位为秒，数值越小越好。
图 3. 不同场景下扭转筛选工夫线查问响应工夫
能够看到，随着筛选的工夫线的减少，InfluxDB 的查问响应工夫在四个测试场景均出现疾速减少的趋势，而 TDengine 对于数据筛选规模的变大则呈现出绝对稳固的查问响应工夫，并且随着工夫线筛选规模的扩充呈现出更大的劣势。由此能够推断，随着查问规模的持续扩充，InfluxDB 的查问响应工夫还会持续疾速减少。各种场景下的查问响应具体工夫见表 3。
3.2.2 查问工夫窗口对查问性能的影响
为了评估不同长度的工夫窗口对查问性能的影响，咱们选取了第四个查问场景，设定并行执行的 work 数量 16，工夫区间是随机选取的 1 h / 2 h / 4 h / 8 h / 12 h 等间断时间段，单个聚合工夫窗口维持在 1 min 不变。取得的查问响应工夫如图 4 所示。
图 4. 扭转查问工夫区间范畴对查问响应的影响
由上图可见，TDengine 绝对于 InfluxDB 有更好的查问性能，并且，随着查问工夫区间的减少，TDengine 的当先劣势继续扩充，当查问工夫区间是 1 小时的时候，TDengine 只比 InfluxDB 快约 8%。然而当查问区间减少到 12 小时的时候，TDengine 的查问劣势曾经扩充到近 2 倍。具体查问响应工夫见表 4。
3.2.3 简单查问性能体现
思考到规范测试中只应用了较为简单的查问函数，咱们应用多个查问函数组合的简单查问，评估查问性能。咱们选取了第四个运行场景，随机选取 1 h 的时间段，聚合工夫窗口为 1 min，过滤筛选 8 个工夫线进行查询处理。
三个场景别离是：
- max(value), count(value),first(value),last(value)
- top(value, 10)
- max(value),count(value),first(value),last(value),integral(value1)spread(ts)/1000 在该场景中，TDengine 中没有 integral 函数，因而采纳 TWA(value) Spread(value) / 1000 的计算形式进行了等效代替。此外，integral 函数查问的是另一个列 value1，而不是 value。
图 5. 不同查问场景下的响应工夫比照
由上图的后果能够看到，在三种简单函数组合的查问条件下，TDengine 查问性能均优于 InfluxDB。特地是在第一种组合场景中，TDengine 的性能是 InfluxDB 的 2.5 倍。具体的查问响应工夫见表 5。
3.2.4 数据读取测试
在这个场景测试中，咱们测试了 TDengine 和 InfluxDB 的数据读取体现。针对全副数据集，不限定查问工夫范畴，调整标签的过滤条件，投影查问来获取全副的数据内容。其后果如图 6 所示。
图 6. 不同数据规模的投影查问响应工夫
能够看到，在提取不同比例的状况下，TDengine 的总的工夫开销稳固在 InfluxDB 的 11% 左右，即该项测试的性能，TDengine 是 InfluxDB 的 8.78 倍，并且该劣势随着工夫线数量的减少而失去扩充，在 128 个工夫线的时候，达到了 9.37 倍。即在更大数据规模的状况下，TDengine 展现出了更好的性能劣势。在工夫线为 256 的时候，InfluxDB 最终未能实现测试运行，服务端呈现了连贯回绝的问题，而 TDengine 也仅用时 365.61 s 就跑完该项测试。
4. 总结
在基于该比照测试框架下运行的测试中，展现出了 TDengine 绝对于 InfluxDB 较大的性能劣势，特地是更加多样化的条件和变量管制状况下的扩大测试中，咱们看到 TDengine 一致性地体现出绝对于 InfluxDB 的较大性能劣势。
附录
比照测试运行的具体数据汇总如下：
表 1. 100 台设施数据集上的查问后果比照
表 2. 1000 台设施数据集上的查问后果比照
表 3. 调整筛选标签数量
表 4. 不同长度的工夫范畴查问响应（秒）
表 5. 简单查问性能体现
表 6. 不同规模数据读取性能体现（秒）
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。