简而言之，我们通过GPS进行商务车辆控制，目前正在处理具有大量数据的mysql。我们正在研究以db作为db移动到mongoDB的可能性，但仍然看不清楚。目前，我们正在使用mongoHQ（daas mongoDB）进行测试。
我们有aprox 2000 gps每分钟发送信息的位置，速度和状态。在一天，24小时，1440分钟，每个gps发送1440条信息，所以1440tracks / device * 2000devices = 2.8M track / day。
我们的第一个想法是将每个曲目收集并存储为此集合中的文档，但每月2.8M生成曲目在月末我们在集合中有+ -80M文档。我们必须在日期之间创建每日，每周或报告，例如，如果在服务2个月后，客户想要查看3天的报告，我们将需要在160M内找到1440个轨道/天* 3天文件......响应时间如何？ mongodb饱和了？如果多个客户端同时发出类似请求，会发生什么？
注意：每个文档占用大约0.3KB，每天每个GPS 占用0.3 * 1440 = 0.5MB，虽然存储量更大......
第二个想法嵌入。
我们决定在每日文档中对所有曲目进行分组。每个都有1 gps doc / day和1440个信息轨道被添加到一个轨道数组{}中。因此，每天我们只有2k文档，到月底只有60k而不是80M！我们认为“我们已经找到了黄金”，直到我们意识到$每天在每个文档中推送1440个曲目创建了重新分配，每个文档需要更长的时间并且不可行。我们怎样才能改进嵌入？如果第一个想法是每天产生大约1GB的存储空间，那么大约是3GB ......
第一个想法是track = doc，gps每天需要0.5MB（存储量更多），2000个团队每天大约需要1GB。每月大约30 GB，即使是最重的mongohq计划（600GB）或mongolab（400GB），我们在达到限制之前最多可以使用20个月。 但是在一年半之后的mysql中，我们并没有占用超过30GB ..：/
目前，我们没有看到更改选项，我们现在必须坚持使用Mysql ...如何从mysql到nosql的良好转换？
答案 0 :(得分：1)
当您知道您的文档达到一定规模时，您可以通过在创建时预先填充它们来避免重新分配。
当您知道阵列最终将有1440个条目时，您可以创建具有1440个虚拟条目的文档，这些条目具有相同的字段集，所有字段都填充了与实际数据长度相同的占位符数据。然后，当您逐渐添加实际数据时，将这些条目替换为$ set而不是使用$ push。
为了提高汇总过去几天数据的报告的效果，您可以每晚运行MapReduce作业，将当天的相关数据汇总到新的收藏中。
答案 1 :(得分：1)
欢迎使用大数据......
我们做的是：
我们以大约200对数/秒的速度涌入了日志事件。
这些日志放在名为log.foo的database.collection中。
您不接触这些记录。这里只制作新的插入物。永远不要更新他们。它会锁定你的数据库并杀死它的性能。
您要做的是创建一个名为aggregate.foo的新database.collection。这是一个新数据库，因为它将拥有自己的写锁，因此不会干扰您的日志数据库。
然后你创建一个用cron或类似的东西运行的作业。对于给定的时间片，此作业对log.foo进行查询（ObjectId对此非常有用）。作业会根据您的需要聚合这些行，并将新文档放入aggregate.foo。然后，如果需要，您可以选择从log.foo删除行，但存储很便宜，所以为什么不保留它们。
所以基本上：结合你的两个想法，但分开日志插入和聚合。