如果需要更新文档中的数组，使用DocumentDB是一个不错的选择

本文关键字：一个 选择 使用 更新 文档 如果 数组 DocumentDB | 更新日期: 2023-09-27 18:06:38

如果需要更新文档中的数组，使用DocumentDB是一个不错的选择吗?或不呢?

老板决定在这个项目中使用DocumentDB。我开始研究它，并开始认为也许DocumentDB不是一个好的选择。

我们有一个webjob，每天运行几次，它使用API来获取文档(json)。这个json包含一些字段:id， _ts，…它还有一个数组，它是历史数据(过去30天):

{"date": "2016-08-01", "value": "100", ....},
{"date": "2016-08-02", "value": "100", ....},
{"date": "2016-08-03", "value": "100", ....},
...

最初，我们保存每个文档，然后我们意识到我们必须将这些文档组合起来以获得过去30天以上的数据。所以，过程是:

1)获取包含所有数据的主文档，对其进行解析以获取'key'字段。在本例中为Date。

2)调用api，获取新数据，解析得到数组。如果'date'不存在，则插入到#1中，如果存在，则在主文档中更新它。

3)更新主文档。

基本上，这更像是使用documentDB作为SQL服务器，基于'key'更新行。我可以看到的一个可能的问题是:随着时间的推移，文档的大小可能会非常大，这意味着在#1和#3中，我们需要解析和更新一个巨大的json文件。这肯定会降低性能。这就是为什么我开始认为也许我们不应该在这种情况下使用documentDB。

我只是想先听听别人的意见，然后再跟老板提。

谢谢

如果需要更新文档中的数组，使用DocumentDB是一个不错的选择

您可能需要重新考虑将单个文档聚合为一个大文档的设计。首先，对文档的最大大小有限制。看看DocumentDB quotas，到目前为止，DocumentDB集合中文档的最大大小可以是512KB。

我仍然会考虑DocumentDB来存储JSON文档(尽管您需要考虑它的成本方面)。它具有出色的查询支持。也许您可以在文档集合上创建适当的索引。在这种情况下，您不需要聚合数据。

相关文章：