共计 2719 个字符，预计需要花费 7 分钟才能阅读完成。
吉科软信息技术有限公司是国家高新技术企业，公司以“让天下没有不释怀的食品”为使命，以“做数字化保卫食品安全的领军企业”为愿景，以打造食用农产品全流程追溯、全流程监管、全流程服务、全产业链降级为外围的产业互联网生态链为主营业务，使用卫星遥感、5G 通信、大数据、云计算、物联网、区块链和人工智能等技术，推出一系列国内首创、行业当先和可落地的研发成绩，为智慧农业、智慧食安、智慧城市提供解决方案。
业务背景
车辆轨迹定位监控我的项目旨在通过车辆的轨迹监管、异样预警、历史轨迹回放，达成对车辆的对立监管、轨迹追踪、大数据分析及可视化利用等目标。该我的项目现已对数万台车辆通过车载定位设施上报定位数据至 GIS 网关服务，服务解析报文下发至音讯队列，利用再将定位数据写入 InfluxDB，最新车辆地位信息写入 Redis，为客户提供车辆实时地位跟踪和历史轨迹回放等查问剖析服务。
时序数据库选型
首先咱们梳理了以后车辆监管架构的次要个性和新需要：
- 继续高并发写入，带有 tag，工夫戳有时会乱序写入 (存在离线数据上传的状况，离线数据的工夫戳小于以后工夫戳)；
- 业务数量级增长快，预估将来每天写入约 8 亿条数据；
- 对基于工夫戳范畴的聚合查问，属于低频查问，通常是由用户触发，查问最近几天的轨迹，按执行工作的工夫进行轨迹回放。
- 实时查问需要，对每个车辆有最初一个定位点数据的查问需要，获取实时地位监控；
- 因为数据量十分大，所以须要反对数据压缩，降本增效；
- 冀望每个车辆独自建表；
- 需反对批量数据写入，且业务冀望写入延时较低；
- 车辆监管我的项目有产品国产化的需要，在中间件的抉择上需采纳国产化产品。
此前，咱们的我的项目一期采纳了 InfluxDB 时序数据库作为存储车辆轨迹数据，二期我的项目须要从新降级改版后进行全新架构设计，同时也要思考业务规模的快速增长、国产化要求及 InfluxDB 的单节点问题。
因而我司须要对时序数据库进行从新选型。咱们对业界支流的时序数据库做了剖析和测试：
- InfluxDB：由 InfluxData 开发的开源时序型数据。它由 Go 写成，着力于高性能地查问与存储时序型数据。被广泛应用于存储系统的监控数据，IoT 行业的实时数据等场景。毛病是开源版本只反对一个节点，开源版本没有集群性能, 存在前后版本兼容性问题，非国产化产品。
- OpenTSDB：基于 HBase 的分布式、可伸缩的工夫序列数据库。作为基于通用存储开发的时序数据库典型代表，起步比拟早，在时序数据库畛域的认可度绝对较高，但 HBase 老本高的问题无奈罢黜。
- TDengine：国产开源时序数据库，应用类 SQL 查询语言来插入或查问数据；通过间断查问，反对基于滑动窗口的流式计算；引入超级表，让设施之间的数据聚合通过标签变得简略灵便；内嵌缓存机制，每台设施的最新状态或记录都可疾速取得；分布式架构，反对线性扩大，以保障任何规模的数据量都能够解决；反对多正本，无单点故障，保证系统的高可用与高牢靠。这些性能和个性都十分合乎咱们的需要。
通过理论比照后、再加上迁徙改变最小化以及国产化需要等因素，咱们最终选定 TDengine 作为车辆轨迹数据的存储计划。
TDengine 的落地利用
初期咱们选用了三台服务器，搭建了 3 节点 3 正本的集群。目前已投入一批车辆经营监控，后续咱们将逐渐迁徙全副车辆的轨迹数据至 TDengine。
历史数据从 InfluxDB 迁徙至 TDengine，采纳的计划是基于 Datax 数据同步，咱们扩大开发了 InfluxDB 的读插件和 TDengine 的写插件，单过程数据同步可达到 6 万 / 秒的同步速度。（该速度受限于 influxdb 的读取，在该过程中 influxdb 的内存上涨过快撑不住，所以最终测试的同步速度 是 6 万 / 秒。目前官网已公布“基于 DataX 的 TDengine 数据迁徙工具和 taosAdaptor 工具”）
以迁徙的局部数据进行剖析：总数据量为 6.5 亿，散布在 14742 个子表中，占用磁盘空间 4.7G，压缩率达到 4%。开启了 cachelast 选项为 1 缓存子表最近一行数据，利用该缓存个性，查问指定车辆的最新 GIS 定位数据进行实时监控时，可间接从缓存中读取，放慢读取速度。
在应用 TDengine 之前，对于所有车辆的最新地位实时监控，咱们采纳的计划是在接管 gis 数据存储至 InfluxDB 时，同时将车辆的最新地位数据存储至 Redis 和 Mysql，应用 TDengine 后计划中对实时地位的存储间接应用 TDengine 的缓存子表最近一行数据的个性就能够实现，齐全能够去掉 Redis 和 Mysql 的存储。
TDengine 的性能体现
我的项目对车辆轨迹数据的利用场景次要集中在车辆实时地位监控、车辆工夫范畴内的轨迹回放。
1. 车辆实时地位监控场景：
查问单个或多个车辆的最新 GIS 地位数据。单个车辆最新地位查问：select last_row(*) from d_track where car_id in (‘dc8a9a0d7b634c9ba4446445c6c’);
利用查问超表的单个车辆最新地位数据工夫在 11 毫秒。如果间接锁定子表进行查问的话，select last_row(*) from _018d16c826cb405ea4a94a14cd4f95a9 ;
返回最初一条地位数据的响应工夫在 1 毫秒。
多个车辆的最新地位数据查问，仍旧应用超表联合标签进行查问，
查问响应工夫在 12 毫秒左右。
持续扩充查问范畴，查问 500~1000 个车辆的最新地位的查问响应工夫也能在 1 秒之内返回后果，齐全达到业务响应的工夫需要。
2. 工夫范畴内车辆的轨迹数据查问
指定车辆在指定工夫范畴内的轨迹数据查问，间接定位到具体的子表进行查问，select * from _0128a4d193424dcfb217242f054716d4 where time >’2021-09-08 10:34:44.000′ and time <‘2021-09-23 21:38:18.000’ ;
测试数据的查问响应工夫为 0.07 秒左右。
在以上两种数据查问场景中，TDengine 的性能不仅齐全可满足需要，更是比原 InfluxDB+Redis+Mysql 计划大幅度的晋升，解决了原计划中车辆查问较大时间跨度的轨迹数据响应超级慢的问题。
写在最初
非常感谢涛思的 TDengine，切实解决了咱们在国产化、性能、降本、平滑迁徙的刚性需要。也非常感谢涛思的罗格老师在咱们尝试和利用 TDengine 过程中给予的悉心领导，放慢了咱们对 TDengine 的把握，更快的利用落地。
以后 TDengine 的大规模利用车辆监管我的项目中，撑持现有数万辆车的行驶轨迹监控，将来将持续扩充规模撑持更多的车辆轨迹监控。
作者
孙运盛 吉科软技术研究院架构师
