7

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

现在，

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

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

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

4

3 回答 3

2

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

于 2013-04-05T03:24:28.557 回答
2

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

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

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

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

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

希望能帮助到你。

于 2013-04-04T18:53:19.250 回答
0

建议继续进行单个收集，正如@Devesh 建议的基于小时的分片应该没问题，在查询时需要处理新的“小时键”以获得更好的性能。

于 2018-01-24T12:37:32.810 回答