共计 4327 个字符，预计需要花费 11 分钟才能阅读完成。
近年来，在能源和环保的压力下，新能源汽车成为了将来汽车倒退的新方向。为反对其疾速倒退，我国出台了一系列搀扶政策，在《新能源汽车产业倒退布局（2021-2035 年）》中就有提出，到 2025 年新能源汽车新车销售量要达到汽车新车销售总量的 20% 左右，其市场广大水平可见一斑。当初炽热的主动驾驶技术，也是新能源汽车的一大劣势，而主动驾驶又须要各类传感器产生的源源不断的时序数据来辅助判断，所以与时序数据相干的采集、解决和存储等各项需要也显著增长。
始终以来，对于新能源车企来说，在时序数据的存储上，抉择的大多都是 MongoDB 或 Apache HBase，这两大数据库技术绝对更加成熟，在业务规模尚未扩张之前，因为设施不多、数据量不大，加上查问场景繁多，尚且能够满足业务需要。随着业务的减速扩张，写入速度太慢、撑持老本过低等问题也逐步浮现。
以零跑汽车为例，此前他们将时序数据别离存储在 MongoDB 和 HBase 中，前者会将数据全副存储在内存中，过高的存储老本导致只能存储一段时间内的数据，且存储的数据格式须要通过业务组织解决，不仅业务变更不灵便，能够做的业务也十分无限。后者用来存储局部实时信号，须要整套 HDFS 做撑持，应用、运维和人力等老本都很高，须要大数据相干的人才能力保障安稳运行。而且公司的 HBase 环境是公有云环境，而云平台在私有云环境，跨专网业务时常会被网络问题影响。
在适合的时候抉择适合的数据库是反对业务倒退的要害，但数据库的更换也并不是头脑一热就能拍板决定的，还须要进行数据库产品的周密察看和调研，能力选中真正适宜本身业务倒退的“天选数据库”。那对于车企来说，到底什么样的数据库更加适宜呢？咱们无妨从它所产生的数据自身去做一下剖析。
从时序数据自身的特点看车企实用的数据库类型
当下车联网曾经成为车企布局将来的一个重要场景，如工业互联网一样其产生的数据分类为时序数据，而时序数据具备如下特点：
- 所有采集的数据都是时序的
- 数据都是结构化的
- 一个采集点的数据源是惟一的
- 数据很少有更新或删除操作
- 数据个别是按到期日期来删除的
- 数据以写操作为主，读操作为辅
- 数据流量安稳，能够较为精确的计算
- 数据都有统计、聚合等实时计算操作
- 数据肯定是指定时间段和指定区域查找的
而关系型数据库次要对应的数据特点却与之差异甚广：数据写入上大多数操作都是 DML 操作，插入、更新、删除等；数据读取逻辑个别都比较复杂；在数据存储上，很少有压缩需要，个别也不设置数据生命周期治理。很显然，关系型数据库是不适宜用于解决时序数据的。
企业在抉择数据库文件系统等产品时，最终目标都是为了以最佳性价比来满足数据写入、数据读取和数据存储这三个外围需要。而时序数据库（Time-Series Database）正是从以上特点登程、以时序数据的三个外围需要为最终后果进行设计和研发的，因而在数据处理上会更加具备针对性。
近年来，随着物联网的疾速倒退、业务规模和数据量的疾速暴发，国内外越来越多的科技企业发现了用传统关系型数据库来存储时序数据的问题，针对时序数据库的选型调研也由此开始。
目前市面上的时序数据库品种繁多，老将如 InfluxDB、Prometheus，后起之秀如 OpenTSDB、TDengine 等，在对本身业务进行时序数据库选型时，除了性能各方面的考量外，大部分企业还会考量其是否具备程度扩大能力。
在性能层面，TDengine 曾做过几家时序数据库的比照——TDengine 与 InfluxDB、OpenTSDB、Cassandra、MySQL、ClickHouse 等数据库的比照测试报告，聚焦工业互联网的和利时也从使用者的角度做过一些比照——从四种时序数据库选型中怀才不遇，TDengine 在工控畛域边缘侧的利用，大家可做参考。而在程度扩大能力方面，TDengine 早在 2020 年就实现了单机和集群版的双开源，同时凭借着性能上的硬核体现，深受着车联网、物联网、工业互联网等企业客户的青眼。
上面咱们以 TDengine Database 为例，看看时序数据库针对车联网场景下宏大的时序数据的写入、查问、存储是如何实现的。
基于 TDengine，你能够怎么设计架构和表
作为时序数据库引擎，TDengine Database 不须要基于 Hadoop 生态搭建，也不须要拼装 Kafka、Redis、HBase 等诸多组件，它将数据处理中的缓存、音讯队列、数据库、流式计算等性能都对立在了一起，这样轻量级的设计不仅让它的安装包很小、对集群资源耗费很少，同时也在肯定水平上升高了研发、运维老本，因为须要集成的开源组件少，因此零碎能够更加强壮，也更容易保证数据的一致性。能够试验一下，如果你要搭建一套车队管理系统，你只须要写一个 Java 利用，再加上 TDengine 齐全可能实现。
从时序数据的特点登程，TDengine 没有抉择风行的 KV 存储，而是应用了结构化存储。同时，基于物联网场景里，每个数据采集点的数据源是惟一的、数据是时序的，且用户关怀的往往是一个时间段的数据而非某个非凡工夫点等特点登程，TDengine Database 要求对每个采集设施独自建表。也就是如果有 1000 万个设施，就须要建 1000 万张表。
这就是 TDengine Database 的外围翻新点之一——“一个设施一张表”，以此保障每个采集点的数据在存储介质上以块为单位进行间断存储，缩小随机读的同时成数量级晋升查问速度，还能够通过无锁、追加的形式写入，晋升写入速度。
篇幅无限，对于 TDengine 的更多设计特点，大家如果有趣味能够移步官网查阅理解更多，在这里就不多做赘述了。
上面咱们来看一下两种数据库下的架构图，从中咱们也能够得出一个论断，抉择 TDengine Database 显著会更加轻量。
- 基于 HBase 的解决方案，架构图如下——
- 基于 TDengine 的解决方案，架构图如下——
在表数据的搭建上，通常车企在采集数据时蕴含的通常都是“采集工夫（工夫戳）、车辆标记（字符串）、经度（双精度浮点）、维度（双精度浮点）、海拔（浮点）、方向（浮点）、速度（浮点）、车牌号（字符串）、车辆型号（字符串）、车辆 vid（字符串）”这 10 类字段。
不同于其余时序数据库，TDengine 会为每辆车独自创立一张数据表，数据字段为采集工夫、车辆标记、经度、纬度、海拔、方向、速度等与工夫序列相干的采集数据；标签字段为车牌号、车辆型号等车辆自身固定的形容信息。这外面有一个小技巧，浮点数据压缩比绝对整型数据压缩比很差，经度纬度通常准确到小数点后 7 位，因而咱们能够将经度纬度增大 1E7 倍转为长整型存储，将海拔、方向、速度增大 1E2 倍转为整型存储。
超级表创立语句：create table vehicle(ts timestamp, longitude bigint, latitude bigint, altitude int, direction int, velocity int) tags(card int, model binary(10));
此前有研发人员应用 C 语言编写了一个车辆模仿数据生成程序，对 TDengine 进行测试，以 10 万张数据表，每张写入 1 个月的数据（数据距离 1 分钟，计 44000 条数据）为测试数据。编译之后，将测试程序和数据库在同一台 2 核 8G 的台式机上运行，写入工夫共计为 3946 秒，相当于 4400000000 条 /3946 秒 =111.5 万条 / 秒，折算成点数为 111.5*5=557 万点 / 秒。
在这里要留神的是，该程序是单线程运行的，如将其批改成多线程，速度还会有更大晋升，然而仅就目前的性能来看，对于车联网的场景也曾经足够。
从蔚来、零跑、现实三家车企，看时序数据库的利用成果
聚焦在理论业务中，时序数据库之于车联网的匹配度之高，咱们从 TDengine 的三个车企客户案例中也可见一斑。
对于蔚来汽车来说，随着业务的倒退，截止 2021 年底其曾经在全国各地布局了换电站 777 座，超充桩 3404 根，目充桩 3461 根，为用户装置家充桩 96,000+ 根。为了对设施进行更高效的治理，他们须要将设施采集数据上报至云端进行存储，并提供实时数据查问、历史数据查问等业务服务，实现设施监控和剖析。
但始终作为蔚来汽车数据存储的 MySQL + HBase 模型却越来越难以为继，随着换电站和超充站等设施在全国的疾速布局，设施数量持续增长，积攒的数据量越来越多，长时间跨度数据查问效率呈现瓶颈，再加上查问场景不断丰富，HBase 曾经无奈满足以后业务须要。他们决定从 OpenTSDB 和 TDengine 中进行抉择，在进行各种比照测试后决定将 HBase 替换为 TDengine。
从最终的革新后果上来看能够说是十分胜利了。在查问速度上，从应用 HBase 查问单设施 24 小时数据的秒级返回降级到应用 TDengine 查问雷同数据的毫秒级返回；在存储空间上，每天增量数据占用的存储空间相当于原来应用 HBase 时的 50%；在老本比照上，迁徙后集群计算资源老本相比应用 HBase 节俭超过 60%。
独一无二，零跑汽车面临着和蔚来汽车一样的窘境，他们此前在数据存储上的抉择是 MongoDB 和 HBase，随着业务规模的扩充，数据库性能越来越难以满足数据处理需要，老本也随之晋升。从降本增效的角度思考，零跑决定在 C11 新车型上试用 TDengine。
零跑科技在做数据库选型调研时只有两点诉求：性能强、成本低。而最终的事实证明，TDengine 的确没有辜负他们的期待。在查问上，TDengine 的列式存储能够间接以 SQL 计算，不必再像 MongoDB 一样，在查问前还须要依据业务加工出需要数据。同时 TDengine 的高压缩算法也助力零跑科技晋升 10-20 倍的压缩性能，既节俭了存储空间也解决了存储老本高的问题。
和前两面两家公司不同，现实汽车是从 TiDB 迁徙到 TDengine 的。整体来看，TiDB 更适宜 TP 或者轻 AP 场景。从现实汽车的角度而言，其写入性价比较低，一次性大批量写入场景也不太适宜，且对业务有入侵性，底层库表要依照月份来建表，还要针对每个采集点打上标签。
在迁徙到 TDengine 之后，现实汽车的机器应用老本显著升高，聚合类查问速度显著提成，引入了 firstEP 机制的弹性扩缩容在肯定水平上保障了性能的强劲，同时 TTL 和标签机制也实现了对业务的通明。
就如零跑汽车的我的项目对接人所感叹的一样，做汽车这样一种产品，数据量之大难以想象，如果没有一款可能实现高效存储的数据库，服务器老本会十分的高。
但当初他们都找到了破解窘境的无效办法。从实践到实际，时序数据库无疑都是车联网的“天选数据库”。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。
