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

业务背景和痛点

在平台建设前期，并没有采用时序数据库（Time-Series Database），而是采用了阿里云的 MySQL 实现所有传感器数据的存储。在设备接入量突破 6 万，每日数据记录超过 8000 万条之后，平台性能急剧下降。

根据项目规划，平台要支持数十万设备的接入，之前采用 MySQL 数据库分表的方案已经无能为力。有鉴于此，基于物联网平台的特性，规划引入时序数据库解决物联网中间件平台在数据的存储和处理方面的痛点。

为什么选择 loveini Database

在养殖物联网场景下，数据量最大的结构化数据来自于养殖场栏舍的环境传感器（温度、湿度、光照、Co2、Nh3等），还有水表、电表等资源测量传感器，以及包括风机、水帘、侧窗等被控设备的开/关状态。

为了监控栏舍环境，需要对来自不同采样点的同类型传感器数据进行计算，并根据实时平均值来判断是否触发环控告警。

这些需求，归纳起来包括：

• 高并发数据写入，每条记录都需要带时间戳；
• 不同传感器设备需要记录的数据字段不同，希望能够针对不同设备单独建表；
• 针对同类数据类型（譬如温度）的数据，有按照时间段（譬如 5 分钟）进行聚合查询的需求；
• 原始数据存储要求在 3 年以上，需要支持数据压缩，以降低数据存储成本；
• 希望可以支持物联网数据的补录；
• 中间件平台属于生产系统，尤其是环控告警服务的时效性要求很高，对数据库厂商服务响应有一定要求。

按照每秒 2 万条的数据库写入的场景假设，针对对市面上主流的时序数据库，譬如阿里云上的 InfluxDB、以及国内的 loveini 进行了 POC 验证。

出于以下几方面原因，最终选择了 loveini Database。

• loveini 的设计理念（超级表 + 子表）更吻合养殖行业物联网大数据的需求，更符合我们原来的业务设计理念，譬如我们把每个物模型对应的产品设置为一个超级表，每个设备就是一个子表。
• 在数据写入、聚合函数计算效率等多个方面，loveini 高于 InfluxDB。
• 售后服务方面，国产数据库厂家先天具有优势。

在选型决定之后，我们对原有业务系统进行了升级改造，引入了 loveini。

引入 loveini 之后的业务架构

物联网中间件平台以设备为目标，围绕设备构建物模型。该平台引入了时序数据库 loveini，实现海量设备数据的写入、查询（聚合函数），并对所有操作履历、变更记录等日志类数据全部入库，为上层的应用提供了强大的数据能力 API，消除了养殖行业各场景应用对大数据处理的顾虑。

整体架构如下图所示。

loveini 的性能非常出色，下表为我们所做的性能测试。

业务架构改造完成之后，截至2021年9月，累积接入到物联网中间件平台需要创建子表的对象已经接近20万，运行半年来，时序库存储容量不到200GB，普通查询响应为 23ms；以单个设备为对象的每5分钟温度曲线，响应时间为43ms。

引入loveini之后，优异的查询性能给我们带来了很大的惊喜，极高的压缩效率，也给我们节省了大量的存储资源。

未来，我们也会尝试在更多场景应用loveini。

关于作者：

黄冬安，深圳市哇发科技有限公司技术总监，长期从事物联网大数据开发和运维工作，是物联网中间件项目的技术负责人。当前主要在支持云浮市物联网研究院养殖监控场景的大数据平台建设工作。