node.js - Mongodb:带有搜索的数据版本控制

Question

相关于Ways to implement data versioning in MongoDB和 structure of documents for versioning of a time series on mongodb

当我还需要能够处理查询时，我应该采用什么数据结构进行版本控制？

假设我有 8500 个以下形式的文档

{ _id: '12345-11',
  noFTEs: 5
}

每个月我都会在大约 30 个文档中获得有关 noFTE 更改的详细信息，我希望将新数据与之前的数据以及日期一起存储。

这似乎会导致:

{ _id: '12345-11',
  noFTEs: {
     '2015-10-28T00:00:00+01:00': 5,
     '2015-1-8T00:00:00+01:00': 3
  }
}

但我也希望能够对最新数据进行搜索(例如 noFTEs > 4，并且该元素应被视为 5，而不是 3)。在那个阶段我只知道我想使用最新的数据，并且不会知道 key 。因此，另一种选择是数组

{ _id: '12345-11',
  noFTEs: [
     {date: '2015-10-28T00:00:00+01:00', val: 5},
     {date: '2015-1-8T00:00:00+01:00', val: 3}
  }
}

另一种选择 - 正如 @thomasbormans 在下面的评论中所建议的 - 是

{ _id: '12345-11',
  versions: [
     {noFTEs: 5, lastModified: '2015-10-28T00:00:00+01:00', other data...},
     {noFTEs: 3, lastModified: '2015-1-8T00:00:00+01:00', other...}
  }
}

我真的很感激一些关于我在开始之前需要考虑的见解，我担心我会导致一个对 Mongo 来说工作量相当大的查询。 (实际上，还有其他 3 个字段可以组合起来进行搜索，其中之一也可能会随着时间的推移而发生变化。)

Answer 1

当您为 noSQL 数据库建模时，需要记住一些事情。

首先是每个文档的大小。如果您在文档中使用数组，请确保它不会超过每个文档 16 Mb 的大小限制。

第二件事，您必须对数据库进行建模才能轻松检索内容。为了提高应用程序的速度和易用性，一些“非规范化”是可以接受的。

因此，如果您需要了解当前的 noFTE 值，并且仅出于审计目的而需要保留历史记录，则可以使用 2 个集合:

collection["current"] = [
    {
        _id: '12345-11',
        noFTEs: 5, 
        lastModified: '2015-10-28T00:00:00+01:00'
    }
]

collection["history"] = [
    {   _id: ...an object id...
        source_id: '12345-11',
        noFTEs: 5, 
        lastModified: '2015-10-28T00:00:00+01:00'
    },
    {
        _id: ...an object id...
        source_id: '12345-11',
        noFTEs: 3, 
        lastModified: '2015-1-8T00:00:00+01:00'
    }
]

通过这种方式，您可以使最常访问的记录更小(我认为当前版本的访问更频繁)。这将使 mongo 更容易将“当前”集合保留在内存缓存中。并且从磁盘中检索文档的速度会更快，因为它们更小。

我认为这种设计在内存优化方面是最好的。但这个决定与您对数据的用途直接相关。

编辑:我更改了原始响应，以便为每个历史条目创建单独的插入。在我原来的答案中，我试图让您的历史记录条目接近您的原始解决方案，以专注于非规范化主题。然而，将历史记录保存在数组中是一个糟糕的设计决策，我决定使这个答案更加完整。

在历史记录中保留单独的插入而不是创建数组的选择有很多:

1) 每当您更改文档的大小(例如，向其中插入更多数据)时，mongo 可能需要将该文档移动到磁盘的空白部分，以容纳更大的文档。这样，您最终会产生存储间隙，从而使您的集合变得更大。

2) 每当你插入一个新文档时，Mongo 都会尝试根据之前的插入/更新来预测它会变成多大。这样，如果您的历史文档大小相似，填充因子将变得接近最佳。但是，当您维护不断增长的数组时，这种预测效果不佳，并且 mongo 会通过填充浪费空间。

3) 将来，如果历史记录集合变得太大，您可能会想要缩小它。通常，我们会定义历史保留策略(例如:5 年)，您可以备份和修剪早于该策略的数据。如果您为每个历史条目保留了单独的文档，则执行此操作会容易得多。

我可以找到其他原因，但我相信这三个足以说明问题。