共计 5357 个字符，预计需要花费 14 分钟才能阅读完成。
作者：大数据模型
本篇文章出自 2022 年“用 TDengine，写 TDengine”征文投稿流动。
因为工作的关系，最近几年我接触到过各种国产数据库，唯独对 TDengine 朝思暮想。在泛滥数据库中，TiDB 一枝独秀，OceanBase 出身名门世家，openGauss 有华为撑腰，只有 TDengine 给人有一种草莽出英雄的感觉；在开发上，TiDB 借用了 rocksDB 的性能，openGauss 是基于 postgreSQL9.2.4 开发的，即便 OceanBase 也是基于外部利用需要开始打造的，只有 TDengine 不依赖任何开源或第三方软件自研而成。而且它不是一款通用型的数据库，剑走偏锋，它有本人独特的社会利用场景，次要为工业网服务。
基于对 TDengine 的定义和了解，笔者将会在本篇文章中从 TDengine 能解决什么问题、它的劣势与亮点、它与其它数据库的区别等维度开展详述，心愿能帮忙到对 TDengine 感兴趣的小伙伴。
“区别于通用数据库，TDengine 抛掉无用包袱”
数据库想要实现杰出的的读写，最外围的能力就是索引，个别数据库产品都具备正向索引能力。所谓正向索引就是通过文档记录外面的标识符为关键字，通过要害标识符不再须要进行全盘扫描。尽管 B 树索引、哈希索引、位图索引有区别，然而大方向都属于正向索引。
除了正向索引，还有反向索引【也称倒排索引】，反向索引次要用于全文检索，例如 ElasticSearch，大多数据库都是正向索引。TDengine 也是应用正向索引，它的特别之处是标识符必定蕴含工夫戳，再加上一个维度指标数据，形成一个对数据值明确的形容——某个工夫某个指标对象的数据值是多少。
从数据组织的存储引擎来看，数据库底层能够分为 B 树机制、LSM 机制，两种机制没有最好，各有各的长处和毛病：
B 树最大益处在于它对数据继续低落读性能的解决，即便数据量级增大，它的读也没有放大。神秘在于对数据进行终极长久存储时， B 树是以有序有法则的数据结构保留在硬盘上的。这样随着数据越来越大，它仍然放弃有序有法则的个性，面对成千上万的读操作，都能够遵循条件运行，缩小或防止读放大的行为。
与 B 树机制截然相同，LSM 机制则是缩小防止了写放大。LSM 机制充分利用了内存，在内存外面开拓了一个空间，写数据优先往内存里放，写进去间接返回用户胜利，而不是像 B 树那样写一个，我要找出谁比我大谁比我小，只有内存有够，就间接往内存外面填就好，当内存达到肯定的阈值，将内存中的数据以批量、程序的形式一次写入硬盘上，内存则重置清零再服务新的写要求。
传统数据库 MySQL、Oracle 应用的是 B 树机制，而 TiDB、OceanBae 应用的是优化后的 LSM 机制，而 TDengine 应用的是 B 树 + LSM 机制的形式，其中 B 树存储的是元数据【次要是工夫戳 + 指标数据】，LSM 机制存储的是具体的数据，元数据以有序表构造形式进行存储，而具体数据则是以追加的形式写入，这样即防止了读话大和写放大。
一般来说，OLTP 产品为了晋升并发管制的性能，必定会有写时复制或者 MVCC 的性能选项，写时复制与 MVCC 尽管保障了数据的一致性，然而带来更多的 IO 累赘。TDengine 不须要对数据进行批改，所以不须要思考数据一致性的问题，数据是以有序的法则并追加的模式写进去的，因为只有读和写，所以也不须要锁爱护，抛掉一些无用的包袱，能够集中优化其它中央，例如列式表。
业界通用数据库针对各种业务都会有行式表、列式表甚至齐全的内存库，对于具体的数据存储 TDengine 应用齐全列式存储在硬盘，而维度指标则行式保留在内存中。因为 TDengine 面对的是机器的数据，机器 24 小时工作准确到每个毫秒都在产生数据，为了存储更多的数据，所以 TDengine 用上行列并存、用处拆散的形式。
一般来说，数据库外面每一行的文档记录都是十分重要的，即便这行记录信息无关交易，只是一个用户的根本信息，那它的价值密度也非常高。但时序数据库（Time Series Database）不同，单行文档记录价值密度低，因为 1 秒能够产生 1 万条记录，必须要把数据聚合汇总起来能力体现数据的价值。疾速并无效聚合一般数据使之变成价值密度高的数据，这个也是时序数据库区别于其它数据库的一个重要的特色。
TDengine 目前提供了三个版本的产品：社区版，企业版以及云版本， 以满足市场的需要和集体开发者的需要。
“拆解时序数据库，几大产品特点剖析”
从技术上辨别定位，TDengine 是专一工夫序列畛域的一个分布式的海量数据分析平台。它的竞争对手能够分为间接竞争对手和间接竞争对手，间接竞争对手有国内的 TiDB、OceanBase、GaussDB 以及国外的 Oracle、MySQL 等等，尽管它们在综合技术维度上与 TDengine 没有对标，然而剖析上只有是应用工夫戳，与工夫序列有关系，这里就有 TDengine 的用武之地。与 TDengine 形成间接竞争的对手有 Druid、OpenTSDB、InfluxDB，他们都是工夫序列剖析的前辈。
Druid 是一个分布式系统，采纳 Lambda 架构，有利于充分利用内存，也会把历史数据保留到硬盘上，按肯定的工夫粒度对数据进行聚合，实时处理和批处理数据解耦离开。实时处理面向写多读少的场景，次要是以流形式解决增量数据，批处理面向读多写少的场景，次要是以此形式解决离线数据。Druid 依赖 Hadoop，集群中采纳 share nothing 的架构，各个节点都有本人的计算和存储能力，整个零碎通过 Zookeeper 进行协调。为了进步计算性能，其会采纳近似计算办法包含 HyperLoglog、DataSketches 的一些基数计算。
OpenTSDB 是一个开源的时序数据库，反对存储数千亿的数据点，并提供准确的查问，采纳 Java 语言编写，通过基于 HBase 的存储实现横向扩大，OpenTSDB 宽泛用于服务器的监控和度量，包含网络和服务器、传感器、IoT、金融数据的实时监控畛域。OpenTSDB 在设计思路上是利用 HBase 的 key 去存储一些 tag 信息，将同一个小时数据放在一行存储，以此进步查问速度。OpenTSDB 通过事后定义好维度 tag 等，采纳精美的数据组织模式放在 HBase 外面，通过 HBase 的 keyRange 能够进行疾速查问，然而在任意维度的组织查问下，OpenTSDB 的效率会升高。
InfluxDB 是一款十分风行的时序数据库，采纳 Go 语言开发，社区十分沉闷，技术特点反对任意数量的列，去模式化，集成了数据采集、存储和可视化存储，应用高压缩比的算法反对高效存储，采纳 TIME SERIES MERGE TREE 的外部存储引擎，反对与 SQL 相似的语言（2.0 版本不再反对）。
工夫序列的业务背景，在 OLAP 场景中个别会进行预聚合来缩小数据量，影响预聚合次要因素能够汇总如下：
- 维度指标的个数
- 维度指标的基数
- 维度指标组合水平
- 工夫维度指标的粗粒度和细粒度
为了实现高效的预聚合，TDengine 的秘诀是超级表，Druid 会提前定义预计算，InfluxDB 也有本人的间断查询方法，只有 HBase 应用时才进行拼接，所以波及不同的维度指标查问，HBase 会慢一些。
据理解，TDengine 基于 TSBS 的测试报告将于近日出炉，第一期报告针对 InfluxDB 和 TimeScaleDB 进行了具体的性能层面的比照剖析，感兴趣的小伙伴最近能够多多关注下公众号的内容。
“放到明天，TDengine 肯定是首选”
我对 TDengine 的意识和理解要从过来的我的项目教训说起，以 2018 年为背景，我给大家讲述一个工业界坏件故障件预测的故事。
某出名团体随着公司业务的快速增长、新工厂的一直减少，各种有价值的数据不能很好的整合、剖析与挖掘出它应有的价值。此时公司倒退曾经进入下一轮“拼”的策略，疾速响应与精确预测是业务倒退的要害，大数据在其中起到无足轻重的作用，以迷信的剖析手法整合各零碎数据、推动工厂制作智能化倒退，成为一件火烧眉毛的工作。
以后工厂生产过程中呈现了同一种非凡问题的 glass id，glass 的品质因为各种起因是参差不齐的，甚至会有品质异样的 glass。这些异样 glass 在检测过程中，是无奈检测出异样起因的，如果无奈疾速定位出异样起因，就会造成更多的异样 glass，重大影响生产。应答的具体伎俩包含：
- 通过品质异样的 glass，找到产生此异样的相关性因子。如：机台、物料、载具、参数等。
- 异样 glass 侦测预警，通过对产生品质异样的因子进行数学建模，预测出偏离失常范畴的异样玻璃，提前预警。
- 剖析 glass 的特征值与特征值之间的关联关系，并建设预测模型，提前预测出 glass 的特征值。
- 剖析 glass 相干的电压、电阻、电流、温度、湿度影响。
很显著这是数据挖掘的我的项目，要剖析以上 glass 在生产过程中的环境信息、检测机台材料、量测机台材料、制程参数信息，以及 FDC、OEE 零碎的数据，能力找出产生这种问题的起因。第一步是数据收集整合，第二步是数据摸索，第三步是模型调校——找出可能性、影响最大的因素的特色因素，第四步是投入生产验证，通过 spark ml 提供预测能源。
过后的技术栈用的是 CDH，首先要通过 Kafka 采集数据，Spark 对接 Kafka 进行初步计算去噪并汇总到 Hadoop 外面，以 parquet 的格局保留，如果须要进一步的加工，就通过 impala 进行。这样每天挂起 N 个工作，不停的调度计算。
CDH Hadoop 尽管无奈做到实时数据分析，然而也还能做些事，聊胜于无，就持续用着。过后这个坏件故障件预测我的项目有以下痛点，次要是及时性、有效性、准确性的问题：
- 难以满足用户需要，某些机器数据的聚合计算须要第二天能力出后果，甚至更多的工夫能力进去。
- 经济老本的费用较高，CPU、磁盘、网络都在一个高段的应用状态，针对越来越多的数据须要投入新机器。
- 保护老本高，你须要保护 Hadoop 所有的机器，各种 HBase、Spark、Zookeeper、HDFS 之类，岂但对工程师要求高，而且工作量微小。
- 低质量数据，因为数据流程或者谬误的逻辑整合，导致机器传感器聚合后数据模型无奈失常应用。
- 无奈做到实时监测，机器数据作为贵重的自变量因素无奈及时传输并进行计算，天然会影响因变量。
笔者经验了这个我的项目，晓得这个坏件故障预测与工夫序列有严密的关系。时至今日，工夫序列剖析也是重要的数据分析技术，尤其面对季节性、周期性变动数据时，传统的回归拟合技术难以见效，这时就须要简单的工夫序列模型，以工夫为特色作为抓手点。这样即便你不太懂业务的前提下，也能够进行数据挖掘的工作。
那这个我的项目与 TDengine 有什么关系呢？实际上，这个我的项目并没有用上 TDengine，起初团体搭建了一个 Hadoop 集群试点，这次竟然用了 HDP，理由很简略，因为 HDP 默认搭载了时序数据库 Druid。
过后技术负责人认为坏件故障预测模型的数据库基座应该是时序数据库，而不是 Hadoop 不停的进行数据采集、数据转换以及各种批计算，通过时序数据库岂但能够实时计算，而且输入的数据品质高。至于抉择哪个时序数据库，彼时思考平稳过渡替换以及学习老本综合因素后他们抉择了 Druid。
但过后是 2017 年，TDengine 也还没有面世，如果放到明天，TDengine 必然是选型思考的首选。
要晓得，TDengine 的劣势绝对 Druid 要多了去了，首先 Druid 不是一个通过开源版本 1.00 正式公布的软件，尽管倒退多年，直至 HDP 与 CDH 两家公司交融，HDP 搭配的 Druid 也不是 1.00 版；其次 Druid 依赖 Hadoop，动辄就应用大量的资源以及各种简单的 Hadoop 组件，最初 Druid 只提供 json 的形式，对传统的 DBA 应用非常不敌对。
TDengine 有一个我认为很秀的性能，就是它的超级表的跨指标维度建模思维，目前它仅用于 自由组合维度指标，拼接不同的工夫粒度进行聚合。在我看来，未来利用于工夫序列机器学习模型也会是它的一个亮点，在数据建模方面，针对工厂的设施、设施、机床、机房、车间、测台等必须要做高效精确的定义。咱们进行我的项目布局建设时，都会做大量的数据治理工作，然而在具体实施工作上，还是要应用这些传统工具和技术。TDengine 能够无效会集各种机器数据源，并且可能高质量的提炼，这个是过来的时序数据产品所不具备的。
“是提速，更是赋能”
中国有句话叫做“长江后浪推前浪，一代新人胜旧人”，IT 世界变幻无穷，如果你和我一样，始终在关注着 TDengine，就会发现，它这几年崛起的十分迅速。去年 TDengine 推出 3.0 版本，新版本升级成为了一款真正的云原生时序数据库，优化了流计算性能，而且还从新设计了计算引擎，优化工程师对 SQL 的应用，另外减少了 taosX，利用本人的数据订阅性能来解决增量备份、异地容灾，更加不便了企业应用。我对 TDengine 将来的冀望是，心愿它减少库内机器学习函数，减少 ARIMA 模型、MA 模型等工夫相干性能，TDengine 的将来是一个智能学习工夫序列数据库，对工业 4. 0 来说不仅是提速，更是赋能。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。
