MongoDB:非稳定时间序列的推荐模式/文档大小

Question

我在互联网上发现了很多围绕稳定时间序列数据的 MongoDB 架构的重要信息。但是in all , these examples ，新的数据对象正在稳定的基础上被插入(即，每 1 秒 1 次更新)。

在非稳定文档更新的情况下是否有推荐的架构？这方面的一个示例是对外部 API 执行 ping 操作以获取新数据。在对 API 的前几次 ping 期间，可能没有任何可用的新数据，因此 Mongo 中没有要更新的内容。但是几个 ping(可能是几秒钟，也可能是几分钟)之后，API 现在已经发布了 5 个新对象，所以现在 Mongo 需要更新 5 个不同的字段。

所以我们依赖于接收数据的时间，但这种关系不是 1:1(数据流不是恒定的)。这意味着预分配和填充一个 60 秒 x 60 分钟的嵌套对象...

values: {
0: { 0: {obj}, 1: {obj}, …, 59: {obj} },
1: { 0: {obj}, 1: {obj}, …, 59: {obj} },
…,
58: { 0: {obj}, 1: {obj}, …, 59: {obj} },
59: { 0: {obj}, 1: {obj}, …, 59: {obj} }

... 意义不大，因为我们不能保证能在1小时内填满。我们根本无法预测在给定时间段内将发布多少新对象。

与其严格根据时间单位创建嵌套网格，对于此用例，更好的方法是

1. 坚持使用嵌套对象模式
2. 但要定义一组自定义维度？

例如:

values: {
0: { 0: {obj}, 1: {obj}, …, 199: {obj} },
1: { 0: {obj}, 1: {obj}, …, 199: {obj} },
…,
198: { 0: {obj}, 1: {obj}, …, {obj}: 1100000 },
199: { 0: {obj}, 1: {obj}, …, {obj}: 1500000 }

... 随机选择 200x200 是因为，我不知道，上限为 40,000 个对象/文档似乎是一个不错的整数？根据外部 API 产生的数据量，此文档可能会在一天或两天内填写完毕，如果没有太多操作，可能长达一周。

如果这是正确的方法，是否有应考虑的推荐和/或最大网格大小？网格越小，生成的文档就越多，我们就必须跟踪这些文档。网格越大，集合中 float 的文档就越少，但更新可能需要更长的时间。

这个答案很可能是基于一些假设，所以为了讨论的目的，让我们假设我们对 this API endpoint 感兴趣. (此 API 实时发布 BTCChina 在线交易中发生的比特币交易。)我们可以假设:

1. 它每天产生 3 万到 6 万个新对象

2. 每个对象的大小如下:

   { "date":"1425556988",//交易日期 "price":1683.98,//每个 BTC 的价格 "amount":0.0134,//BTC 交易量 "tid":"24357098"//交易ID

3. 客户将不会订阅这些文档 - 数据的客户端解析是基于这些原始信息生成的

4. 我们希望永远保留这些原始文件，以防将来需要它来重新生成更高级别的决议

如有任何建议，我们将不胜感激!谢谢!

Answer 1

请记住，在面向文档的存储中，每个文档都需要一个时间戳。这意味着创建任意 bin 是毫无意义的，因为你不能说“这个文档指的是这个小时/分钟。”

您有 3 个选择:

保持小时>分钟>第二个结构并且在没有可用数据时不要创建对象。这就是无模式设计的美妙之处。这意味着如果在 12:59:32 没有数据进来，该对象将丢失。将其视为稀疏矩阵。

保留小时>分钟>第二个结构并为每个包含 NaN 的文档预分配一个 60x60 的对象。好处是文档不必在内存中移动。 (热门选择)

将每个时间戳存储为自己的文档。这里的好处是分辨率最高，因为买入/卖出价格在一秒钟内最多可以变化 1000 次。