MongoDB—单个庞大的原始数据集合。分裂还是不分裂？

我们从大量主机收集和存储检测数据。 我们的存储是MongoDB—多个具有副本的碎片。所有东西都存储在一个大型集合中。 我们插入的每个文档都是基于时间的观察，具有一些属性（度量）。时间戳是最重要的属性，因为所有查询至少都基于时间。文档从不更新，因此它是一个纯写入式查找模型。目前，它在几十亿个文档中运行得相当好

现在,

我们希望增长一点，最多保存12个月的数据，这可能会导致超过万亿次的观察（文档）。 我在想，把所有的东西都扔进一个庞大的收藏品是最好的选择，还是有一种更明智的方法。 我所说的更智能是指使用更少的硬件，同时仍然提供快速插入和（重要的）快速查询。 因此，我考虑将大型集合拆分为较小的部分，希望在索引、插入和查询速度方面获得内存

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

---

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

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

如果它是可以聚合的，我会说通过一个计划的map/reduce函数进行聚合，并将较小的数据大小存储在单独的集合中

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

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

如果你能详细说明你对查询的具体需求，你会更容易提出建议

---

希望能有所帮助。

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

建议继续进行单个收集，正如@Devesh hour-based shard所建议的，应该可以，在查询时需要注意新的“hour Key”以获得更好的性能。

您的查询范围是否基于时间？是的，时间是所有查询中的主要参数。此外，用户还可以选择其他属性。例如，“给我上个星期天的特定产地的东西，颜色是红色的，或者当温度低于零度时。”@Dima最后，你的决定是什么？你选择了哪种方式？@Bogdan Burim，我选择创建“分区”来存储受时间跨度限制的少量数据。在我的例子中，“分区”保存几天的数据。在我的例子中，分区是一个独立的数据库，但使用集合也有意义。。我想我之所以选择数据库，是因为当它们非常大时更容易删除。到目前为止效果很好。@Dima感谢分享您的经验！该集合保存一些传感器的纯原始数据。每次读取都是一组平面名称-值对，构成一个文档。查询可以通过属性的任意组合完成，但时间始终存在，并且是集合中的主要索引。我们已经使用了切分法，通过它们的起源来传播这些观察结果。但是这些东西的数量让我想知道单个集合是否是正确的选择。您有哪些类型的查询？您是否可以聚合旧记录，对于查询，只使用聚合值，或者需要从头开始计算每个查询的值？还有，您执行查询的频率是多少？实际上，当您提到“使用时间戳的小时字段进行切分”时，它敲响了警钟。。我没想过这个。我只是把绝对时间看作是切分键。谢谢