MongoDB - 单个巨大的原始数据集合。是否分裂？

我们收集并存储来自大量主机的检测数据。我们的存储是MongoDB--带有副本的几个分片。一切都存储在一个大集合中。我们插入的每个文档都是基于时间的观察结果，并带有一些属性（测量结果）。时间戳是最重要的属性，因为所有查询都至少基于时间。文件从不更新，所以它是一个纯粹的写入查找模型。目前它与数十亿文档合作良好。MongoDB - 单个巨大的原始数据集合。是否分裂？

现在，

我们要长一点，容纳12个月数据的可能构成一个可怕万条+的意见（文件）。如果把所有东西都倾倒到一个单一的怪物收藏中，那么我是在徘徊，这是最好的选择，或者有更聪明的方法去实现它。通过更智能的我的意思是 - 使用更少的硬件，同时仍然提供快速插入和（重要的）快速查询。所以我想将大集合拆分成更小的部分，希望能够获得索引，插入和查询速度上的内存。

我查看了碎片，但按时间戳分片听起来像一个糟糕的主意，因为所有写入操作都会进入一个节点，取消分片的好处。插入率非常高，所以我们需要分片在这里正常工作。我也想过每个月创建一个新集合，然后为用户查询选取相关集合。超过12个月的收藏将被丢弃或归档。还有一个选项可以每个月创建一个全新的数据库并进行类似的轮换。其他选项？或者也许一个大集合是THE选项增长真正大吗？

请在类似的应用程序中分享您的经验和注意事项。

来源

2013-04-04 Dima

您的查询是基于时间的范围吗？ – 2013-04-04 19:43:17

是的，时间是所有查询中的主要参数。另外，用户可以选择其他属性。例如，“从特定来源的最后一个星期日拿到东西，并有红色或温度低于零”。 – Dima 2013-04-04 19:55:55

这实际上取决于您的查询的用例。

如果它是可以聚合的东西，我会说通过预定的map/reduce函数来做到这一点，并将较小的数据大小存储在单独的集合中。

如果一切都应该在同一个集合中，并且应该同时查询所有数据以生成所需的结果，那么您需要使用Sharding。然后，根据查询的数据大小，您可以使用内存映射/减少，甚至可以在应用程序层执行。

正如您所指出的，基于时间的Sharding是一个非常糟糕的主意。它使所有写入到一个分片，所以定义你的分片键。 MongoDB Docs，对此有很好的解释。

如果您可以详细说明您的具体需求，查询会更容易建议。

希望它有帮助。

来源

2013-04-04 18:53:19 Majid

该集合保存纯粹的原始数据 - 一些传感器的读数。每个阅读是一组平面名称 - 值对，它们构成一个文档。查询可以通过任意属性组合来完成，但时间总是存在，并且是集合中的主要索引。我们已经使用分片传播这些观察的起源。但是东西的剪切量让我怀疑单一收集是否是正确的选择。 – Dima 2013-04-04 19:52:58

你有什么类型的查询？你可以聚合旧的记录和查询只使用聚合值，或者它需要从头开始计算每个查询？你也执行查询的频率如何？ – Majid 2013-04-04 21:01:13

我认为每月收集会帮助你得到一些提升，但我想知道为什么你不能使用时间戳的小时字段进行分片。您可以添加一个将保留时间戳的HOUR部分的列，并且当您对它进行碎片整理时，将会很好地共享，因为您每天都有重复的时间。我还没有测试过，但认为它可能会帮助你

来源

2013-04-05 03:24:28 Devesh

实际上，当你提到“使用你的时间戳的时间字段进行分片”时，它敲响了钟声。我没有想过这个。我只是将绝对时间视为分片密钥。谢谢！ – Dima 2013-04-05 08:01:53

建议继续单个集合，如@Devesh小时基于分片应该没问题，在查询时需要照顾新的“小时键”获得更好的表现。

来源

2018-01-24 12:37:32

MongoDB - 单个巨大的原始数据集合。是否分裂？

回答

相关问题