例如，我有这样的文档集合：
{
hotField1 : 0,
hotField2 : "",
coldField1 : 0,
...
coldFieldN : ""
}
在这个范围内，冷属性被写一次，有时被访问，热属性被写，然后经常被访问\更新(但在不同的用例中，它不是同一个子文档或同一对象的一部分)。文档数量相当巨大(1M及以上)，热数据的大小至少是冷数据的十倍。
由于部分更新仍然是最需要但尚未实现的功能，更新hotField1的唯一方法是：
- 请求完整文档
- 更改hotField1或hotField2
- 回写整个文档
就RU而言，这是昂贵的，而且扩展性不太好。
所以问题是如何组织这样的数据&调用DocumentDB以最大限度地降低成本
发现的替代品：
显然最好：检索一个属性；改变更新-尚未更新- 分离两个集合，使用存储过程从主集合检索，然后从字典检索
- 将hotFields1-2作为子文档
({ sub: {hf1:0, hf2:""}})，并以某种方式只更新它？(我不确定是否可能)
PS。我们使用的客户端库的标签中的C#。如果它缺少smth，那么可以使用REST接口。
虽然没有确切的"最佳"答案：
您的#2选择将不适用于存储过程，因为存储过程的作用域是一个集合。
更新子文档(#3选项)与更新顶级属性没有什么不同——您仍在检索和重写文档(子文档只是文档上的另一个属性)。
虽然它可能会也可能不会减少RU(正如Larry在评论中指出的那样，你需要进行基准测试)，但你可以选择将热门属性存储在一个单独的(较小的)文档(或多个较小的文档)中。属性越少，更新过程中消耗的带宽就越少，索引更新也就越少。然而，由于您现在要检索多个文档(可能是多个调用)，您可能会发现此活动会抵消存储在单个文档中所节省的任何RU。
注意：没有什么可以阻止您将这些单独的文档存储在同一个集合中(这可以让您使用存储过程来解决问题，正如您在#2选择中所建议的那样)。您只需要创建某种类型的属性来帮助识别不同的文档类型。
一旦更改一个或所有属性，基于Documents的NoSQL就会替换文档。
就成本而言，它是以每次收集为基础的。
因此，如果您有一个DB，其中有两个集合，每个集合的性能级别为S1，即每月25美元。
$25 x 2=$50
如果你需要更好的性能，并将其更改为S2，你将被收取费用：
$50+$25=75