首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >MongoDB加载每日数据(还是坚持使用mysql?)

问MongoDB加载每日数据(还是坚持使用mysql?)
EN

Stack Overflow用户
提问于 2013-12-16 13:39:01
回答 2查看 1K关注 0票数 1

简而言之,我们有一个业务车辆控制通过GPS,目前工作在mysql与大量的数据。我们正在研究迁移到mongoDB作为db的可能性,但仍不清楚。目前,我们正在使用mongoHQ (daas mongoDB)进行测试。

我们有aprox 2000全球定位系统每分钟发送信息,包括位置、速度和状态。在一天,24小时1440分钟,每个gps发送1440轨道的信息,所以1440轨道/设备*2000设备= 2.8M轨道/天。

我们的第一个想法是在这个集合中有一个集合并将每个曲目作为文档存储,但是在月底,每天有2.8M生成轨道,我们在一个集合中有+-8000万个文档。我们必须创建每日、每周或日期之间的报告,例如,如果在服务2个月后,客户想要查看3天的报告,我们必须在大约1.6亿份文档中查找1440条轨道/日*3天.响应时间是多少?饱和的mongodb?如果多个客户同时提出类似的请求,会发生什么情况?

注:每个文档占用约0.3KB,也就是说,每个全球定位系统每天占用0.3 * 1440 = 0.5MB,尽管storageSize较大.

第二思想嵌入。

在这里,我们决定把所有的曲目编成一份每日文件。每个路径都有1个gps文档/天,1440个信息轨道被添加到一个轨道{ }数组中的$push。因此,每一天我们将只有2k文档,到月底只有60000,而不是8000万!我们一直以为“我们找到了金子”,直到我们意识到$pushing 1440轨迹在每个文档中每天都会产生重新分配,因此每个文档所需的时间要长得多,而且不可行。我们如何改进嵌入?如果第一个想法是每天产生大约1GB的存储,那么这个大约是3GB.

对于第一个想法,track = doc,gps每天需要0.5MB (稍微多一点存储空间),对于2000支队伍来说,每天大约是1GB。每月约30 GB,即使有最重的蒙古总部计划(600 GB)或蒙古国(400 GB),我们将有最多20个月的服务在达到极限之前。但在mysql中,一年半之后,我们占用的内存不超过30 in。:/

目前,我们没有看到改变的选择,我们必须坚持Mysql目前.你知道如何从mysql很好地切换到nosql吗?

EN

回答 2

Stack Overflow用户

回答已采纳

发布于 2013-12-16 14:40:22

欢迎来到大数据..。

我们所做的是:我们有大量的日志事件以大约200条日志/秒的速度流入。这些日志被放入一个名为database.collection的log.foo中。你不能碰这些唱片。这里只有新的插入件。永远不要更新他们。它会锁定您的数据库并破坏它的性能。

您要做的是创建一个名为database.collection的新aggregate.foo。这是一个新的数据库,因为它将有自己的写锁,因此不会干扰您的日志数据库。

然后创建一个与cron或类似的任务一起运行的作业。这项工作在给定的时间内对log.foo进行查询(ObjectId对此非常有用)。该作业按您认为合适的方式聚合这些行,并将新文档放入aggregate.foo中。如果需要,可以选择从log.foo中删除行,但是存储成本很低,那么为什么不保留它们呢?

因此,本质上:合并您的两个想法,但单独的日志插入和聚合。

票数 1
EN

Stack Overflow用户

发布于 2013-12-16 14:27:21

当您知道您的文档将达到一定大小时,可以通过在创建时预先填充它们来避免重新分配。

当您知道您的数组最终将有1440个条目时,您可以使用1440个虚拟条目来创建文档--具有相同字段集的条目,所有这些条目都填充了占位符数据,这些占位符数据的长度与实际数据相同。然后,当您逐步添加实际数据时,将这些条目替换为$set,而不是使用$push。

为了提高总结过去几天数据的报告的性能,您可以每天晚上运行一个MapReduce作业,将当天的相关数据聚合到一个新的集合中。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/20612353

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档