近年来，在能源和环境保护的压力下，新的能源车已成为未来汽车开发的新方向。为了支持其快速发展，我的国家引入了一系列支持政策，并在“新的能源车辆行业开发计划（2021-2035）”，建议到2025年，新能源车辆的销量将达到汽车新车的总销量。大约20％的市场广阔性是明显的。
对于新的能源汽车公司，大多数时间数据存储的选择都是MongoDB或Apache HBase。这两个大型数据库技术相对成熟。在扩展业务规模之前，由于设备和数据不多，数据和数据数量不大，并且查询方案单可以满足业务需求。随着业务的加速扩展，写作速度太慢的问题和高昂的支持成本逐渐出现。
以零运行汽车为例。早些时候，他们分别将定时数据存储在MongoDB和HBase中。前者将将所有数据存储在内存中。过多的存储成本仅导致一段时间内的数据格式，并且需要用商业组织处理存储数据格式。业务不仅不灵活，而且可以完成的业务也非常有限。后者用于存储一些真实的时间信号，这需要整个HDF作为支持。使用，操作和维护以及人力的成本非常高。需要大型数据相关的人才来确保运行顺畅。此外，公司的HBASE环境是一个私人云环境，并且云平台在公共云环境中，并且特殊网络业务通常会受到网络问题的影响。
在合适的情况下选择正确的数据库是支持业务开发的关键，但是数据库的替换不是由Head Hot确定。它还需要对数据库产品进行细致的观察和研究，以选择实际的业务开发。“ Sky Election Database”。哪种数据库更适合汽车公司？我们还可以从其生成的数据中分析。
当前的汽车网络已成为汽车公司铺平未来的重要方案。工业互联网生成的数据的数据分类是定时数据，当前数据具有以下特征：
但是，关系数据库的主要数据特征与此不同：数据编写的大多数操作是DML操作，插入，更新，删除等；数据阅读逻辑通常很复杂；在数据存储中，它非常非常存储。几乎没有压缩要求，并且数据生命周期管理通常没有设置。显然，关系数据库不适合处理计时数据。
选择诸如数据库文件系统之类的产品时，最终目标是满足数据编写，数据阅读和数据存储的三个核心需求，具有最佳的成本效益。时间序列数据库是根据三个核心需求设计和开发的来自上述特征的时序数据，因此它将在数据处理中更具针对性。
近年来，随着物联网的快速发展，业务规模和数据量的迅速爆发，国内外越来越多的技术公司发现了使用传统的关系数据库存储定时数据的问题。
目前，市场上有许多类型的计时数据库。退伍军人（例如Infuxdb，Prometheus）以及后来的演出，例如OpentsDB，Tdengine等。在选择自己业务的正时数据库时，除了各个方面的考虑之外，大多数公司还将考虑是否拥有它。。
在性能级别上，Tdengine比较了几个计时数据库-tdengine和InfluxdB，OpentsDB，Cassandra，MySQL，Clickhouse，Clickhouse和其他数据库比较测试报告。比较 - 比较 - 从四个时序数据库选择中脱颖而出，Tdengine的应用程序在TDENGINE的应用程序上，在TDENGINE的应用程序上，在TDENGINE上的应用程序。在工业控制领域，您可以参考。根据水平扩展功能，Tdengine早在2020年就实现了两台支架和集群版本的双重开源。与此同时受到企业客户的青睐，例如物联网，物联网和工业互联网。
在下面，我们以Tdengine数据库为例，以了解如何在Internet中为大量顺序数据实现时间序列数据库。
作为计时数据库引擎，TDENGINE数据库不需要构建许多基于Hadoop Ecosystem的组件，例如Kafka，Redis，HBase和其他组件。这样，这种方式，轻巧的设计不仅使其安装袋非常小，而且很小，而且消耗了非常小的，也可以非常消耗。几乎没有集群资源，但也可以在一定程度上降低研发和运营成本。因为很少需要集成的开源组件，因此系统可以更易于确保数据的一致性更容易。如果您想构建团队管理系统，则只需要编写Java应用程序，再加上Tdengine可以完全实施。
从定时数据的特征开始，Tdengine没有选择流行的KV存储，而是使用结构存储。在同一时间，根据事物互联网方案，每个数据收集点的数据源是唯一的，数据是顺序的，是顺序的，用户关心时间段而不是特定时间点的特征。TDENGINE数据库要求为每个收集设备分别构建表，也就是说，如果有1000万个设备，则需要1000万个桌子。
这是TDENGINE数据库 - “一个设备，一个表”的核心创新点之一，以确保每个收集点的数据连续存储在存储介质的存储介质中，从而减少了随机读取和在查询查询中的数量在量化查询中，也可以通过不锁定或其他方法来提高写作速度。
有关更多空间，即Tdengine的更多设计特征，如果您有兴趣，可以查看官方网站以检查和了解更多信息，因此我不会在此处详细介绍。
让我们看一下两个数据库下的架构图。由此，我们还可以得出一个结论，即选择Tdengine数据库显然会更轻。
高度（浮点），方向（浮点），速度（浮点），车牌号（字符串），车辆型号（字符串），vid（string）”。
与其他计时数据库不同，Tdengine将为每辆车分开创建一个数据表。数据字段是与时间序列有关的收集数据，例如收集时间，车辆徽标，经度，纬度，高度，方向，速度等。。浮动点数据压缩比的压缩比非常差。小数点之后，经度纬度通常是准确到7位。增加1E2次，到集成存储。
超级监视创建声明：
早些时候，一些研发人员使用C语言来编写车辆模拟数据生成程序，测试Tdengine，带有100,000个数据表，每个书面数据（1分钟的数据间隔，44,000个数据）作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试的测试的测试的测试测试测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试的测试的测试的测试。测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试作为测试的测试的测试测试的测试作为测试作为测试作为测试的测试，测试是测试。DATA.DATA。编译后，测试程序和数据库在同一2 -CORE 8上运行G桌面。写作时间为3946秒，相当于440000000000/3946秒= 115万件/s/秒。转换点的数量为111.5*5 = 557.10,000点/秒。
应该在这里注意到程序正在以单个线程运行。如果将其修改为多线程，则速度将得到更大的提高，但是就当前的性能而言，车辆互联网的现场也足够了。
为了关注实际业务，Time -order -tory数据库在汽车的连接上很高，我们还可以从三家汽车公司的Tdengine客户案例中看到。
对于Weilai Automobile来说，随着业务的发展，截至2021年底，它在全国范围内部署了777个电站，3404个超级收费桩，3461个桩和96,000多个用户的根源。有效地，他们需要向云报告设备收集数据以存储它，并提供诸如真实时间数据查询和历史数据查询之类的业务服务，以实现设备监控和分析。
但是，一直存储在Weilai Automobile的数据存储中的MySQL + HBase模型已变得越来越不可持续。随着设备（例如电站和增压站）的快速布局，设备的数量继续增加，并且数据累积量正在增加。长期跨度数据查询效率具有瓶颈，并且查询场景不断丰富，HBase无法再满足当前的业务需求。他们决定从OpentsDB和Tdengine中进行选择，并在各种比较测试后决定用Tdengine替换HBase。
从最终转换结果来看，可以说这是非常成功的。从第二级返回升级的术语中查询相同的数据；在存储空间中，每日增量数据所占据的存储空间等于HBASE的原始使用。50％；在成本比较方面，与HBASE相比，迁移后计算资源的成本节省了60％以上。
巧合的是，零车辆与Weilai Automobile面临着相同的困境。他们先前在数据存储上的选择是mongoDB和HBase。随着业务规模的扩大，数据库性能变得越来越困难地满足数据处理需求。
零运行技术在进行数据库选择调查时只有两个要求：强劲的性能和低成本。最终事实证明，Tdengine并未达到他们的期望。在查询中，Tdengine的列存储可以直接在SQL中计算。不再需要根据MongoDB等业务处理处理需求数据。在同一时间，Tdengine的高压算法还可以帮助零运行的技术将压缩性能提高10-20次，这不仅可以节省存储空间，但还解决了高存储成本的问题。
与前两侧的两家公司不同，理想的汽车从tidb转移到TDENGINE。整体上，TIDB更适合TP或Light AP场景。从理想汽车的视角上，它的书写相对较低，并且相对较低，并且它不适合一个时间大量写入现场。它对业务具有侵入性。
迁移到Tdengine后，使用理想汽车机的成本大大降低，总查询速度显着委托，并且速度机制的弹性扩展能力在一定程度上保证了强大的性能。同时透明度。
正如零运行汽车的项目正在哀叹一样，很难想象数据量。如果没有可以实现有效存储的数据库，则服务器成本将非常高。
但是现在他们已经找到了破解困境的有效方法。从理论上到练习，时序数据库无疑是车辆互联网的“天空选择数据库”。
如果您想了解有关TDENGINE数据库的特定详细信息的更多信息，请检查GitHub上的相关源代码。
原始：https：//juejin.cn/post/70968136490580541