Question

例如，我有像这样的文档集合：

{
   hotField1 : 0,
   hotField2 : "",
   coldField1 : 0,
...
   coldFieldN : ""
}

在此范围内，冷属性被写入一次，有时访问，热属性被写入然后经常被访问\更新（但在不同的用例中，它不是相同的子文档或同一对象的部分）。文件数量相当庞大（1M及以上），热数据的大小至少比寒冷少十倍。

由于部分更新仍然是最需要但尚未实现的功能，因此只有更新hotField1的方法是：

申请完整文件
更改hotField1或hotField2
回写整个文件

这在RU方面成本很高，并且不能很好地扩展。

所以问题是如何在DocumentDB中组织此类数据和调用以最大限度地降低成本？

发现的替代方案：

~~显然最好：检索一个属性;更改;更新~~ - 尚未。
在两个集合上分开，使用存储过程从Main Collection检索然后从Dictionary？
将hotFields1-2作为子文档({ sub: {hf1:0, hf2:""}})放置并以某种方式仅更新它？（我不确定是否有可能）

PS。我们使用的客户端库的标签中的C＃。如果它缺少smth，则可以使用REST接口。

Answer 1

虽然没有确切的＆＃34;最好的＆＃34;回答：

您的＃2选项不适用于存储过程，因为存储过程的范围限定为集合。

更新子文档（＃3选项）与更新顶级属性没什么区别 - 您仍然在检索和重写文档（子文档只是文档上的另一个属性）。

虽然它可能会或可能不会减少RU（您需要进行基准测试，正如Larry在评论中指出的那样），您可以选择将热属性存储在单独的（较小的）中文件（或多个较小的文件）。使用较少的属性，更新期间消耗的带宽将减少，索引更新也会减少。但是，由于您现在正在检索多个文档（可能跨多个调用），您可能会发现此活动无法将任何RU节省存储在单个文档中。

注意：没有什么能阻止您将这些单独的文档存储在同一个集合中（这样您就可以使用存储过程解决问题，正如您在＃2选择中所建议的那样）。您只需要创建某种类型的属性来帮助您识别不同的文档类型。

Answer 2

一旦更改了一个或所有属性，基于文档的NoSQL就会替换文档。

就成本而言，它基于每个收集基础。

所以，如果你有一个带有两个集合的数据库，每个集合的性能等级为S1，即25美元/月。

$ 25 x 2 = $ 50

如果您需要更好的性能，并将其中一个更改为S2，则需要付费：

$ 50 + $ 25 = $ 75

DocumentDB：如何更好地构建更新数据

2 个答案: