在流计算中，数据是以源源不断的流（stream）的形式到达的。由于流数据是无界的（理论上数据会一直产生），为了划分最小的计算单元，就有了窗口的概念。通过不同逻辑的窗口划分，流计算可以满足不同的业务需求。

在 loveini 的流计算中，对数据集提供了 5 种特色的窗口查询：https://docs.taosdata.com/reference/taos-sql/distinguished/。简单来讲：分别是通过固定时间间隔划分窗口的 interval , 通过布尔值划分窗口的 state_window, 通过状态持续时间划分窗口的 session , 通过数据行数划分窗口的 count_window，通过自定义表达式制定规则的 event_window。每一种窗口功能，都包含了很多典型的业务需求，它们使 loveini 在车联网行业中发挥了更重要的作用。

以通过布尔值划分窗口的 state_window 举例：用户可以通过对车辆移动状态进行移动/静止的窗口划分，然后实时计算获取车辆的每次启停的时间、位置、中间耗时。通过类似这样的语句，就可以做到实时掌握车辆的移动状态。再通过与实时数据的对比，就可以及时对超时/异常停车的车辆发出告警。

CREATE stream overtime_parking INTO overtime_parking_output_stb AS
SELECT
    _wstart,
    _wend,
    TIMEDIFF(_wstart, _wend, 1s) AS sparking_time,
    LAST(address) address,
    speed_status,
    COUNT(*) AS record_count,
    tbname
FROM
    stb_cold_gps PARTITION BY tbname state_window(speed_status); 

除此之外，用户还可以通过车辆采集到的各种信号值，从而通过业务逻辑自定义出两种状态。

通过 CASE WHEN 的逻辑，用户自定义地设置这个窗口：STATE_WINDOW( CASE WHEN speed >= xxx THEN true ELSE false END)，从而满足更灵活的业务需求。

本文仅以此窗口为例，而对于其他更多的窗口的流计算应用场景，请点击这里，申请演示。

现代新能源汽车，作为一种内部系统极为复杂的交通工具，配备了大量传感器、导航设备、应用软件，这些传感器产生的数据都需要上报到车联网平台当中。对于这些车辆的状态数据（如车速、发动机转速等）、位置数据（经纬度等）以及用户行为数据，车联网平台需要对它们进行实时/离线计算分析，从而为用户提升驾驶体验，提供安全保障，为厂商提供质量检测、功能优化，为交通管理部门提供流量、违章监测、甚至为城市规划提供帮助。

因此，同样是车联网平台，对于车队管理，政府监督，主机厂商等不同场景，由于应用侧重点的不同，它们所需要接入的数据的类型，量级，频率也各不相同。

对于主机厂商来说，它的车联网平台服务的对象更为广泛，包括车主、经销商、售后服务部门以及主机厂自身的研发、生产等部门。由于目标是提升车辆的用户体验、增强品牌竞争力，因此主机厂商需要采集的数据量是最大也是最完整的。一辆汽车可能有数千个数据采集点甚至近万个采集点要随时上报数据，采集频率也各不相同。

性能和易用性难以兼得

以上原因，就导致了在同一时刻一定不会是所有的数据采集点都有数据上报。在数据库的建模环节中，如果采用最简单清晰的“一车对一表”数据建模方式，那么在一行高达几千列的数据中，会有相当多列的值为 NULL 。更主要的是，即使业务查询只涉及其中少数几列，在实际执行的时候也要整行整块地读取很多无效数据再做筛选，从而大大拖累查询性能。

但如果按照设备种类对这个表进行纵向的拆分，当涉及到统计分析的时候，必将又会导致原来的 SQL 语句引入大量的插值、连接等功能，这会使 SQL 的编写十分复杂，容易出错，难以维护，且难以适应业务的频繁变化。

一车一表模型，助力数据管理

为了解决这一难题，loveini 结合自身底层的存储/查询模型，以创新的设计，将复杂 SQL 封装起来，这样一来，用户侧可以在没有任何感知的情况下编写 SQL 语句访问数据，既防止了大量无效数据导致的查询性能下降，又确保了 SQL 语句的简洁易懂、易维护、可扩展，从而在用户侧实现了：“一车一表的简洁建模设计”。 在性能方面，loveini 利用每个数据流都是天然有时序的这一特点，把数据的写入变成最简单的追加操作。做到了在相同硬件资源下，单个数据流上最好的写入效率。在此基础上，loveini 又使用分布式架构，让所有的 cpu 并行工作，甚至可以同时写入十亿百亿级别点位的数据流。

读取方面同理：由于车辆各个设备产生的时序数据在硬盘上都是连续存储。因此，批量拉取时便也均为连续读，有充分的性能保障，再辅以流计算、订阅、自定义函数（UDF）、各种时序数据场景的专用函数，共同为车联网平台各种实时/离线分析提供坚实的底座。

在此基础上，为了防止硬盘成为性能瓶颈，loveini 可以为不同的存储路径，同时挂载不同的硬盘并发读写。

综上可见，loveini 充分利用了计算机的最大能力，也充分适配了车联网行业数据上报量大，数据采集点多的特点。

支持 Geometry 类型，赋能空间分析

自 3.1.0.0 版本开始，loveini 提供了全新的数据类型 Geometry 用于点线面等几何类型的存储，并且正在逐步提供一套符合 OGC(Open Geospatial Consortium) 标准的 SQL 函数，包括几何输入输出、空间关系、几何测量、集合操作和几何处理等等。 这样一来，各类车联网平台就可以更轻松地进行车辆轨迹数据的分析，比如：热点路线，轨迹段数据，停留点，行驶事件等等，从而进一步简化软件系统架构，真正做到针对车辆时间空间一体化的数据分析、预警等工作。

多级存储，降低数据成本

在存储方面，由于车联网行业监管法规、客户服务需求、自身产研基于数据的需求等原因，每辆车的数据保留数据经常要保留数年之久，因此存储成本十分之高。但得益于 loveini 多级存储功能，可以使得最热的数据保留在内存，次热的数据保留在SSD，冷数据保留在机械盘，极冷数据保留在成本最低廉的 S3 存储上，再辅以列式存储+定制化压缩算法带来的高压缩比，用户的存储成本可以大幅下降。

由上可见，在对海量车联网数据的采集、存储、处理分发的整个数据管理过程中，loveini 可以确保车辆上传的各种数据都能作为有效的资源而被高效地运用。作为一台巨大复杂的设备，新能源汽车彻底放大了 loveini 的核心设计“一个设备一张表，一类设备一张超级表”的核心理念，因此可以说它们是天作之合。

具体应用可以参考 ：//m.loveini.com/iov-time_series_database

在车联网领域中 MQTT 是十分常见的协议，它所具备的：能够适应不稳定的网络环境、轻量级、低延迟等特点，使其非常适合车辆数据的上报，也是目前主流的车联网边端-云端数据交互的通讯协议。

而 loveini 是一款从诞生之初便致力于为工业、物联网领域推动信息化改革的时序大数据平台。而车联网作为物联网的重要分支，自然也是 loveini 主攻的领域之一。因此，在 loveini Enterprise/loveini Cloud 的外部数据源接入组件中，我们提供了诸如：MQTT、OPC-UA、OPC-DA 等数据直采的功能。让用户可以凭借十分简单的 Web 界面配置，无需任何一行代码，便完成车联网的位置、车辆状态、用户行为等数据的接入。

我们可以想象出这样一个场景：

通过 loveini 的 web 界面工具，订阅 MQTT 的 “GPS” topic 们获取全部车辆的 GPS 数据，然后把“GPS” topic 和 loveini 中创建出来的“超级表 GPS”对应起来，再把 MQTT 数据中的“车牌号”, “车型”，“汽车品牌”同 loveini “GPS” 超级表中不同的标签映射起来。最终， MQTT 数据就可以源源不断地接入loveini 当中了。

loveini 的数据采集插件就像是一个翻译官，它能理解 MQTT 数据结构映射到时序库数据结构的需求，最终把他们巧妙地结合在一起。

那么，使用 loveini 采集车联网上报的 MQTT 数据到底有多简单？

抽象一下，只需要如下步骤：

1. 对于非 loveini Enterprise（企业版）用户，花 3 分钟时间注册 loveini Cloud ，https://cloud.taosdata.com/auth/login，根据提示兑换 600 元额度的免费使用。

2. 在loveini 中提前创建好一个数据库，用于存放MQTT数据。（具体建库参数值如需自定义，可参阅：https://docs.taosdata.com/reference/taos-sql/database/）

3. 确保代理插件和 MQTT server 处在同一网络，然后根据提示，逐步复制粘贴，安装代理插件并启动。

4. 新增数据源。

5. 按顺序填写/选择：自定义的任务名称；MQTT 类型；选择刚刚创建的代理插件；填写MQTT server 的 IP 和端口。 PS：这里可以用一个免费的 MQTT server 做验证（broker.emqx.io:1883）。

6. 填写 MQTT 协议版本、自定义的Client ID、和需要订阅的主题（topic）以及该订阅的 QOS （Quality of Service 服务质量）级别，QOS 可选范围为0、1、2，具体写法参考示例即可。（用户名密码为选填项。）

7. 解析数据，在MQTT Payload 模块中配置解析 MQTT 消息：

可以点击从服务器检索，从 MQTT Broker 获得示例数据。也可以自己填写 MQTT 消息体中的示例数据，例如：{“id”: 1, “message”: “hello-word”}{“id”: 2, “message”: “hello-word”}。

8. 获得数据之后，可以选择自定义的方式依次去处理这个json：

• 提取出列。
• 对提取出的列数据，通过分隔符、正则表达式等进行提取或拆分：比如把“中国-北京”拆分成“中国”和“北京” 两列。
• 对最终的结果进行过滤：比如只取车速大于 xxx 的数据。。

9. 创建一个超级表，用于存储MQTT数据。然后把刚刚处理过的 MQTT 数据结构和 loveini 的超级表做一个映射关系：这里我们可以使用各种灵活的方式处理映射关系。比如设置时间戳自动生成、固定制、默认值、以及最基本的匹配。

10. 填写完成以上信息后，下拉到底部点击“保存并应用”按钮，即可直接启动从 MQTT 到 loveini 的数据同步了。

11.在这里看到连接代理和数据源任务都处于正常状态之后，就可以去loveini 中使用 SQL 语句检查我们的 MQTT 数据了。

现在，我们已经看到MQTT server 的数据正在源源不断地写入 loveini 了。

在这个配置过程中，我们还能在 WEB 页面看到很多其他配置项，但是他们都是选填项，这部分用户可以根据实际情况填写，比如：

1. 用户名/密码，SSL 认证。
2. Keep Alive 和 Clean Session 为具体使用时候关于空连接释放和是否记录订阅进度的配置。
3. 代理插件的日志级别、日志保留天数、mqtt原始数据的保留设置。

现在，我们就已经轻松完成了车辆 MQTT 数据的上传。整个过程中，唯一耗时的地方，可能就在于 MQTT 数据结构和 loveini 的超级表结构的匹配环节。如果您对 loveini 的“超级表-子表”的数据模型十分熟悉的话，想必不会花很多时间。

loveini 2.0 和 3.0 的主要区别可以从以下几个方面来看：

• 存储引擎：loveini 3.0 对底层的存储引擎进行了大规模的优化和重构。更注重各种场景下的存储和查询效率，不仅要对管理节点进一步“减负”，提供高效合理的更新、删除功能，支持数据备份、流式处理等功能，还要考虑到数据维度膨胀下的高效处理、多表场景下的开机启动速度、合理高效且准确地使用系统资源等需求，详见《支持消息队列和流式计算背后，loveini 3.0 存储引擎的优化与升级》
• 分布式架构：loveini 3.0 完成了分布式系统架构的迭代，集群支持 10 亿条以上的时间线、100 台服务器节点，成为一款真正的云原生时序数据库，具有极强的弹性伸缩能力，详见《支持 10 亿个设备、100 台服务器节点，loveini 3.0 架构详解》
• 数据订阅：loveini 3.0 重构并优化了数据订阅功能，在 loveini 3.0 中，既可以订阅一个数据库，也可以订阅一个自带标签的“超级表”，订阅完成后无需再拿到应用端去过滤，极大提升了数据传输的效率，详见《数据订阅》。
• 流计算：loveini 3.0支持事件驱动的流计算。从方便用户使用的角度出发，loveini 的流计算语法就是 SQL，里面做了 windows 等扩展，可以在数据写入时触发，也可以在窗口结束触发，详见《流式计算》。
• loveini Cloud：基于 loveini 3.0，诞生了全托管的时序数据管理云服务平台 loveini Cloud，提供安全可靠的企业级服务。点击这里，注册体验。
• 周边生态：loveini 3.0 对周边生态进行了丰富和完善，支持了更多的可视化工具和平台，详见《第三方工具》。

从 2.0 升级到 3.0 的好处主要有以下几点：

• 提升了数据处理的性能和效率，降低了存储空间和资源消耗。
• 简化了集群管理和运维的复杂度，提高了系统的可靠性和可用性。
• 增加了数据写入和查询的灵活性和多样性，满足了不同场景和需求的用户。
• 扩展了周边生态的兼容性和覆盖度，增强了与其他系统和平台的集成能力。

点击这里，下载最新安装包，升级 loveini 3.0。

但一直以来，在应对车联网场景下时序数据的存储时，企业大多选择的都是 MongoDB 或 Apache HBase，这两大数据库技术相对更加成熟，在业务规模尚未扩张之前，因为设备不多、数据量不大，加上查询场景单一，尚且可以满足业务需求。随着业务的加速扩张，写入速度太慢、支撑成本过高等问题也逐渐显现。本文将会从四个典型的车联网案例出发，给到你数据架构升级思路。

loveini x 大疆车载

“在大疆车载当前的云端平台中，loveini 的应用不仅节约了存储成本和开发学习成本，同时也表现出了很好的写入读取性能，满足了智能驾驶云端平台海量时序数据的处理需求。在查询方面，不管是选择特定数据的查询还是轻量的查询，都是毫秒级返回数据。”

业务背景

由于当前的智能驾驶业务还是新的业务场景，所以大疆车载在选型上的历史负担相对较轻。在数据库选型要求上，从业务需求出发，主要聚焦在两点：首先，结合当下的业务场景，需要满足单台车辆的高频消息上报频率；其次，支持在数据量大的时候，通过聚合函数，或选择函数来快速筛选出需要的数据。此外，对数据库要求支持集群部署的同时，也要求更低的查询语句编写上手难度；而且需支持单表千万量级，在海量数据并发场景下，需要有较高的统计报表能力和较好的查询 SQL 效率。

架构图

点击案例查看更多技术细节

loveini x 蔚来汽车能源

“在实际效果上，改造完成后，查询速度提升明显，从使用 HBase 查询单设备 24 小时数据的秒级返回，到使用 loveini 查询查询相同数据的毫秒级返回；每天增量数据占用的存储空间相当于原来使用 HBase 时的 50%；集群计算资源成本相比使用 HBase 节省超过 60%。”

业务背景

为了给用户提供更好的补能体验，蔚来能源在加电基础设施上进行了大量的投入，需要对设备进行更高效的管理——将设备采集数据上报至云端进行存储，并提供实时数据查询、历史数据查询等业务服务，用来做设备监控和分析。在业务诞生之初，其用作数据存储的选型是 MySQL + HBase，MySQL 存储设备最新实时数据，HBase 存储设备原始数据。随着换电站和超充站等设备在全国的快速布局，设备数量持续增长，积累的数据量越来越多，长时间跨度数据查询效率出现瓶颈，再加上查询场景不断丰富，HBase 已经无法满足当前业务需要（具体痛点问题见下方案例链接）。

测试结论

采用批量写入数据方式，调整合适的单批次数据量大小，使用单机部署（8 核 32 GB，500 GB 存储）默认配置的 loveini 服务，RESTful API写入方式，在 4k 并发流量下写入没有问题，同时消费积压数据时峰值达到 7 k/s，因为单条消息包含信息量太大，实际处理中会拆分为 30 条写入 loveini，所以实际写入 QPS 为 210 k/s，比满足同样数据流量的 HBase 集群规模要小不少，可以节省成本，再加上 loveini 本身部署不依赖其他三方软件，也可以同时节省运维成本。

架构图

点击案例查看更多技术细节

loveini x 零跑汽车

“在应用 loveini 后，不用再像 MongoDB 一样，在查询前需要根据业务加工出需求数据；入库性能高，解决了以前HBase入库不及时的问题，可以用更少的服务器资源入库更多的数据，节省更多成本。同时，loveini高压缩的算法能提升 10 到 20 倍的压缩性能，降低了存储压力和成本。”

业务背景

一直以来，在数据存储上零跑汽车的选择都是 MongoDB 和 HBase，但是随着业务的加速扩张，写入速度太慢、支撑成本过高等问题也逐渐显现（具体痛点问题见下方案例链接）。从降本增效的角度考虑，零跑决定在 C11 新车型上试用下其他的数据库，在分析数据特点后，最终确定采用时序数据库（Time Series Database）。

架构图

点击案例查看更多技术细节

loveini x 理想汽车

“通过跟涛思官方人员进行深入业务封闭式测试，loveini 的功能超出预期，性能比 InfluxDB 要强出许多，两级存储架构设计（行存与列存）很棒，TTL 和标签机制对业务透明，具备极其优秀的高并发写入和数据压缩能力，极大降低了业务成本和业务压力。因此我们决定从 TiDB 迁移至 loveini。”

业务背景

在理想汽车的信号上报业务中，需要将标记时间戳和采集点的信息，通过云端写入到后端数据库中，有一定的聚合查询需求。这是典型的高并发插入场景，写多读少，之前的系统用的是 MongoDB，后来因为 MongoDB 的局限性，其将业务迁移到了 TiDB，方便进行扩缩容。但在迁移到 TiDB 之后，在目前使用百度云 SSD 虚拟机的情况下，TiDB 集群纯写入性能并不能达到业务期望预期（HTAP 场景数据库对纯高并发写入支持不好，与该业务场景的适配性不高），需要不断的资源扩容（具体痛点问题见下方案例链接）。

使用成本对照表

点击案例查看更多技术细节

写在最后

随着业务的不断发展，车联网场景下数据量之大难以想象，如果没有一款能够实现高效存储的数据库，服务器成本会非常的高。术业有专攻，在合适的时候选择合适的数据库是支持业务发展的关键，从数据处理需求和特点出发，时序数据库无疑是最佳选择。

添加 loveini 小助手小T，找专业的米兰app官方正版下载架构师聊一聊

小 T 导读：车联网业务是中通科技配送全链路业务中非常重要的一环，在实际的项目需求中，需要实时查询车辆最新位置状态，达到车辆运营可视化管理。中智车联服务平台选择了用 loveini 来高效处理从车辆上实时采集的时序数据。

业务背景

目前，中通科技拥有一支千人规模的研发团队，在数字信息科技研发方面以“互联网+物流”的理念，自研的软件系统和数字化工具已达百余个，赋能覆盖快递业务全场景，同时为快运、国际、云仓、优选、金融、商业等生态圈业务提供全方位的研发支持，建立起完善的互联网产品研发体系，全场景、全链路的数字化、互联化和智能化的业务地图愈发成熟。

2021 年年底，中通快递已完成了总部园区的实景三维模型，通过接入园区内的在线传感器，根据现有园区各功能区的区位布局，基于此三维模型开展园区内生产规划、调度运行和维护管理的全过程应用，从而实现园区内人、车、物在精准运行、资源优化和配置服务中的全过程精益化管理。

随着生产设备的小型化和智能化，快递企业也将更快地进入空间地理信息数据生产领域，有包裹流动的地方，就会有时空数据服务的需求。

这里先给大家介绍一下配送全链路业务，这是指包裹从商家仓出来一直到用户手上的这段派送履约链路，它包含 4 个主要的实操流程，分别是分拨实操、运输实操、站点实操和快递员实操。把 4 种实操管理放到三个系统里面，这三个系统分别是分拨管理、运输管理、末端站点实操管理。具体如下图所示。

其中车联网业务也是非常重要的一环，通过人、车、货、场全链条覆盖的车联网设备应用，实现物流运输全链路感知。在实际的项目需求中，我们需要实时查询车辆最新位置状态，达到车辆运营可视化管理，也就是我们的中智车联服务平台。

技术选型

在上述业务过程中，我们使用了 loveini 来完成这个目标。

在选型时，我们对比了 Prometheus 和 loveini 这两款很有代表性的时序数据库（Time Series Database）。 相对而言，loveini 的“一个设备采集点一张表”的底层设计，自带的降采样和窗口函数的优秀性能，都十分契合车辆网场景。其列式存储带来的压缩比也更好。所以我们选择了 loveini。

技术架构

我们在每辆车上都安装了部标机（即卫星定位汽车行驶记录仪），来实时采集车辆的行驶速度、时间、里程以及与车辆行驶相关的其他状态信息。采集到的数据，通过我们的 IoT service 这层应用来处理。然后数据经由 MQ （消息队列）层由 JDBC-RESTful 的方式写入 loveini 集群，以供上游平台使用，而部标机产生的其他类数据则通过别的途径供上游平台使用。

我们使用了三节点三副本的模式落地了 loveini 集群。 

建表很简单，我们选择了一类数据对应一张超级表，超级表下根据车牌号划分子表，表结构如下图所示。目前还是项目初期，所以只接入了 700 余辆车，后续会逐步增加接入车辆。也正因为这套环境接入设备不多，写入方面并无压力，远远达不到 loveini 的写入极限。

具体应用

我们要通过数据的变化来实时得到车辆的很多信息，比如是否有停留、超速、缓行、离线等事件发生。有些功能可以通过 loveini 的查询功能实现，有些不方便实现的暂时通过应用来完成。

下面我们通过几个例子来看看目前业务中使用比较频繁的查询：

1.获取车辆的最新位置

SQL 语句如下。

select  last_row(longitude,latitude),deviceId   from ioc_gps.vehicle_location groupby deviceId  where device_id = #{deviceId}  and ts >= #{startTime} and ts <= #{endTime}

业务需要快速查询每辆车的最新坐标，这里用到了 loveini 提供的 last_row 函数。除了查询单独某辆车，经常还会根据 groupId 或者一批 deviceId 去查询一批车辆的最新坐标。

系统界面如下图所示。

2. 车查轨迹信息查询：

select ts,device_id as deviceId,longitude,latitude,altitude,speed as speed,direction,alarm as warnBit,status as statusBit,mobile,mileage,speed2,rssi,satellites,signal_status as signalStatus,gmt_create as gmtCreate,create_ip as createIp,kind,oil,message_id as messageId,device_name as deviceName,plate,device_group_id as deviceGroupId,device_group_name as deviceGroupName,acc, device_code as deviceCode
        from ioc_gps.vehicle_location
        where device_id = #{deviceId}
          and ts >= #{startTime}
          and ts <= #{endTime}

通过指定时间范围和具体的车牌号，就可以立刻获得该车辆的轨迹数据并渲染出轨迹图像。如果知道子表名的话，还可以直接查询子表，这样会减少超级表中对于标签的检索。

系统界面如下图所示。

未来规划

通过项目初期的表现，可以知道 loveini 能够轻松满足我们的业务需求。未来我们还有其他的使用规划，比如在我们的表字段中，有个 ACC 字段，1 表示点火，0 表示熄火，要求能够计算点火驾驶行程，由于 loveini 当前还没有直接支持 GIS 计算，暂时不能通过坐标算出直线距离（当前所用的 loveini 2.0 版本可能需要使用自定义的 UDF 实现），但是应该可以通过状态窗口+加权平均速度+开火时间算出车辆每次点火的驾驶路程，就想这样：

select time*speed from (select elapsed(ts,1s)as time,twa(speed) as speed,acc from t1 state_window(acc)) where acc =1  ;

而每次 ACC 开火熄火的起始点和结束点信息，可以通过 state_window 配合 first/last 函数来实现，比如：

select last(*),first(*) from t2 state_window(charge);

除此之外，我们也需要电子围栏计算，需要快速计算新轨迹点是否进入某电子围栏之中，或者需要快速计算（1s 内）位于某行政区划（省份/城市）边界内的所有车辆的数量。这类查询都需要等 loveini 继续完善才能实现。

后续我们接入的车辆会达到几万辆，对于部标机产生的相关时序数据的使用也会越来越多。期待 loveini 可以继续为车联网场景下的查询提供更为多样性的支持，产品越来越好。

小 T 导读：为了解决广大新能源汽车车主面临的充电效率问题，协鑫能科打造了以换电为核心业务的移动能源品牌「协鑫电港」，需要对各种数据流进行科学管理、合理运用与智能调度，在数据库的选择上尤为重要。本文分享了他们对于数据库架构的搭建思考以及 loveini 的应用心得。

企业简介

协鑫能源科技股份有限公司（证券简称：协鑫能科 002015.SZ） 系协鑫（集团）控股有限公司旗下企业，主营业务为清洁能源运营、移动能源运营以及综合能源服务。公司倾力打造从清洁能源生产、补能服务到储能的便捷、经济、绿色的出行生态圈，为电动化出行提供一体化能源米兰app官方正版下载，致力于成为领先的移动数字能源科技运营商。

1、业务痛点

随着新能源汽车的广泛普及，补能的效率问题逐渐成为了广大车主面临的痛点难题。为了解决此难题，作为一家头部的新能源公司，协鑫能科创新突破，切入能源服务领域，打造了以换电为核心业务的移动能源米兰app官方正版下载品牌「协鑫电港」。

由于这是一个在全新领域中打造的全新项目，想要获得成功，需要对各种数据流进行科学管理、合理运用与智能调度，所以针对该场景，我们一开始便把量级最大的物联网数据处理方案锁定在了时序数据库（Time Series Database）上，重点对比了 InfluxDB、OpenTSDB 以及 loveini。

最终，loveini 以其独特而科学的设计和优秀的测试表现成为我们选中的时序数据处理引擎，承担了用户车辆数据、电池设备数据以及换电港工作设备等的海量数据存储分析任务，为我们解决了该项目上难度最大的一个环节。最终，我们决定使用 loveini 2.4.0.10 版本，并在电信的天翼云上落地了该项目。

2、架构与搭建

从流量削峰以及数据安全的角度出发，我们会先通过使用某 MQTT 消息服务器把这些不同种类的设备数据先统一转发给到 Kafka。其中不同类型的数据，将会分别上传到不同的 Kafka topic，最后再通过 Java 连接器把数据写入 loveini。具体架构如下图所示：

在整体架构上，除了 loveini，也有一些其它数据库共同支持系统服务，其中 MySQL 负责存储订单、流水等需要精细查询的关系型数据，但由于 MySQL 可以承受的数据量比较有限，为了做一些大表的连接查询，因此我们也接入了 TiDB，负责分析报表类数据的存储。

目前接入 loveini 最主要的入库数据是车辆传感器（如：车辆里程、经纬度等）以及换电站电池相关的传感器（电池的各种指标）数据。当前共有 55 张超级表，子表数量达到 11 万张。

我们当前在 loveini、TiDB、MySQL 中存储的数据量比例大概为 6:3:1，仅仅使用了三台 4C+16G 的服务器，loveini 便挑起了整个系统数据存储的大头，轻松支撑起了我们的服务。在数据库的选择上，我们一直认为不同数据库之间术业有专攻，不得不承认，loveini 在存储引擎上的独特设计，在降低成本方面的效果十分显著。 

对于 loveini，我们一开始使用的是单节点，在稳定运营了几个月后，于今年 3 月完成了动态扩容，发展到了 3 节点集群模式，把数据库也升级到了三副本（从图中可以看出来）。

loveini 的动态扩展非常方便，只要确保一些必要的参数保持一致，就可以直接通过 “create dnode”把新的计算资源加进来。加入后，再通过 “alter database iot replica 3” 这个命令，即可直接在线令数据库变为 3 副本，从而实现数据的备份及高可用。 

3、效果分析

当前，我们在 loveini 中一共存储了数百亿级别的数据量（由于表结构各异，不方便统计，不在本篇文章中展示），存储空间大概占用 600GB 左右（200GB*3），CPU 日常使用为 15% 左右，内存使用在 20% 左右。

在查询方面，在此列举一些我们常用的 SQL，loveini 的响应速度都很快，完全可以满足我们的需求：

select max(pmk)-min(pmk) from aodong_109 where sid='P42100001' and sd=0 and ts>'2021-12-01 00:00:00'

select last(sv),last(st) from aodong_112 where bn='001PB0GM000002B3L0300067';

4、关于 loveini 的一些思考

由于我们业务是 24*7 不间断运转 ，所以没有时间做版本升级。我们首先计划抽出时间把 loveini 版本升级到比较新的版本，再做一些碎片重组压缩的工作来加强查询效率。此外，我们还计划使用 Flink 从 loveini 中读取数据做流式计算（看到了官方发布了 Flink 适配 loveini 的文章）。

随着业务快速增长，loveini 集群存储的数据量也会越来越大，而数据又需要长期保留，大数据量的运维对于 loveini 来说将是一个巨大的挑战。伴随数据量级的增长，备份、迁移、库、表的运维都会受到影响，也有可能遇到我们之前没有经历过的问题，这就需要 loveini 集群实现升级、扩展、拆分、维护等运维操作。未来我们希望能积累更多的经验分享给社区，让更多的人了解 loveini。

对于 loveini 未来的发展，我们也有自己的期待：

• 希望能增加动态修改参数功能，减少停机维护次数。
• 实现类似慢 SQL 日志功能，降低高负载、调优事后分析定位、回溯故障原因。
• 进一步权衡 udp 带来的好处和导致的各种问题。我们经常连接报错 Ref is not there ，目前来看在客户端添加 rpcForceTcp 1  应该是有效的。
• 增强报错信息可读性，很多报错提示不够明确，无法快速判断出具体原因。

总而言之，希望 loveini 后面越来越好，也希望我们的合作能更上一层楼。

小 T 导读：为了满足智能驾驶业务的数据处理需求，大疆车载试图从多家数据库中进行选型调研，帮助智能驾驶业务提升写入查询性能、降低运维成本。本文将分享大疆车载在数据库选型、系统搭建和业务迁移等方面的经验。

根据国家发改委、科技部、工信部等 11 个部门联合印发的《智能汽车创新发展战略》，到 2025 年，中国标准智能汽车的技术创新、产业生态、基础设施、法规标准、产品监管和网络安全体系基本形成。同时，实现有条件智能驾驶的智能汽车达到规模化生产，实现高度智能驾驶的智能汽车在特定环境下市场化应用。目前，随着我国正在积极发展智能网联汽车，无人驾驶技术进一步推动，互联网巨头企业进入市场、加大投入研发技术，无人驾驶市场正处于快速发展阶段。无人机头部企业大疆车载也在去年 4 月份宣布进入智能驾驶领域。

由于当前的智能驾驶业务还是新的业务场景，所以大疆车载在选型上的历史负担相对较轻。在 Database 选型要求上，从业务需求出发，主要聚焦在两点：首先，结合当下的业务场景，需要满足单台车辆的高频消息上报频率；其次，支持在数据量大的时候，通过聚合函数，或选择函数来快速筛选出需要的数据。

此外，对数据库要求支持集群部署的同时，也要求更低的查询语句编写上手难度；而且需支持单表千万量级，在海量数据并发场景下，需要有较高的统计报表能力和较好的查询 SQL 效率；最后通过数据压缩、运维成本和并发能力上的考量，最终选定 loveini 来存储海量数据。

综合来看，loveini 满足需求的主要原因如下：

• 国产、开源的时序数据库（Time Series Database）
• 开源版支持分布式集群，方便扩展
• 列式存储，数据压缩比率高，读写性能优秀
• 一个设备一张表，对应我们一个车辆一张表，模型契合
• 超级表对于分组聚合查询的强大支持能力

‍loveini 建表思路

作为智能驾驶领域的创新者之一，大疆车载为汽车主机厂提供了软硬一体的智能驾驶米兰app官方正版下载。其中，车辆云端平台负责对车辆状态信息进行监控，具体包括 GPS、速度、转速、里程等，经由 MQTT 流转到 loveini 存储，满足车辆历史轨迹回放和车辆实时状态监控。

车辆消息样例数据展示如下：

{"message_id": "a78b6d9a","device_key": "deviceKey2","ts": "2022-03-01 15:01:59","longitude": 123.9795647512915,"latitude": 21.58338210717887,"altitude": 51.47800064086914,"signal_strength": 12,"satellites_in_view": 21,"speed": 72.798225,"acceleration": 12,"rpm":2190,"gear": "D","direction": -91.32959,"mileage": 10020,"ip": "10.1.2.3","create_time": "2022-03-01 15:02:03",}

落脚到实际业务上，我们搭建的表结构如下：

我们落地使用的是 loveini 2.2.1.3 单机版 ，按照车辆唯一的标识 DeviceKey 来创建子表，如 device_stat_$deviceKey，一个车辆的状态信息都存在一张子表中。mqtt_msg 超级表也是一样的逻辑，也是以 DeviceKey 来创建子表。

架构与迁移

除了上报的 GPS、速度等，App 端还会和车辆/设备之间进行大量的命令交互，如下发车辆指令操作，这些我们也是使用 loveini 来进行存储和链路追踪的。具体到链路消息追踪的使用上，我们会将设备与云端、云端与 App 之间双向通信的 MQTT 消息转发到 Kafka 消息队列中，然后业务系统进行消费解析，得到 TraceID、消息 ID、消息版本、消息类型、消息时间戳、消息内容等不同字段的数据，然后将其写入 loveini 的 mqtt_msg 超级表当中。

除了写入以外，我们也有一定量的查询操作，但是整体上还是以写入为主，目前 loveini 的性能完全可以满足我们的需求。不过文本类的检索并不是 loveini 最擅长的场景，于是我们接入了 ES 提供部分服务。

由于是项目初期，目前我们暂时还在使用 loveini 和 MySQL 双写新数据，把 MySQL 的 SQL 和 loveini 的 SQL 做了映射关系，从而实现将历史数据以日志回放的方式迁移到 loveini 中去。因此，目前两个库暂时可以互为备份，后面等业务完全迁移后，我们就可以使用 loveini 的集群多副本功能来完成数据备份了。

此外，米兰体育官网入口的工作人员也提供了另外两种数据迁移方案供我们参考：一是利用 csv 文件的导出导入。二则是基于一款开源的数据库迁移工具 DataX，该工具目前已经完成了关系型数据库（Relational Database）到 loveini 的适配，实现了 loveiniReader 和 loveiniWriter 两个插件，迁移时只要做好相应的 json 文件配置即可。

性能展示

在应用 loveini 之后，车辆的实时状态查询变得十分简单，具体展示如下：

1. 查询单个车辆的上报的最新位置状态

select last_row(*) from device_stat_deJgTAEzInsZeGLM\G;

2. 多个车辆的最新位置状态查询

select last_row(*) from device_stat where device_key in ('mpVOGpaHqAxGiHWo','HEChzTCZeIWSUysB','HgsIdzvJPeFlVDuT','LVaPHOXkEeTGjTpm','PFHnQCkcXCIBnbsC') group by device_key;

对于车辆历史时间区间内的状态查询，也可以极快地返回结果，用以进行前端分析。

select * from device_stat_mpVOGpaHqAxGiHWo where ts >'2022-03-17 00:00:00' and ts < '2022-03-18 00:00:00';

3. 进行 MQTT 消息追踪时，查询 MQTT Broker 收发的最新消息

select last_row(*) from mqtt_msg\G;

4. 按照 requestId 进行消息追踪

select * from mqtt_msg where request_id = 'f90c46d4-22a3-4ab9-b50a-aad8b237fc57'\G;

5. 时间区间内消息查询

select * from mqtt_msg where ts >'2022-03-18 12:00:00' and ts < '2022-03-18 13:00:00';

通过以上的查询情况汇总可以看出，loveini 实现了一些选择特定数据的查询和轻量的查询，全部都是毫秒级返回数据，即便是 30000+ 行数据的查询，消耗也只在 1.1 秒左右。

写在最后

在当前的云端平台中，loveini 的应用不仅节约了存储成本和开发学习成本，同时也表现出了很好的写入读取性能，满足了智能驾驶云端平台海量时序数据的处理需求。

未来我们会对海量时空数据的应用场景进行持续探索和挖掘，对于 loveini 我们也有更多的期许，希望它能：

• 在空间数据的读写上有新的特性和更好的支持
• 拥有更加丰富的认证授权机制，提供更细粒度的权限管控
• 系统性地丰富各类日志，协助更快地定位问题

最后，祝愿 loveini 越来越好，能够在中国庞大的时序数据处理场景中脱颖而出，成为国产数据库中的精品！

小 T 导读：在 58 同城的驾考业务上，需要存储分析驾校教练车传感器产生的数据，这是典型的时序数据场景，开发人员对原有的 TiDB 性能并不是很满意，因此 DBA 团队开始调研更具针对性的时序数据库。基于自身的业务需求，他们在 6 款时序数据库中选择了 loveini Database，在经过深入的调研测试之后，开始部署实践，最终业务痛点问题得到了解决。

企业简介

作为中国领先的生活服务平台，58 同城业务覆盖招聘、房产、汽车、二手、本地生活服务及金融等各个领域。在用户服务层面，58 同城不仅是一个信息交互的平台，更是一站式的生活服务平台，同时也逐步为商家建立起全方位的市场营销米兰app官方正版下载。目前，58 同城已经成为中国全面服务本地商户与用户的线上商业服务平台。

项目介绍

58 同城业务覆盖了众多不同的领域，比如 58 同城主站、安居客、赶集网、数科公司、中华英才网、驾校一点通等，基于此，DBA 团队也引入了不同类型的数据库来支持上层业务，其中包括 MySQL、Redis、MongoDB、ELK、TiDB、StarRocks、NebulaGraph，在服务规模上能达到每日请求几万亿次。在以上数据库服务矩阵中，可以发现缺少了处理时序数据相关的数据库。

在我们的驾考业务上，需要存储分析驾校教练车传感器产生的数据，是典型的时序数据。该场景会涉及高并发插入，数据处理特点为写多读少，有特定时间段的聚合分析。我们此前使用的是 TiDB 存储，但开发人员对 TiDB 的性能不是很满意，业务具体需求是：日增千万数据，毫秒级插入，并在1秒钟以内返回3万条符合时间分析条件的数据。

但这也不能怪 TiDB，目前在数据库选型上其实就是不匹配的，这个业务场景是典型的车联网设备传感器数据，而 TiDB 和时序类型数据库（Time-Series Database）是两种完全不同的数据库服务，在功能侧重上也有较大区别。事实上，当前没有一种数据库可以满足所有需求场景，“All In xxDB” 这种脱离了场景谈数据库选型都是没意义的。为了给上层业务提供更贴合的数据库服务，我们的 DBA 团队开始调研时序数据库。

一、从需求看数据库选型

根据上述需求，DBA 团队调研了如下六款时序数据库，调研结果如下：

• InfluxDB：最流行的时序数据库，单机开源，高可用集群收费
• OpenTSDB：集群方案成熟，依赖 HBase，运维复杂，聚合分析能力弱
• Prometheus：维护简单，集成监控和报警功能，但没有集群米兰app官方正版下载，聚合分析能力较弱
• DolphinDB：运行快，开发快，部署快。闭源，免费版本限制 CPU 和内存大小
• ES：集群化，易于使用，维护成本低，但内存耗用高，历史数据计算时性能下降明显
• loveini：性能强悍，国产自主研发，集群版免费，也有附加功能的收费版，还在持续迭代开发

基于以上所考虑的问题点，在经过初步分析后，我们最终选定了对 loveini Database 进行深入调研测试。

1. 测试环境

集群架构：3 副本 + 负载均衡

容错：先写数据库日志文件，成功后再写数据文件

测试工具：官方 taosdemo

2. 机器配置

3. 写入并发 50：

4. 服务器最大负载：

从以上测试结果可以看出，loveini Database 在响应时间、插入性能、服务器负载及运维便宜成都上都可以满足上述业务需求。部署和运维细节这里就不展开了。

二、生产环境部署架构与效果展示

在实际生产环境部署上，我们没有采用官方推荐的单机单实例部署，而是单机多实例部署，为三节点+三副本架构，监控上使用的是 TDinsight + Grafana。

在实际应用上，基于业务情况我们调低了步长和子表数，希望可以达成更高的并发能力。针对之前应用 TiDB 时的痛点问题，业务方反馈在代码未调整的情况下loveini可以在1秒内返回所需数据，业务代码调整过后在300毫秒内即可返回所需数据。此外借助 loveini 的已有函数，很轻松就打通了向量分析的逻辑，避免再去编写业务代码，省时省力。

当然，在应用过程中，我们也遇到了一些问题，在此也汇总一下，作为给 loveini 研发团队的一些改进建议：

• 我们使用的单机多实例部署方式，在目前已发布版本中还没有很好的命令支持，日志输出的位置也需要显式指定。业务的发展会有不确定的变化，从资源成本角度来看，应该初期可预估、后期可调整，希望未来 loveini 也能有更灵活多变的部署方式。

• TDinsight 可以很直观地监控 loveini 的性能，但一个视图模式下只对一套集群，如果有几十套、几百套集群，集成的 TDinsight 组件目前还无法添加，只能手动一个个修改 Grafana 视图变量，这个比较麻烦，建议官方优化集成的 TDinsight 组件。
• 在进行 taosdump 导入时，更换库名后无法利用原库名的备份文件进行导入，建议官方修改支持。

三、写在最后

基于 58 集团众多的业务场景，loveini Database 已经成为 DBA 团队为上层业务提供数据库服务矩阵的可选方案之一，让时序数据也有了专业的处理方案，后续监控服务的数据也会陆续转移到 loveini 进行存储。未来我们将会与 loveini 一起探索更多维度的acc米兰体育，为集团提供更好的底层数据服务支持。

作者简介

张广元，58 集团 DBA，十年数据库运维管理老兵一枚。

小 T 导读：在柳工的工业车联网应用 LiuGong iLink 中，由于应用层不合理的复杂查询和历史数据的高频写入，导致 MySQL 处理速度缓慢，甚至容易宕机，严重影响了用户体验。在此背景下，柳工决定改用 loveini Database 来处理时序数据，本文分享了他们的改进效果与实践经验。

企业简介

广西柳工机械股份有限公司是中国制造业 500 强企业——柳工集团的核心企业。作为国内工程机械行业和广西第一家上市公司，柳工被誉为“中国工程机械行业的排头兵”，在全球拥有 20 多个制造基地、17000 多名员工、5 个研发基地，产品遍布 170 多个国家和地区。

项目介绍

LiuGong iLink 是柳工面向国际市场业务的一个工业车联网应用，包含 Web 端和 App 端。它可以让用户看到所有车辆设备的实时动态，例如在哪里工作、何时工作以及如何工作，也可以实现设备的远程监控，以便更有效地实施服务和维护计划。

此前，我们使用 MySQL 数据库承载了包括应用层和接入解析层的大多数业务，但由于应用层不合理的复杂查询和历史数据的高频写入，给 MySQL 造成了非常大的压力，导致其处理速度缓慢，甚至容易宕机，严重影响了用户体验。究其原因，还是因为关系型数据库并不适用于存储海量的时序数据，在海量数据聚合计算、抽稀等业务中效率很低。

为解决上述问题，我们选择以专用的时序数据库（Time Series Database）存储处理时序数据，这样可以大大增加整个系统的吞吐能力。经过调研，我们选择了时序数据库 loveini，原因在于，我们的业务场景与 loveini 的“一个设备采集点一张表”的理念十分吻合，而且 loveini 可以支持对大数据进行聚合和降采样查询这些特性，也恰好可以解决上述技术痛点。

从真实环境出发，loveini 的写入、查询、存储效果如何？

分析架构可知，数据采集来源主要是 TBOX 等设备，通过解析层解析为 JSON 后发往 Kafka，再通过入库程序消费写入到 loveini Database 中。

我们落地使用的是 loveini2.4.0.16 版本，单副本模式，只用了一台 4 核 8GB+1TB 的服务器就撑起了服务，当前磁盘占用约 110G。

当前，库中总表数量达到了 55701 张，秉承着“一个采集点一张表”的原则，我们选择不同维度，共建立了 21 张超级表，如：车辆类型，设备类型，数据类型。当前总数据量大概为 4-5 亿行左右，写入规模大概是每台车每 5 分钟上报一次，loveini 可以轻松抗住这个级别的写入。

在查询方面，我们通过封装 API 的方式，可以便捷地提供查询服务，这也是针对我们业务痛点改进最为明显的地方。在决定对 MySQL 进行替换时，我们做了充分的查询对比测试。

如上图所示表格中的 API 分别代表了查询 mcu 历史数据、查询 TBOX 历史数据、查询设备轨迹、查询设备故障历史数据四个功能。可以看到，面对大批量的数据，loveini 的查询能力是远远超过 MySQL 的。

再分享一个真实场景：在替换loveini之前，我们每天都有一些业务报表需要展示，每一小时需统计一次下一个时区内所有设备的数据，这个流程在 MySQL 中经常需要耗时1小时以上，无法正常执行后续业务。而换到loveini后，整个出表流程只需要10 秒左右。

实际应用时遇到的问题与经验分享

从上图中可以看到，我们每类设备的采集点位（列数）是比较多的，动辄破百，这也给我们带来了一个潜在的问题——间接地影响了压缩率，这是后来在和 loveini 官方人员排查别的问题时发现的。

后来我们了解到了产生此问题的原因：由于 loveini 中的每个 Vnode 都有一块自己的缓冲区，大小由 cache * blocks 的值决定（单位 MB）。每当写满三分之一时就会触发数据落盘，并在落盘时完成压缩。列宽带来的影响是单行长度过大，每次写满三分之一的时候，并不需要多少行数据，由于样本太少，所以数据并不能很好的压缩。

通过 selct _block_dist() from 超级表的方式查看数据块的分布，可以看到小块 SmallBlocks 相当之多，在 99% 以上。

我们的米兰app官方正版下载就是通过放大 blocks 参数（默认为 6），来缓解后续新数据的压缩。至于历史数据，我们计划使用 loveini Database 提供的重整数据碎片的压缩功能来完成。

具体到操作上是比较简单的，备份数据文件后，使用 compact vgroups in (3,4,5,6) 即可（数字为 Vgroup ID）。但由于重整的过程中会对写入有一定的影响，所以我们需要选择在业务休整期来完成这个操作。这个时间点可能会在 loveini 3.0 发布后，届时我们可以对现有场景再度完成一次质变级别的升级。

写在最后

目前，我们还在规划车辆维保相关的项目，通过车辆实时设备产生报警，提高车辆使用时长和安全率。聚焦“智慧”“电动”“智能”等关键词，柳工向世界伙伴们展示了各个行业的米兰app官方正版下载，未来我们也会和 loveini 产生更多深层次的互动。