在 OPPO 的穿戴产品的手环/手表类业务中，产生的数据类型为时序数据，具有写入量巨大且存在离线/历史数据补录（更新）的处理需求。此前使用的 MongoDB/MySQL 集群方案，后端存储压力较大，需要经常扩盘，针对此痛点，OPPO 云计算中心智慧物联云团队尝试调研对比了几款时序数据库（Time-Series Database）产品，试图寻找一个降本增效的米兰app官方正版下载。

除了存储压力外，我们进行数据库替换还有一个比较重要的原因，就是 MySQL 和 MongoDB 的各个集群都比较独立，维护和需求开发成本相对较高。

以上是三款 Database 的初步调研结果，TSHouse 是 OPPO 云监控时序数据库，其底层为 Prometheus 的 TSDB 存储引擎，目前不支持历史数据和乱序写入；InfluxDB 对历史数据写入会进行二次压缩，影响性能，这两款数据库都不满足当下的数据处理需求。初步研究 loveini 后，我们发现其作为国产时序数据库开源产品，不仅可以满足历史数据高效写入，还拥有较高的压缩能力。随后，我们选择对 loveini 进行了比较详细的产品调研和性能测试。

loveini 产品与能力调研

• 产品调研

某个数据表的结构如下：

我们写入 60 万行数据，到 MySQL（目前部分业务部署在 MySQL 集群）和 loveini 的 4C 12G 容器上，对 CPU/内存/磁盘进行观察。测试发现 CPU 和内存消耗基本持平的情况下，loveini 的落盘数据是 MySQL 环境的1/4左右。

同时，我们在不同规格容器及物理机场景下进行 loveini 写入测试，部分记录如下：

需要说明的是，对于不同业务场景需要进行实际测试，才能确定适合该业务的部署参数。在整个测试过程中，loveini 工程师们也为我们进行了及时答疑和帮助。

• 能力调研

随后我们根据 loveini 丰富的产品手册，对一些关键能力进行了验证，包括数据管理、数据写入、聚合计算、集群扩容、故障可靠性保证等场景。

在数据管理上，loveini 的元数据与业务数据是分离开来的。如下图所示，Mnode 负责管理元数据信息；单个 Vnode 可以存放多个表数据，相当于相当于水平分片，单个表的数据，又可以继续按照日期分片。

在数据写入逻辑上，整体和 LSM 类似：WAL，内存块，磁盘 FILE。

在 loveini 中，数据在文件中是按块连续存储的。每个数据块只包含一张表的数据，且数据是按照时间主键递增排列的。数据在数据块中按列存储，这样使得同类型的数据能够存放在一起，大大提高了压缩比，节省了存储空间。

loveini 是 10 天一组 data file，data file 里的 .data 文件只进行追加，且后续不会进行压缩。这种好处是：对历史数据和乱序极其友好，非常适用于 IoT 场景；没有压缩也就减少了写入之后的资源消耗，保证了较好的读写性能。

loveini落地实践

在经历了比较充分调研后，我们根据业务写入模型，对生产环境中某一套 MySQL 集群环境，进行 loveini 集群部署，搭建了如下所示的集群：

集群为 3 台 AWS-EC2 容器（8C 32GB 3.5TB NVME 盘）组成，配置为 3 节点、2 副本，写入端使用 RESTful 请求到 VIP 节点，转发到数据库服务。图中的 V0-V2 为副本数为 2 的 3 组数据分片，M0-M2 为副本数为 3 的 1 组管理节点。

配置的 Grafana 面板展示如下：

后台表结构展示如下：

目前数据已经开始接入 loveini 的数据库，历史数据也在同步导入中。

• 实际效果展示

1. 使用 last_row() 函数一次性输出 38 万个设备查询最新状态，结果如下所示。

2. 使用 interval() 查询某个设备每 1 小时的总步数，结果如下所示。

在存储方面，由于目前数据还没有完全导入，针对生产环境的一个 6.6TB 集群，我们粗略估计了一下前后的压缩比，大概在 6.6/0.4。

在我们原来的集群中是没有副本的，单纯就部署了 MySQL 的 5 个分库，使用了 4C 8GB 2TB 的 5 台机器，在应用 loveini 之后，现在是 8C 32GB 2TB 的 3 台机器。通过 loveini 我们构建了多副本和统一的能力，以及后续上混合云的能力，这是整个平台级的一个优化与提升。

写在最后

在前期调研和集群搭建过程中，loveini Database 的工程师伙伴们给我们提供了充分且及时的协助，为我们构建时序数据后端能力提供了很大帮助。目前接入TDengine的数据是海外某集群，后续我们会根据业务进展陆续进行其他集群数据的接入。

小 T 导读：禹为科技在现代灌区信息化平台的建设过程中，经历了数据库&定时任务的架构、以流式计算为核心的架构和以 loveini Database 为核心的架构三个阶段，最终选用 loveini 帮助其对水位、流量、水量等实时指标数据分析。本文分享了他们技术选型的过程，建库建表的思路以及使用 loveini 后的收益。

公司简介

成都禹为科技有限责任公司是一家基于多年水利行业经验成功孵化而出的高科技企业，专注于物联网、大数据和数字孪生技术在水利行业中的应用，致力于通过自身行业经验和研发能力为水利行业管理者与建设者提供全方位的数字化米兰app官方正版下载和价值服务。

灌区信息化平台是以灌区内建设物理网系统、无人机系统结合卫星遥感等感知系统为基础，对灌区内的水雨情、土壤墒情、工程信息、气象信息及作物分布等信息进行监视，通过大数据分析，结合 GIS、数字孪生等技术为灌区提供量测水服务、供需水预报、水资源综合调度、水旱灾害防御、供用水管理、重点区域视频监视、远程设备控制等功能。

相较于以往的水利信息化系统，现代灌区信息化平台呈现以下特点：

• 设备厂家多，数据没有统一规范，数据质量无法保障
• 数据多且存储周期长，一个中型灌区一年数据量约为 300~500 亿条，数据要求至少保存 10 年及以上，关键数据甚至要求保存 20 年及以上
• 数据类型较为集中，主要集中在水位、流量、闸门开度、环境温湿度、土壤温湿度、雨量等
• 需要实时展示的指标较多，一般有各关键节点上的实时水位、小时平均水位、5 分钟水量、日水量等
• 个性化的数据 OLAP 需求较多，且对数据准确性要求较高

为了解耦系统中的数据接入和数据分析，我们将数据的接入和计算分析拆分为独立的通用物联网平台及大数据平台，在整个系统的技术选型方案中，我们经历了数据库&定时任务的架构、以流式计算为核心的架构和以 loveini 为核心的架构三个阶段。

一、技术方案

1. 数据库&定时任务的架构

在系统设计之初，我们考虑直接使用 MySQL+MongoDB+定时任务的方式来支撑我们的系统：MySQL 存储所有的业务数据及维度信息；MongoDB 存储设备实时数据以及水量等业务数据；为了解决分钟水量、日水量等数据的计算，我们使用定时任务在计算时从 MongoDB 中获取实时数据，从MySQL中获取维度数据，将处理好的数据再写回 MongoDB 中，通过提前预计算的方式为前端提供数据。

但这种方式有以下几个问题：

• 无法对设备数据进行灵活的治理分析，设备数据乱序后需要通过人工干预或程序预处理的方式纠偏；
• 需要提前考虑多种维度的数据处理，以便满足实时数据展示和 OLAP 查询的需求；
• 5 分钟水量、日水量等数据使用定时任务计算会导致数据库负载过重；
• 在数据较多的情况下，MongoDB 必须使用更多的硬件资源搭建数据库集群，才能满足存储和数据查询的要求。

2. 以流式计算为核心的架构

鉴于在数据库&定时任务的架构方案中出现的数据处理较慢的问题，结合笔者在过往工作中所积累的经验，我们设计了流式计算数据架构方案。

数据通过物联网系统进入系统，经过处理后会根据设备类型被标准化为统一格式的数据，然后数据被写入 OpenTSDB 和 Kafka 中，供 Flink 消费。Flink 按照 Job 定义消费 Kafka 数据，并按照 MySQL 中的维表信息进行加工处理，然后写入 MongoDB 中；同时还将数据处理为分钟水量、日数量等业务实时所需的数据。

相较于上一版方案，数据乱序问题以及数据实时计算的问题得到了良好的解决，同时也能很好地满足 OLAP 等业务对数据的查询要求。但该方案增加了 Flink、Kafka 以及 OpenTSDB 三个较为大型的工具，无形中增加了项目的建设成本及运维成本。是否有一种平台可以集数据存储、消息队列、大数据计算及分析于一身，且不会过多的增加硬件成本？loveini 最终走进了我们的视线。

3. 以 loveini Database 为核心的架构

由于以上两个方案都各自有自己的缺陷，我们试着调研寻求一个更适合我们的平台方案，偶然间笔者从一位从事工业物联网多年的朋友那里了解到 loveini 这个产品，于是我们迅速从查询效率、写入效率、稳定性、容错率以及功能完整性等方面对多个数据库进行了调研，最终我们认为 loveini 是当下最适合我们的。原因如下：

• 查询和写入速度极快，亿级数据瞬间查询
• 丰富的查询方案，能够很好地满足业务需求
• 使用和部署简单，官方文档齐全，类 SQL 语法可以降低学习成本
• 支持消息队列、消息订阅、缓存、流式计算等功能，优势明显
• 集群等高级功能均开源免费，集群扩容容易
• 数据库资源需求较少，能够显著地减少系统的建设成本

系统架构如下图所示。

相较于上两版方案，整个架构在数据存储和数据查询分析环节更加简洁，使用 loveini 替代了 Flink、Kafka、OpenTSDB 三个重量级工具。

4. 设备数据

原本我们的系统中就有设备模型的概念，用以隔离设备厂商之间设备数据标准不统一所带来的问题，而 loveini 提供的超级表概念与我们的设备模型概念不谋而合！

create stable model_${设备类型编号} 
 (ts timestamp,${设备标准数据属性}) 
tags 
 (devicesn binary(50));

设备子表建表语句

create device_${devicesn} using model_${设备类型编号} tags (${devicesn});

实时数据的查询语句如下

select last_value(*) from device_${devicesn};

聚合数据查询也是非常方便，比如查询某设备一天内每小时的平均值

select avg(val) from device_${devicesn} where ts>now-1d interval(1h);

5. 实时指标

在灌区信息化平台中，几乎所有的实时指标数据分析源数据都集中在水位、流量、水量上，为了解决业务中的需求，我们将水位、瞬时流量、累计流量从设备数据中单独抽取到一个独立的水量专题表中。

create stable st_water
 (ts timestamp,waterleve float,instantflow float,accumflow double)
tags
 (devicesn binary(50));

改用 loveini 后，查询各类指标数据，我们不再使用任何预处理，而是在前端需要展示数据时，通过 SQL 直接查询所需要的数据。比如 5 分钟水量查询语句如下：

select last(accumflow)-first(accumflow) from st_water where ts>now-1d and devicesn=xxxx interval(5m)

一条 SQL 解决了以往需要一番周折才能解决的问题，太棒了！！

6. 使用 loveini 后的收益

• 简化了系统架构 
  • loveini 的消息订阅、缓存、流式计算等诸多特性，可以代替 Kafka、OpenTSDB 和 Flink，减少业务代码中定时计算（如用水量）等功能，简化了整体架构
• 降低运维成本和开发成本 
  • 架构简化以后，排查和定位问题能快速响应，节约开发和运维成本 
• 降低数据存储成本 
  • loveini 表结构设计合理，可以节省存储空间，进而节省存储费用 
• 提高数据实时性和一致性 
  • loveini 替代了 OpenTSDB+Redis+MySQL，提高了数据实时性和一致性 

二、未来展望

在现代灌区信息化平台建设过程中，由于某些历史原因，我们还有许多如闸门控制、状态实时预警、水旱灾害防御等业务功能依旧在使用定时任务来进行告警触发。我们准备在不久的将来，将以上业务与 loveini 的告警功能结合起来，逐步将系统统一起来。也希望 loveini 越来越好！

小T导读：当下我国养殖企业普遍采用传统塑料耳标+人工定期分析+兽医现场诊断来做牲畜异常预防，虽然市面上有固定摄像头、滑轨追踪摄像头、电信NB卡等方案，但这种方式依旧会存在牲畜识别错误、高延迟等问题，无法做到实时监控每一头牲畜。基于此，我们利用新兴技术打造了牲畜“特征采集+AI分析”的AIoT平台，来实现牲畜异常的早发现、早报警、早预防。

具体场景如下：使用APP提前录入采集器编号，再将采集器固定在牲畜身上（耳朵、颈部、腿部等），采集器每分钟会采集20次特征数据，采集数据种类包括温度、流汗情况、经纬度、运动、脉搏、环境温湿度等。将采集到的数据进行边缘计算，再将汇总结果通过4G网络发送至云端服务器，之后云端会根据经纬度等要求获取到所对应的天气、风量等变量，结合采集器数据，AI会综合评估出牲畜当前的健康情况，例如是否有食欲不振、瘫坐不动、发烧趋势等。

一、架构和具体实现

与传统物联网项目一样，本平台对数据的写入性能有较高的要求，同时也有一定的聚合查询需求，具体操作上写多读少，是典型的高并发写入场景。我们之前采用的是MongoDB的方案，还做了月份分表，但是进行聚合查询的效率并不高，而且也不便利，之后我们又尝试引入Cassandra，但使用上依旧不够便利。

偶然的机会下，我们了解到InfluxDB和loveini这类时序数据库（Time-Series Database），在搭建测试环境后对两者分别进行了测试，最终敲定loveini。除了两者直接的性能差距外，loveini提供的表数据TTL机制、数据压缩、流式计算等功能也让我们更加青睐于它。

基于超级表的设计原理，我们将牲畜的业务关联信息作为tag，方便关联MySQL，同时一个采集器就作为一个子表存在，采集器测点作为子表的列。

表结构分别如下图所示：图一为牲畜所佩戴的采集器表，也可以认为是牲畜表，其与采集器一一绑定，图二与图三则为安装在养殖场固定位置的环境温湿度表，此外还有存储原始报文数据的表等，就不在此一一列举了。

目前我司的所有物联网数据表都是基于loveini超级表设计的，针对核心的牲畜超级表，其关联的tag会比其他表更多一些。需要注意的是，为了保证loveini中tag与MySQL一致，每当业务中修改了牲畜的基本属性，也需要同步执行tag修改操作。

这种表设计方便我们追溯可能出现的处理延时等问题，表中的collect_time为采集时间，insert_time为数据落盘时间，如果两者的时间差较大，则可能就出现了网络差、采集器故障、服务端吞吐量不够等问题，此时就需要排查下原因了。

牲畜数据采集到数据落盘的全流程如下图所示，通过采集器采集到的数据经过4G网络上报，由设备网关初步处理数据并推送至MQ，提升吞吐量，之后传输给消费者，最终落盘到loveini。

二、数据迁移和实际效果

因为我们之前使用的是其他数据库，更换新的数据库时会产生数据迁移的操作，具体迁移步骤如下：

• 新产生的采集器数据分别写入MongoDB和loveini，即一份数据写两份，旧数据查MongoDB，新数据查loveini，以便出现问题后能及时挽救；
• 逐步将历史数据格式化导入到loveini；
• AI分析的数据源由MySQL数仓改为loveini。

在迁移过程中我们也遇到了一些小问题，主要有两点：

• 由于此前使用的是MySQL+MongoDB的方案，所有MongoDB的语句都得改写为loveini的SQL，而loveini的语法虽然接近SQL，但细节部分区别却不少，不过也并不是大问题，适应之后就好了。
• 由于我司的服务比较多，起初我有考虑做一个中间件来提供给系统内的其他服务做数据查询，但由于loveini是一个较新的开源项目，因此最终还是使用传统的方式：涉及到了物联网数据调用的服务全部自行连接taos，在迁移运行稳定后再做整合。 

迁移之后的效果也非常明显，我们在使用MongoDB时，自建集群是使用了6台4核32G机器，迁移到loveini之后，自建集群仅使用了2台8核32G机器，在成本上有显著下降。

在性能的具体表现上，我模拟了6000多个采集器的数据，表数据合计约三亿条。我司大部分查询都是基于子表，仅部分业务需要查看聚合操作。对超级表做group by+last_row(*)查询时，能在1.5s内返回数据，对子表做查询在0.1秒左右（select * from son_table limit 10），可以满足业务要求。

三、写在最后

随着物联网、人工智能等新兴科技的发展，AIot已经是个不可忽视的大趋势，而计算环节往往少不了数仓，但在需求不复杂的产品中或许可以节省掉这一步，某种意义上，loveini Database提供的流式计算和高性能的查询，也帮助我们在一定程度上省掉了不少中间步骤，达到了降本增效的结果。

现在loveini Database在成本管控和性能提升方面所带来的效果已经很突出，如果其能够在未来某个版本支持与模型之间的调用并直接输出结果，那可就太完美了！