共计 2818 个字符，预计需要花费 8 分钟才能阅读完成。
小 T 导读：在 TDengine 安稳运行的数周工夫里，中天钢铁的新零碎均匀每周收录 3000 多辆车辆表与 100 多条船只表，每张表中数据或多或少，累计数量已达百万，业务的实际效果也达到了预期。本文分享了他们对于新我的项目的数据库选型、利用的思考，同时也进行了业务成果剖析。
为了满足业务倒退需要，咱们须要新开发一套性能，对厂内每辆运输车辆的实时 GPS 地位进行追踪，通过大数据平台对 GPS 坐标进行解决、剖析、可视化展现。同时也须要对公司货运船只进行实时监控，使用 GPS 平台的剖析解决能力对船只的航运轨迹进行预判，计算其是否偏离航线。这些 GPS 数据来自于中天云商 App，只有运输车辆司机关上云商 App，零碎每隔 10 秒会主动发送该车辆 GPS 信号到大数据平台，再由大数据平台剖析解决。
数据处理门路次要为，大数据平台将 ERP 中关联过合同的 MMSI 信息同步到 GPS 平台，由 GPS 平台挑选出 300 条船舶的 MMSI 同步至船达通平台，同时将接收数据接口地址发送到船达通平台，船达通平台会依据 MMSI 编号以及推送地址，每隔 10 分钟将该船只的最新地位以及动动态信息推送至 GPS 平台。基于此，调研到一个适合的数据库，对于实现我的项目的数据处理需要至关重要。
对于数据库选型调研的思考
实质上来讲，行车记录、行船记录都是时序数据，人造带有工夫戳，这些时序数据达到服务器时都是有序递增的，且时序数据的特点是流量安稳却十分微小，这点和电商数据不太一样，比方双十一时电商数据会呈现陡增，平时却没有那么高流量。作为典型的时序数据，车联网数据每隔 10 秒或 10 分钟发送一条，绝对固定，在调研时咱们发现，TDengine“一辆车一张表”的模型很符合这一场景。
同时，时序数据在查问时要匹配特定的工夫线或数据标签，且实时状态查问、数据降精度、整体趋势剖析较多，一般数据库无奈提供这种函数。基于“一辆车一张表”这样的设计，TDengine 可能实现任何一台设施采集的数据，在存储介质里都是一块一块间断寄存的，且依照工夫排序，保障了在查问单个设施一个时间段的数据时，查问性能可能有数量级的晋升。
另外一方面，尽管不同设施因为网络的起因，达到服务器的工夫无法控制，是齐全乱序的，但对于同一个设施而言，数据点的时序却是能够保障的。“一个设施一张表”就保障了一张表插入的数据是有时序保障的，这样一来数据插入操作就变成了一个简略地追加操作，插入性能也有了大幅度晋升。
在压缩性能上，通过下表几家 Database 的比照，也可看出 TDengine 的优良：
同时 TDengine 针对同类型设施间的聚合问题，创新性地提出超级表的概念，让多设施间的聚合变得灵便不便，也让实时数据大屏显示、监测设施分类管理变得极其简略。总结而言，TDengine 针对时序数据的写入、存储、索引、查问等方面都进行了特定的优化，从而实现了更优的数据加载、压缩、查问、写入性能，十分匹配工业传感器数据的利用剖析场景。
尽管接入设施繁多，但 TDengine 兼容性很强，写入、读取和统计效率也大大高于其余同类型数据库。比照 InfluxDB 来看，其测试数据显示如下：
为了评估不同长度的工夫窗口对查问性能的影响，咱们选取了第四个查问场景，设定并行执行的 work 数量 16，工夫区间是随机选取的 1h / 2h / 4h / 8h / 12h 等间断时间段，单个聚合工夫窗口维持在 1min 不变。取得的查问响应工夫如下所示：
平台架构的实现
下图是咱们的数据处理门路图，数据通过中天云商、船达通平台将数据抽到 GPS 平台，通过 GPS 平台剖析解决后将数据存入数据仓库（TDengine）。
基于 TDengine，GPS 平台会对实时获取的 GPS 数据以及 AIS 数据进行剖析解决和存储，再通过每辆车、每条船对应的表，实现车辆船只轨迹可视化。
依据业务不同，咱们创立了两张超级表，别离为车超级表与船超级表。超级表是具备沟通的 Schema 独特元数据表的汇合，能够认为创立一个超级表，它上面可能再次创立很多子表，对超级表的查问相当于作用到它上面所有的子表。
比方当你要查一个超级表的平均值，假如它上面有 100 万张表，我就相当于对这 100 万张表做了查问，这样用一个超级表就解决了这个问题。每新增一条信息则按照对应载具信息新建子表或者在已有子表中插入最新数据。
测试与查问
目前 TDengine 在咱们的生产环境中运行安稳，通过对生产环境的机器进行检测，CPU 使用率平时不到 1%，内存使用率稳固在 25%。下图为集群中一台机器的监控图表：
在 TDengine 安稳运行的数周工夫里，中天钢铁的新零碎均匀每周收录 3000 多辆车辆表与 100 多条船只表，每张表中数据或多或少，累计数量已达百万，业务的实际效果也达到了预期。
当初能够依据车辆车牌号、须要查问的工夫区间来可视化车辆轨迹。在数据库中存储上车辆信息工夫、经纬度、车牌信息，在展现页面中就会实时显示以后厂内所有提货车辆的最新地位（前提是必须放弃中天云商处于关上状态），当车辆提货出厂后，则不再发送 GPS 信息，零碎会将该车辆判断为离线状态，不再显示。或者当司机异样敞开中天云商超过 8 个小时，零碎也将视该车辆为离线，从屏幕显示中去除，直到从新接管到 GPS 信号。
依据船舶名称、须要查问的工夫区间，就能够查问该艘船只的历史 AIS 轨迹图，如果有的船只中途异样敞开 AIS 信息发送安装，则零碎无奈接管到该船只的 AIS，展现的历史轨迹中则会呈现间断。船只 AIS 信息永恒保留在 TDengine 库中，在其中能够查问任意时间段内的 AIS 轨迹。
将来布局
本次在中天钢铁 GPS 平台车辆调度中应用了 TDengine，咱们发现它不仅性能高效，在设计上也很人性化，其反对的 SQL 查问语句，让人无需学习就能立即上手。再就是对于 TDengine 在监控畛域的利用，监控无非是做一个数据的存储，数据库的存储性能相当重要，TDengine 体现很突出。
总而言之，TDengine 的利用真正让车联网、工业互联网、运维监测大数据平台的搭建变得简略，不仅升高硬件老本、运维老本，还能大幅升高对研发和运维人员的需要。后续咱们也会持续分享 TDengine 的更多利用场景和实践经验等，给到大家参考。
当然，对于 TDengine 咱们也有一些倡议，心愿它可能倒退地越来越好：
- 反对更加丰盛的 SQL 语句：可能针对特有的场景，提供更加灵便的 SQL 语句，便于做更加简单的计算剖析，这也是 AIOps 的进阶局部。
- 子表主动清理性能：因为域名会存在下线问题，目前的 TTL 策略只是针对数据而不是 Table 自身，淘汰子表还须要人工运维染指。
- 当初 TDengine 对于数据的更新只有雷同工夫戳笼罩这种方法，心愿能提供数据删除性能（小 T 提醒：TDengine 2.6 企业版曾经提供删除性能 ⬅️点击链接文章看详情）。
- 提供简洁易操作的可视化界面，如 Navicat 之于 MySQL。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。
