从《写入性能：TDengine 最高达到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》、《查问性能：TDengine 最高达到了 InfluxDB 的 37 倍、TimescaleDB 的 28.6 倍》两篇文章中，咱们发现，TDengine 不仅在写入和查问性能上超过了 InfluxDB 和 TimescaleDB，在数据处理过程的资源耗费也比两大时序数据库要更低。本篇文章将会从 TDengine 的产品设计角度登程，为感兴趣的小伙伴剖析一下 TDengine 性能强耗费低的起因。
为什么 TDengine 的“写入强，开销低”？
“客户端上 TDengine 对 CPU 的需要大于 TimescaleDB 和 InfluxDB，而 InfluxDB 的写入压力基本上齐全集中在服务端，这种模式很容易导致服务端成为瓶颈。TDengine 在客户端的开销最大，峰值霎时达到了 56%，而后疾速回落。综合服务器与客户端的资源开销来看，TDengine 写入持续时间更短，在零碎整体 CPU 开销上 TDengine 依然具备相当大的劣势。”
在 TSBS 测试报告全副的 cpu-only 五个场景中，TDengine 写入性能均优于 TimescaleDB 和 InfluxDB。绝对于 TimescaleDB，TDengine 写入速度最当先的场景是其 6.7 倍（场景二），起码也是 1.5 倍（场景五），而且对于场景四，如果将每个采集点的记录条数由 18 条减少到 576 条，TDengine 写入速度是 TimescaleDB 的 13.2 倍。绝对于 InfluxDB，TDengine 写入速度最当先的场景是其 10.6 倍（场景五），起码也是 3.0 倍（场景一 )。此外，在保障高效写入的状况下，TDengine 在写入过程中耗费的 CPU 资源和磁盘 IO 开销也是起码的。
写入过程中客户端 CPU 开销
通过上图能够看到，从客户端负载来说，三个零碎中 InfluxDB 计算资源占用最低，对客户端压力最小，但这并不能阐明 InfluxDB 是三个数据库当中 CPU 开销最低的，因为其写入压力根本齐全集中在了服务端，而这种模式也为 InfluxDB 埋下了一个隐患， 如果写入的数据规模过大，写入线程会长工夫地大量耗费服务器的计算和磁盘 IO 资源。
与 InfluxDB 相同，TDengine 在客户端的开销最大，峰值间接冲到了 56%，其在客户端的开销比 TimescaleDB 都多了 1 倍，但在用时上，却比 InfluxDB 和 TimescaleDB 都小。也因而，从零碎整体的 CPU 开销来看，TDengine 的劣势仍旧十分显著。
基于产品特点，咱们能够从两个方面剖析这种“高写入，低开销”的实现。首先，为充分利用数据的时序性等特点，TDengine 采取了“一个数据采集点一张表”的策略，要求对每个数据采集点独自建表（比方有一千万个智能电表，就需创立一千万张表），用来存储这个数据采集点所采集的时序数据。这种设计对于晋升写入性能来说次要体现在两个方面：
- 因为不同数据采集点产生数据的过程齐全独立，每个数据采集点的数据源是惟一的，一张表也就只有一个写入者，这样就可采纳无锁形式来写，写入速度就能大幅晋升。
- 对于一个数据采集点而言，其产生的数据是依照工夫排序的，因而写的操作可用追加的形式实现，进一步大幅提高数据写入速度。
其次，因为 TDengine 的 SQL 解析是在客户端实现的，这样一来，其在整个写入过程中，次要的负载都集中在客户端，服务器端承当的压力就会变得十分小。咱们之所以将写入的负载转移到客户端，其起因是客户利用端的伸缩和扩大操作十分地便捷容易，可操作性更强—— 在保障服务器有残余能力的状况下，如果写入性能不够，只有减少写入过程或写入客户端即可解决此问题，不再须要减少服务器的设施了。
试想一下，如果不须要变更服务器数量，那也就不会波及到集群的伸缩操作、资源负载平衡等简单逻辑，整体的写入老本天然就会显著升高。
除了客户端 CPU 开销外，三个零碎比照，TDengine 对服务器的 CPU 需要也是最小的，峰值仅应用了 17% 左右的服务器 CPU 资源。在磁盘写入能力的耗费上，InfluxDB 长时间耗费齐全部的磁盘写入能力，TimescaleDB 写入过程对于写入的耗费绝对 InfluxDB 来说要更具劣势，然而依然远超 TDengine 对磁盘写入能力的需要。
如何用最小的计算开销实现最高的查问性能？
“从整体 CPU 开销上来看，TDengine 不仅实现全副查问的工夫低于 TimescaleDB 和 InfluxDB，在整体上 CPU 计算资源的耗费也远小于 TimescaleDB 和 InfluxDB。在整个查问过程中，TDengine 内存也始终维持在一个绝对安稳的状态。”
基于 TSBS 测试报告咱们能够总结出，查问方面，在场景一（只蕴含 4 天的数据）与场景二的 15 个不同类型的查问中，TDengine 的查问均匀响应工夫全面优于 InfluxDB 和 TimescaleDB，而且在简单查问上劣势更为显著，同时具备最小的计算资源开销。相比 InfluxDB，场景一中 TDengine 查问性能是其 1.9 ～ 37.0 倍，场景二中 TDengine 查问性能是其 1.8 ～ 34.2 倍；相比 TimescaleDB，场景一中 TDengine 查问性能是其 1.1 ～ 28.6 倍，场景二中 TDengine 查问性能是其 1.2 ～ 24.6 倍。
查问过程中服务器 CPU 开销
在资源开销上，TDengine 在查问过程中整体 CPU 占用约 80%，是三个零碎中最高的，TimescaleDB 在查问过程中刹时 CPU 占用次之，InfluxDB 的稳固 CPU 占用最小（然而有较多的刹时冲高）。从整体 CPU 开销上来看，尽管 InfluxDB 刹时 CPU 开销大部分是最低的，然而其实现查问持续时间最长，所以整体 CPU 资源耗费最多。 因为 TDengine 实现全副查问的工夫仅为 TimescaleDB 或 InfluxDB 的 1/20，尽管 CPU 稳固值是 TimescaleDB 与 InfluxDB 的 2 倍多，但整体的 CPU 计算工夫耗费只有其 1/10。
用最小的计算开销实现最高的查问性能，TDengine 是如何做到的呢？首先，TDengine 对每个数据采集点独自建表，但在理论利用中常常须要对不同的采集点数据进行聚合。为高效的进行聚合操作，TDengine 引入超级表（STable）的概念。超级表用来代表一特定类型的数据采集点，它是蕴含多张表的表汇合，汇合里每张表的模式（schema）完全一致，但每张表都带有本人的动态标签，标签能够有多个，能够随时减少、删除和批改。利用可通过指定标签的过滤条件，对一个 STable 下的全副或局部表进行聚合或统计操作，这样就大大简化了利用的开发。其具体流程如下图所示：
因为 TDengine 在 vnode 内将标签数据与时序数据拆散存储，通过在内存里过滤标签数据，就能够先找到须要参加聚合操作的表的汇合，这样须要扫描的数据集就会变得大幅缩小，聚合计算速度天然就会取得显著晋升。同时，因为数据分布在多个 vnode/dnode，聚合计算操作在多个 vnode 里并发进行，这又进一步晋升了聚合的速度。
其次，在单表查问上，当咱们要对全副数据集进行查问时，就须要将查问申请播送到所有的节点。 试想一下，当咱们在业务场景中须要对某个设施进行查问，这时如果能够不应用标签过滤，间接查问对应的设施，查问效率是不是变得更高了，TDengine 便是如此。 在本次测试报告中就有几个这样的场景，TDengine 都体现出了很好的查问性能。
此外，为无效晋升查询处理的性能，针对物联网数据不可更改的特点，TDengine 会在数据块头部记录该数据块中存储数据的统计信息：包含最大值、最小值、和，咱们称之为预计算单元。如果查询处理波及整个数据块的全副数据，就能够间接应用预计算后果，齐全不须要读取数据块的内容。因为预计算数据量远小于磁盘上存储的数据块数据的大小，对于磁盘 I/O 为瓶颈的查询处理，应用预计算后果能够极大地减小读取 I/O 压力，减速查询处理的流程。预计算机制与 PostgreSQL 的索引 BRIN（block range index）有殊途同归之妙。
用极致压缩比实现存储老本的最大水平升高
“磁盘空间占用方面，TimescaleDB 在所有五个场景下的数据规模均显著大于 InfluxDB 和 TDengine，并且这种差距随着数据规模减少疾速变大。TimescaleDB 在场景四和场景五中占用磁盘空间是 TDengine 的 25.6 倍和 26.9 倍。在后面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 十分靠近，然而在大数据规模的场景四和场景五中，InfluxDB 落盘后文件占用的磁盘空间是 TDengine 的 4.2 倍和 4.5 倍。”
当数据写入磁盘时，TDengine 会依据系统配置参数 comp 决定是否压缩数据。TDengine 共提供了三种压缩选项：无压缩、一阶段压缩和两阶段压缩，别离对应 comp 值为 0、1 和 2 的状况。一阶段压缩依据数据的类型进行了相应的压缩，压缩算法包含 delta-delta 编码、simple 8B 办法、zig-zag 编码、LZ4 等算法。二阶段压缩在一阶段压缩的根底上又用通用压缩算法进行了压缩，压缩率更高。
同时，TDengine 采纳的是标签拆散存储机制，即标签与数据是离开进行存储的，这样就带来了两个方面的益处：
- 在存储操作上占用更小的磁盘空间，表级别的标签基本上没有冗余。
- 标签集中存储更有利于标签过滤操作中 IO 拜访的局部性，标签过滤实现得更快，查问性能也会变得更好。
此外，对于 TDengine 来说，每个数据块外部采纳的就是列式存储模式，而且打造了“一个数据采集点一张表”的翻新设计，一个数据采集点采集量的变动必定比多个采集点的采集量变动更慢，压缩率天然也会变得更高。 综合上述的几点设计，TDengine 在进行数据处理时提供了很好的压缩比，帮用户节约了存储空间和存储资源，极大水平上缩小了存储老本节约。
写在最初
在产品开发之初，TDengine 就明确了设计方向，即针对时序数据的特点对写入、存储、查问等流程进行设计和优化，在通过几个版本的一直迭代增强后，其存储量大、存储运维成本低、读写性能卓越、压缩率低等特点越发显著。这些劣势也体现在企业的具体实际上，以西门子的数字化解决方案革新我的项目为例，TDengine 帮忙其 SIMICAS® OEM 2.0 版本移除了 Flink、Kafka 以及 Redis，大大简化了零碎架构，节约了运维老本；而在零跑科技的 C11 新车型我的项目中，TDengine 高压缩算法助力其压缩性能晋升了 10-20 倍，升高存储压力的同时也解决了数据存储老本高的问题。
如果你也面临着性能和老本难以两全的数据处理难题，亟需降级数据架构，欢送增加小 T vx：tdengine1，退出 TDengine 用户交换群，和更多气味相投的开发者一起攻克难关。