DocumentDB：如何更好地构建数据以进行更新答案

【问题标题】：DocumentDB: How to better structure data for updatesDocumentDB：如何更好地构建数据以进行更新
【发布时间】：2017-01-23 19:50:23
【问题描述】：

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

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

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

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

索取完整文档
更改 hotField1 或 hotField2
写回整个文档

这在 RU 方面代价高昂，并且无法很好地扩展。

那么问题是如何在 DocumentDB 中组织这些数据和调用以最小化成本？

发现的替代品：

~~显然最好：检索一个属性；改变;更新~~ - 还没有。
分离两个集合，使用存储过程从主集合中检索，然后从字典中检索？
将 hotFields1-2 作为子文档({ sub: {hf1:0, hf2:""}}) 并以某种方式只更新它？（我不确定是否可能）

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

【问题讨论】：

#3 今天也是不可能的。我的第一个建议是使用直接的多合一文档方法构建它并对其进行基准测试。如果它不符合标准，则在使用分区集合时调整分配的吞吐量参数，如果不是，则转到更高的 S 级别。如果这仍然不够，那么根据字段的“热”程度考虑更复杂的分区设计。以我的经验，工程师关于什么会很快，什么不会的假设与现实相去甚远。你需要试验一下。
@LarryMaccherone，我们已经在 RDBMS 上有了工作系统，所以我们已经收集了一些统计数据。你能详细说明一下，更复杂的设计是什么意思？
只是将您的数据按热域和冷域拆分是构建、维护和培养新开发人员的更多工作。在您知道简单的多合一文档设计是否足够之前，为什么要承担这笔费用？

标签： c# azure-cosmosdb

【解决方案1】：

虽然没有确切的“最佳”答案：

您的#2 选择不适用于存储过程，因为存储过程的范围是一个集合。

更新子文档（#3 选择）与更新顶级属性没有什么不同 - 您仍在检索和重写文档（子文档只是文档上的另一个属性）。

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

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

【讨论】：

我花了一些时间考虑存储单独的文档是否是个好主意。显然 - 不。我确信部分更新是计划中的功能，但这显然不是一件容易的事。首先制作特殊类型的数据 - 子文档不是很合理吗？因此它将不是一个普通的 JSON {} 对象，而是 DocDB 术语中的小文档（即带有 _etag 和其他 _ 字段）。我想并发控制是可能的，因为对于每个用户添加的文档属性，部分更新将需要像 _etag 这样的东西。则子文档对 CC 有效。你怎么看？
老实说，我不明白你的后续问题，关于不是一个普通的 JSON 对象，我也不明白你如何得出结论，拥有单独的文档（一种非常常用的技术）不是一个好的想法，但是... cmets 不是用来讨论的。

【解决方案2】：

基于文档的 NoSQL 会在您更改一个或所有属性后替换文档。

在成本方面，它是基于每个收集的基础。

因此，如果您的数据库中有两个集合，每个集合的性能层为 S1，即每月 25 美元。

25 美元 x 2 = 50 美元

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

50 美元 + 25 美元 = 75 美元

【讨论】：

不是我想要的，但有很好的洞察力