作者：大数据模型 本篇文章出自 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 | OpenTSDB | InfluxDB |
| 使用场景 | 时间序列实时分析 | 时间序列实时分析 | 时间序列实时分析 | 时间序列实时分析 |
| 开发语言 | C | Java | Java | GO |
| 接口协议 | OLAP/JDBC | JSON | JSON | OLAP/JDBC |
| 发布时间 | 2018 | 2011 | 2010 | 2013 |
| 主要领域 | 工业领域 | 广告领域 | 运维领域 | 资源监控 |
| 产品生态 | 独立自治 | Hadoop生态圈 | Hadoop生态圈 | 独立自治 |
| 核心技术 | 超级表 | 预计算、实时聚合 | 使用时进行聚合 | 提前预计算 |
| 部署 | 一键部署、无依赖 | 需要搭建Hadoop，配置Java环境 | 需要搭建HBase，创建tsd数据、配置Java环境 | 部署简单、无依赖 |
| 集群 | 单机和集群版本双开源 | 集群方案成熟 | 集群方案成熟 | 开源仅支持单机 |
| 资源占用 | 资源占用少 | 资源占用多 | 资源占用多 | 资源占用少 |
| 存储引擎 | 自己独立研发 | 基于lambda架构的批处理能力和流处理能力 | 基于HBase的存储 | 自己独立研发 |
| 存储特点 | 单点写入，连续存储，跨维度指标融合的超级表 | 支持跨标签聚合，热数据保存内存中，冷数据保存在硬盘中 | 无法有效压缩，聚合能力弱 | 同一数据源的标签不再冗余存储，独立压缩 |
| 性能 | 查询更快，数据汇聚分析较快 | 查询更快，数据汇聚分析较快 | 数据写入和存储较快，但查询和分析能力略有不足 | 查询更快，数据汇聚分析较快 |
| 开发 | 架构简单，类SQL易开发 | API较为丰富 | API较为丰富 | 架构简单，类SQL易开发（仅限2.0前版本） |
“放到今天，TDengine 一定是首选”
我对 TDengine 的认识和了解要从过去的项目经验说起，以 2018 年为背景，我给大家讲述一个工业界坏件故障件预测的故事。 某知名集团随着公司业务的快速增长、新工厂的不断增加，各种有价值的数据不能很好的整合、分析与挖掘出它应有的价值。此时公司发展已经进入下一轮“拼”的战略，快速响应与准确预测是业务发展的关键，大数据在其中起到举足轻重的作用，以科学的分析手法整合各系统数据、推动工厂制造智能化发展，成为一件迫在眉睫的工作。 当前工厂生产过程中出现了同一种特殊问题的 glass id，glass 的品质由于各种原因是参差不齐的，甚至会有品质异常的 glass。这些异常 glass 在检测过程中，是无法检测出异常原因的，如果无法快速定位出异常原因，就会造成更多的异常 glass，严重影响生产。应对的具体手段包括：- 通过品质异常的 glass，找到产生此异常的相关性因子。如：机台、物料、载具、参数等。
- 异常 glass 侦测预警，通过对产生品质异常的因子进行数学建模，预测出偏离正常范围的异常玻璃，提前预警。
- 分析 glass 的特征值与特征值之间的关联关系，并建立预测模型，提前预测出 glass 的特征值。
- 分析 glass 相关的电压、电阻、电流、温度、湿度影响。
- 难以满足用户需求，某些机器数据的聚合计算需要第二天才能出结果，甚至更多的时间才能出来。
- 经济成本的费用较高，CPU、磁盘、网络都在一个高段的使用状态，针对越来越多的数据需要投入新机器。
- 维护成本高，你需要维护 Hadoop 所有的机器，各种 HBase、Spark、Zookeeper、HDFS 之类，不但对工程师要求高，而且工作量巨大。
- 低质量数据，因为数据流程或者错误的逻辑整合，导致机器传感器聚合后数据模型无法正常使用。
- 无法做到实时监测，机器数据作为宝贵的自变量因素无法及时传输并进行计算，自然会影响因变量。
“是提速，更是赋能”
中国有句话叫做“长江后浪推前浪，一代新人胜旧人”，IT 世界千变万化，如果你和我一样，一直在关注着 TDengine，就会发现，它这几年崛起的非常迅速。去年 TDengine 推出 3.0 版本，新版本升级成为了一款真正的云原生时序数据库，优化了流计算功能，而且还重新设计了计算引擎，优化工程师对 SQL 的使用，另外增加了 taosX，利用自己的数据订阅功能来解决增量备份、异地容灾，更加方便了企业应用。我对 TDengine 未来的期望是，希望它增加库内机器学习函数，增加 ARIMA 模型、MA 模型等时间相关功能，TDengine 的未来是一个智能学习时间序列数据库，对工业 4. 0 来说不仅是提速，更是赋能。想了解更多 TDengine Database的具体细节，欢迎大家在GitHub上查看相关源代码。
标签：存储,TDengine,Druid,数据库,投稿,时序,维度,数据 From： https://www.cnblogs.com/taosdata/p/17146695.html