# 数据模型和设计 ## 数据模型 ### 物联网典型场景 在典型的物联网、车联网、运维监测场景中,往往有多种不同类型的数据采集设备,采集一个到多个不同的物理量。而同一种采集设备类型,往往又有多个具体的采集设备分布在不同的地点。大数据处理系统就是要将各种采集的数据汇总,然后进行计算和分析。对于同一类设备,其采集的数据类似如下的表格: | Device ID | Time Stamp | Value 1 | Value 2 | Value 3 | Tag 1 | Tag 2 | | :-------: | :-----------: | :-----: | :-----: | :-----: | :---: | :---: | | D1001 | 1538548685000 | 10.3 | 219 | 0.31 | Red | Tesla | | D1002 | 1538548684000 | 10.2 | 220 | 0.23 | Blue | BMW | | D1003 | 1538548686500 | 11.5 | 221 | 0.35 | Black | Honda | | D1004 | 1538548685500 | 13.4 | 223 | 0.29 | Red | Volvo | | D1001 | 1538548695000 | 12.6 | 218 | 0.33 | Red | Tesla | | D1004 | 1538548696600 | 11.8 | 221 | 0.28 | Black | Honda | 每一条记录都有设备ID,时间戳,采集的物理量,还有与每个设备相关的静态标签。每个设备是受外界的触发,或按照设定的周期采集数据。采集的数据点是时序的,是一个数据流。 ### 数据特征 除时序特征外,仔细研究发现,物联网、车联网、运维监测类数据还具有很多其他明显的特征。 1. 数据是结构化的; 2. 数据极少有更新或删除操作; 3. 无需传统数据库的事务处理; 4. 相对互联网应用,写多读少; 5. 流量平稳,根据设备数量和采集频次,可以预测出来; 6. 用户关注的是一段时间的趋势,而不是某一特点时间点的值; 7. 数据是有保留期限的; 8. 数据的查询分析一定是基于时间段和地理区域的; 9. 除存储查询外,还往往需要各种统计和实时计算操作; 10. 数据量巨大,一天采集的数据就可以超过100亿条。 充分利用上述特征,TDengine采取了一特殊的优化的存储和计算设计来处理时序数据,能将系统处理能力显著提高。 ### 关系型数据库模型 因为采集的数据一般是结构化数据,而且为降低学习门槛,TDengine采用传统的关系型数据库模型管理数据。因此用户需要先创建库,然后创建表,之后才能插入或查询数据。 ### 一个设备一张表 为充分利用其数据的时序性和其他数据特点,TDengine要求**对每个数据采集点单独建表**(比如有一千万个智能电表,就需创建一千万张表,上述表格中的D1001, D1002, D1003, D1004都需单独建表),用来存储这个采集点所采集的时序数据。这种设计能保证一个采集点的数据在存储介质上是一块一块连续的,大幅减少随机读取操作,成数量级的提升读取和查询速度。而且由于不同数据采集设备产生数据的过程完全独立,每个设备只产生属于自己的数据,一张表也就只有一个写入者。这样每个表就可以采用无锁方式来写,写入速度就能大幅提升。同时,对于一个数据采集点而言,其产生的数据是时序的,因此写的操作可用追加的方式实现,进一步大幅提高数据写入速度。 ### 数据建模最佳实践 **表(Table)**:TDengine 建议用数据采集点的名字(如上表中的D1001)来做表名。每个数据采集点可能同时采集多个物理量(如上表中的value1, value2, value3),每个物理量对应一张表中的一列,数据类型可以是整型、浮点型、字符串等。除此之外,表的第一列必须是时间戳,即数据类型为 timestamp。有的设备有多组采集量,每一组的采集频次是不一样的,这是需要对同一个设备建多张表。对采集的数据,TDengine将自动按照时间戳建立索引,但对采集的物理量不建任何索引。数据是用列式存储方式保存。 **超级表(Super Table)**:对于同一类型的采集点,为保证Schema的一致性,而且为便于聚合统计操作,可以先定义超级表STable(详见第10章),然后再定义表。每个采集点往往还有静态标签信息(如上表中的Tag 1, Tag 2),比如设备型号、颜色等,这些静态信息不会保存在存储采集数据的数据节点中,而是通过超级表保存在元数据节点中。这些静态标签信息将作为过滤条件,用于采集点之间的数据聚合统计操作。 **库(DataBase)**:不同的数据采集点往往具有不同的数据特征,包括数据采集频率高低,数据保留时间长短,备份数目,单个字段大小等等。为让各种场景下TDengine都能最大效率的工作,TDengine建议将不同数据特征的表创建在不同的库里。创建一个库时,除SQL标准的选项外,应用还可以指定保留时长、数据备份的份数、cache大小、文件块大小、是否压缩等多种参数(详见第19章)。 **Schemaless vs Schema**: 与NoSQL的各种引擎相比,由于应用需要定义schema,插入数据的灵活性降低。但对于物联网、金融这些典型的时序数据场景,schema会很少变更,因此这个灵活性不够的设计就不成问题。相反,TDengine采用结构化数据来进行处理的方式将让查询、分析的性能成数量级的提升。 TDengine对库的数量、超级表的数量以及表的数量没有做任何限制,而且其多少不会对性能产生影响,应用按照自己的场景创建即可。 ## 主要模块 如图所示,TDengine服务主要包含两大模块:**管理节点模块(MGMT)** 和 **数据节点模块(DNODE)**。整个TDengine还包含**客户端模块**。