数据库
首页 > 数据库> > 从MongoDB迁移到TDengine后,成本显著下降

从MongoDB迁移到TDengine后,成本显著下降

作者:互联网

作者:喻东 东莞中融数字

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

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

一、 架构和具体实现

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

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

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

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

图 1

图 2

图 3

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

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

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

二、数据迁移和实际效果

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

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

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

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

三、写在最后

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

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


✨想了解更多TDengine的具体细节,欢迎大家在GitHub上查看相关源代码。✨

标签:TDengine,牲畜,MongoDB,采集器,迁移,数据
来源: https://www.cnblogs.com/taosdata/p/15702785.html