MongoDB数据建模小案例:物联网时序数据库建模

本文涉及的产品
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
云数据库 MongoDB,通用型 2核4GB
简介:

注:本案例来自MongoDB官方教程PPT,也是一个非常典型的CASE,故此翻译,并结合当前MongoDB版本做了一些内容上的更新。

本案例非常适合与IoT场景的数据采集,结合MongoDB的Sharding能力,文档数据结构等优点,可以非常好的解决物联网使用场景。

需求

案例背景是来自真实的业务,美国州际公路的流量统计。数据库需要提供的能力:

  • 存储事件数据
  • 提供分析查询能力
  • 理想的平衡点:

    • 内存使用
    • 写入性能
    • 读取分析性能
  • 可以部署在常见的硬件平台上

几种建模方式

每个事件用一个独立的文档存储

{
    segId: "I80_mile23",
    speed: 63,
    ts: ISODate("2013-10-16T22:07:38.000-0500")
}
  • 非常“传统”的设计思路,每个事件都会写入一条同样的信息。多少的信息,就有多少条数据,数据量增长非常快。
  • 数据采集操作全部是Insert语句;

每分钟的信息用一个独立的文档存储(存储平均值)

{
    segId: "I80_mile23",
    speed_num: 18,
    speed_sum: 1134,
    ts: ISODate("2013-10-16T22:07:00.000-0500")
}
  • 对每分钟的平均速度计算非常友好(speed_sum/speed_num);
  • 数据采集操作基本是Update语句;
  • 数据精度降为一分钟;

每分钟的信息用一个独立的文档存储(秒级记录)

{
    segId: "I80_mile23",
    speed: {0:63, 1:58, ... , 58:66, 59:64},
    ts: ISODate("2013-10-16T22:07:00.000-0500")
}
  • 每秒的数据都存储在一个文档中;
  • 数据采集操作基本是Update语句;

每小时的信息用一个独立的文档存储(秒级记录)

{
    segId: "I80_mile23",
    speed: {0:63, 1:58, ... , 3598:54, 3599:55},
    ts: ISODate("2013-10-16T22:00:00.000-0500")
}

相比上面的方案更进一步,从分钟到小时:

  • 每小时的数据都存储在一个文档中;
  • 数据采集操作基本是Update语句;
  • 更新最后一个时间点(第3599秒),需要3599次迭代(虽然是在同一个文档中)

进一步优化下:

{
    segId: "I80_mile23",
    speed: {
        0:  {0:47, ..., 59:45},
        ...,
        59: {0:65, ... , 59:56}
    }
    ts: ISODate("2013-10-16T22:00:00.000-0500")
}
  • 用了嵌套的手法把秒级别的数据存储在小时数据里;
  • 数据采集操作基本是Update语句;
  • 更新最后一个时间点(第3599秒),需要59+59次迭代;

嵌套结构正是MongoDB的魅力所在,稍动脑筋把一维拆成二维,大幅度减少了迭代次数;

每个事件用一个独立的文档存储VS每分钟的信息用一个独立的文档存储

从写入上看:后者每次修改的数据量要小很多,并且在WiredTiger引擎下,同一个文档的修改一定时间窗口下是可以在内存中合并的;
从读取上看:查询一个小时的数据,前者需要返回3600个文档,而后者只需要返回60个文档,效率上的差异显而易见;
从索引上看:同样,因为稳定数量的大幅度减少,索引尺寸也是同比例降低的,并且segId,ts这样的冗余数据也会减少冗余。容量的降低意味着内存命中率的上升,也就是性能的提高;

每小时的信息用一个独立的文档存储VS每分钟的信息用一个独立的文档存储

从写入上看:因为WiredTiger是每分钟进行一次刷盘,所以每小时一个文档的方案,在这一个小时内要被反复的load到PageCache中,再刷盘;所以,综合来看后者相对更合理;
从读取上看:前者的数据信息量较大,正常的业务请求未必需要这么多的数据,有很大一部分是浪费的;
从索引上看:前者的索引更小,内存利用率更高;

总结

那么到底选择哪个方案更合理呢?从理论分析上可以看出,不管是小时存储,还是分钟存储,都是利用了MongoDB的信息聚合的能力。

  • 每小时的信息用一个独立的文档存储:设计上较极端,优势劣势都很明显;
  • 每分钟的信息用一个独立的文档存储:设计上较平衡,不会与业务期望偏差较大;

落实到现实的业务上,哪种是最优的?最好的解决方案就是根据自己的业务情况进行性能测试,以上的分析只是“理论”基础,给出“实践”的方向,但千万不可以此论断。

VS InfluxDB

说到时序存储需求,大家一定还会想到非常厉害的InfluxDB,InfluxDB针对时序数据做了很多特定的优化,但MongoDB采用聚合设计模式同样也可以大幅度较少数据尺寸。根据最新的测试报告,读取性能基本相当,压缩能力上InfluxDB领先MongoDB。但MongoDB的优势在于可以存储更丰富的信息,比如地理坐标,文本描述等等其他属性,业务场景上支持更广泛。
另外,MongoDB的Sharding水平扩展能力,Aggragation功能,Spark Connector等等特性,对IoT来说,生态优势明显。

相关实践学习
钉钉群中如何接收IoT温控器数据告警通知
本实验主要介绍如何将温控器设备以MQTT协议接入IoT物联网平台,通过云产品流转到函数计算FC,调用钉钉群机器人API,实时推送温湿度消息到钉钉群。
阿里云AIoT物联网开发实战
本课程将由物联网专家带你熟悉阿里云AIoT物联网领域全套云产品,7天轻松搭建基于Arduino的端到端物联网场景应用。 开始学习前,请先开通下方两个云产品,让学习更流畅: IoT物联网平台:https://iot.console.aliyun.com/ LinkWAN物联网络管理平台:https://linkwan.console.aliyun.com/service-open
目录
相关文章
|
29天前
|
NoSQL 网络协议 MongoDB
Windows公网远程连接MongoDB数据库【无公网IP】
Windows公网远程连接MongoDB数据库【无公网IP】
|
30天前
|
存储 NoSQL 关系型数据库
一篇文章带你搞懂非关系型数据库MongoDB
一篇文章带你搞懂非关系型数据库MongoDB
53 0
|
1月前
|
人工智能 NoSQL MongoDB
|
2月前
|
SQL NoSQL Java
文档型数据库MongoDB
文档型数据库MongoDB
|
2月前
|
JSON NoSQL MongoDB
MongoDB详解(五)——MongoDB数据库简单使用
MongoDB详解(五)——MongoDB数据库简单使用
105 1
|
2月前
|
存储 NoSQL Linux
MongoDB详解(四)——MongoDB数据库安装
MongoDB详解(四)——MongoDB数据库安装
63 2
|
2月前
|
NoSQL 关系型数据库 MySQL
Windows、Linux、Mac安装数据库(mysql、MongoDB、Redis)#0
不同系统下进行MySQL安装、MongoDB安装、Redis安装【2月更文挑战第5天】
438 5
Windows、Linux、Mac安装数据库(mysql、MongoDB、Redis)#0
|
3月前
|
存储 JSON NoSQL
【MongoDB】<文档型数据库>Windows&Liunx安装MongoDB(无错完整)
【1月更文挑战第26天】【MongoDB】<文档型数据库>Windows&Liunx安装MongoDB(无错完整)
|
3月前
|
机器学习/深度学习 自然语言处理 NoSQL
|
3月前
|
NoSQL 安全 物联网
检索时间减少83%!部署MongoDB后,通用电气医疗集团狠狠提升了物联网设备的利用效率!
作为医疗技术领域的全球领导者,通用电气医疗集团选择了 MongoDB由其管理旗下物联网设备,从部署(生命周期初期,即 BoL)到报废(生命周期结束,即 EoL)的整个生命周期
1821 3
检索时间减少83%!部署MongoDB后,通用电气医疗集团狠狠提升了物联网设备的利用效率!

相关产品

  • 云原生多模数据库 Lindorm
  • 云数据库 MongoDB 版