共计 4461 个字符，预计需要花费 12 分钟才能阅读完成。
上周三，TDengine 正式公布了基于 TSBS 的时序数据库（Time Series Database，TSDB）性能基准测试报告，该报告采纳 TSBS 平台中针对 DevOps 的场景作为根底数据集，在雷同的 AWS 云环境下对 TDengine 3.0、TimescaleDB 2.6 和 InfluxDB 1.8 进行了比照剖析。为了便于大家更好地浏览和了解，基于报告内容，咱们将从写入、查问及测试过程如何复现等几大维度输入系列文章。本篇文章将为大家解读三大时序数据库在写入性能上的差别点。
在《TSBS 是什么？为什么 TDengine 会抉择它作为性能比照测试平台？》一文中，咱们对测试场景和根本配置曾经进行了具体介绍，本篇文章便不再赘述，还没有理解过的小伙伴能够点击上文链接查看。
五大场景下，TDengine 写入性能实现全面超过
不同场景下写入性能的比照（metrics/sec. 数值越大越好）
如上图所示，咱们能够看到在全副五个场景中，TDengine 的写入性能全面超过了 TimescaleDB 和 InfluxDB。在场景二中 TDengine 写入性能最大达到了 TimescaleDB 的 6.74 倍，在差距最小的场景五中，TDengine 也是 TimescaleDB 的 1.52 倍。相比 InfluxDB，TDengine 在场景五中写入性能达到 InfluxDB 的 10.63 倍，在差距最小的
场景一中也有 3.01 倍，具体的倍率关系请参见下表。
TDengine 与 InfluxDB、TimescaleDB 的写入性能比照
此外，咱们还留神到，随着设施数规模的减少，所有零碎写入基本上出现降落趋势。TimescaleDB 在小规模数据状况下写入性能不迭 InfluxDB，然而随着设施数量的减少，其写入性能超过了 InfluxDB。
在数据齐全落盘后，咱们又比拟了一下三个零碎在不同场景下的磁盘空间占用状况。
磁盘空间占用（数值越小越优）
能够看到，TimescaleDB 在所有的场景下数据规模均显著地大于 InfluxDB 和 TDengine，并且这种差距随着数据规模减少疾速变大——TimescaleDB 在场景四和场景五中占用磁盘空间是 TDengine 的 25 倍。在后面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 十分靠近（在场景二中，TDengine 的数据落盘规模比 InfluxDB 大了 1%）, 然而在场景四 / 五两个场景中，InfluxDB 落盘后文件占用的磁盘空间却达到了 TDengine 的 4 倍以上。
写入过程资源耗费比照，InfluxDB>TimescaleDB>TDengine
仅凭数据写入速度，并不能全面地反映出三个零碎在不同场景下数据写入的整体体现。为此咱们以 1,000,000 devices × 10 metrics（场景四）为数据模板，查看三大数据库在数据写入过程中服务器和客户端的整体负载情况，并以此来比照它们在写入过程中服务器 / 客户端节点的资源占用状况。这里的资源占用次要包含服务器端的 CPU 开销 / 磁盘 IO 开销和客户端 CPU 开销。
服务端 CPU 开销
写入过程中服务器 CPU 开销
上图直观地展现出了三大零碎在场景四写入过程中的服务器端 CPU 负载情况，在图中咱们应用虚线标识出了服务端给客户端确认写入实现的时刻。能够看到，三个零碎在返回给客户端写入实现音讯当前，都还持续应用服务器资源进行相应的解决工作，这点上，TimescaleDB 尤为显著——TimescaleDB 在 7x 秒时即反馈客户端写入实现，然而其服务器端依然再调用 CPU 资源进行数据压缩和整顿工作，当然整个工作带来的 CPU 负载相对而言并不高，只有其峰值 CPU 开销的一半左右，然而持续时间相当长，靠近净写入工夫的 4 倍。
InfluxDB 则在写入过程中应用了相当多的 CPU 资源，刹时峰值甚至应用了全副的 CPU 资源，其写入负载较高，并且持续时间比 TimescaleDB 更长，当然也远长于 TDengine。三个零碎比照，TDengine 对服务器的 CPU 需要最小，峰值也仅应用了 17% 左右的服务器 CPU 资源。由此可见，TDengine 独特的数据模型不仅体现在时序数据写入的性能上，在整体的资源开销上劣势也极为显著。
磁盘 I/O 比照
写入过程中服务器 IO 开销图五展现了场景四下数据写入过程中服务器端磁盘 IO 趋势。能够看到，联合着服务器端 CPU 的开销体现，三大零碎的 IO 动作与 CPU 出现同步的沉闷状态。写入雷同规模的数据集下，TDengine 在写入过程中对于磁盘写入能力的占用远小于 TimescaleDB 和 InfluxDB，写入过程只占用了局部磁盘写入能力（125MiB/Sec. 3000IOPS）。从图上能看到，数据写入过程中磁盘的 IO 瓶颈是的确存在的——InfluxDB 运行中有相当长一段时间将全副的磁盘写入能力耗费殆尽，TimescaleDB 对于写入能力的耗费绝对 InfluxDB 来说要更具劣势，然而依然远超过了 TDengine。
客户端 CPU 开销
写入过程中客户端 CPU 开销从上图能够看到，三个零碎在服务器确认写入实现当前客户端均不再有 CPU 开销。客户端上 TDengine 对 CPU 的需要大于 TimescaleDB 和 InfluxDB，而 InfluxDB 在整个写入过程中，客户端负载整体上来说是三个零碎中计算资源占用最低的，对客户端压力也是三者中最小的，其写入的压力基本上齐全集中在服务端，这种模式很容易导致服务端产生瓶颈。
再看 TimescaleDB，对于客户端压力比 InfluxDB 要更大，CPU 峰值达到 17% 左右。而 TDengine 在客户端的开销最大，峰值霎时达到了 56%，而后疾速回落。尽管 TDengine 在客户端的开销相比于 TimescaleDB 多了 1 倍，但其 写入持续时间更短，综合服务器与客户端的资源开销来看，在零碎整体 CPU 开销上 TDengine 依然具备相当大的劣势。
写入性能基准评估扩大局部
为了更全面地评估 TDengine 在默认参数下的写入性能，咱们在上面的性能评估中对可能会影响写入性能的多个参数进行了调整，以便发展更全面的评估工作。
虚构节点（vnodes）数量
咱们调整数据库中虚构节点数量（默认是 6）为 6、8、12、24，并掂量不同 vnode 数量状况下 TDengine 的写入性能。
不同虚构节点数据量状况写入性能变动
从上表能够看到，在设施数最小的场景一中，随着虚构节点数的减少，写入变化趋势不显著。在较多设施的场景（场景五）中，减少 vnodes 的数量，写入性能取得了显著的晋升。可见在不同规模的场景中，通过调整 TDengine 虚构节点的数量能够取得更好的写入性能，大规模场景中尤甚。
fsync 对写入性能的影响
不同 fsync 配置下写入性能趋势
咱们应用 fsync 参数管制写入到预写日志（write ahead log, WAL）文件中的数据调用 fsync 的频率，以确保数据牢靠落盘。一般来说，调用 fsync 会耗费较多的 IO 资源，并会对写入过程造成肯定的影响。但从上表能够看到，fsync 的配置调整对 TDengine 写入性能影响很小。
在前四个场景中，fsync 配置为实时同步刷入磁盘（fsync 为 0）的状况下，写入性能并没有呈现显著升高。这是因为写入过程采纳了大批量的写入模式，升高了每次刷入磁盘的次数需要，所以对性能影响并不显著，反之写入性能将升高。因而，咱们能够取得一个信息，在此种状况下利用 TDengine，减少每批次写入数据量，能够无效缓解 fsync 配置写入的影响。
设施记录数量
TDengine 的“一个设施一张表”数据模型使得其在进行数据写入时要先创立表，建表操作对每个设施只执行一次，但这会让 TDengine 在数据写入的筹备阶段耗时较多。当单个表中数据量减少当前，数据筹备（建表）的开销会被摊派到数据写入的整体开销中，所以应该有更好的数据写入性能。
以场景四为例，单个设施的数据量仅有 18 条。当咱们调整参数，将单个设施记录数据减少到 36、72、144 条时，整体写入工夫也变得更长，即建表开销被摊派到更多的数据写入过程中，建表的开销绝对于数据写入的耗时占比越来越小，相应的整体写入速度也就越来越快。因而能够看到，随着设施记录数量减少，TDengine 体现出了更加显著的写入劣势。
设施记录数减少时数据写入性能比照（数值越大越好）
随后咱们调整了 vnodes 的数量配置，并同时测试两个不同 vnodes 数量状况下的写入性能指标。如上图所示，随着表中记录数的减少，单表记录减少到 72 时，TDengine 设置为 6 vnodes 的写入性能呈现了降落，然而在 24 vnodes 的状况下，写入性能呈现出继续减少的趋势，并且在全副场景下写入性能均优于 6 vnodes 的写入性能。
当设施记录数达到 576 行（此时数据集规模为 1,000,000 × 576 = 5.76 亿行数据记录）时，写入性能达到 6,605,515 metrics/sec.。在单设施记录达到 576 行时，默认 6 vnodes 配置下 TDengine 写入性能是 TimescaleDB 和 InfluxDB 的 7 倍多，当设置为 24 vnodes 时，性能更是大幅当先于 TimescaleDB 与 InfluxDB，最高达到了 TimescaleDB 和 InfluxDB 的 13 倍多。
TimescaleDB 写入性能在单表记录数量大于 72 行时就呈现了降落趋势，在单表记录数 144 行当前呈现了疾速衰减。InfluxDB 在单设施记录减少过程中，写入性能有衰减，但衰减趋势比拟迟缓。
写在最初
由此可见，TDengine 在五个测试场景中，写入性能均超过了 TimescaleDB 和 InfluxDB。且在整个写入过程中，TDengine 不仅提供了更高的写入能力，还保障了最小的资源耗费，不论是服务器的 CPU 还是 IO，TDengine 均远优于 TimescaleDB 和 InfluxDB。即便加上客户端的开销统计，TDengine 在写入开销上也远优于 TimescaleDB 和 InfluxDB。
在前面的拓展局部，通过调整不同的参数，以及设置不同的数据规模、调整 fsync 参数等形式，咱们在更多的方面评估了 TDengine 在 TSBS 基准数据集上的写入性能。通过这一系列深刻的比照能够看到，针对更大规模数据集，TDengine 能够通过简略调整虚构节点数量的形式取得更高的写入性能，并且 TDengine 在针对大数据集写入场景下展现出了更大的性能劣势。
TDengine 高效的写入性能在企业实际中也失去了验证，此前在机器人骨干企业拓斯达的工厂整体解决方案我的项目案例中，就论述了利用 TDengine 后的革新后果——一个设施一天最多能写入近十万条数据，近千个设施同时写入也齐全没有问题，相较于之前，写入速度晋升了数十倍。
如果你也面临着数据处理难题或想要进行数据架构降级，欢送增加 小 T vx：tdengine1，退出 TDengine 用户交换群，和更多气味相投的开发者一起攻克难关。
理解更多 TDengine Database 的具体细节，可在 GitHub 上查看相干源代码。
