MongoDB - 单一庞大的原始数据集合。分还是不分？

Question

我们从大量主机收集和存储检测数据。我们的存储是 MongoDB——几个带有副本的分片。一切都存储在一个大型集合中。我们插入的每个文档都是基于时间的观察，具有一些属性(测量值)。时间戳是最重要的属性，因为所有查询都至少基于时间。文档永远不会更新，所以它是一个纯粹的 write-in-look-up 模型。现在它可以很好地处理数十亿个文档。

现在，

我们希望增长一点，并保存长达 12 个月的数据，这些数据可能达到可怕的万亿以上观察(文档)。如果将所有东西都倾倒到一个巨大的集合中是最好的选择，或者有更聪明的方法来解决它，我一直在徘徊。我的意思是更智能 - 使用更少的硬件，同时仍然提供快速插入和(重要的是)快速查询。所以我考虑将大集合拆分成更小的部分，希望在索引、插入和查询速度方面获得内存。

我研究了分片，但按时间戳分片听起来是个坏主意，因为所有写入都将进入一个节点，从而取消了分片的好处。插入率非常高，所以我们需要分片才能在这里正常工作。我还考虑过每个月创建一个新集合，然后为用户查询挑选一个相关集合。超过 12 个月的收藏将被删除或存档。还可以选择每月创建全新的数据库并进行类似的轮换。其他选择？或者也许一个大集合是THE真正变大的选择？

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

Answer 1

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

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

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

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

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

希望对你有帮助。