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

所以，比如我有集文档的是这样的：DocumentDB：如何更好地构建数据更新

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

在此范围内的低温性能都写一次，访问有时，热性能相当写，然后经常访问\更新（但在不同的使用情况下，它不是相同的子文档或同一对象的部分）。文档数量相当大（1M以上），热数据的大小至少比冷数小十倍。

由于部分更新仍然最想做但没有实现的功能，只更新hotField1方法是：

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

这对于RU而言是昂贵的，并且不能很好地扩展。

所以问题是如何在DocumentDB中调用这些数据调用&以最小化成本？

发现的替代品：

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

PS。 C＃中的标签用于我们使用的客户端库。如果它缺乏可以使用REST接口的话。

来源

2017-01-23 Sanctus

＃3今天也不可能。我的第一个建议是使用直接的一体化文档方法进行构建并对其进行基准测试。如果不符合规定，则使用分区集合调整已分配的吞吐量参数，否则请转至较高的S级别。如果这还不够，那么考虑一个更复杂的分区设计，根据该领域的“热”程度进行分区。根据我的经验，工程师对什么是快速的和什么不会脱离现实的假设。你需要试验。 –

@LarryMaccherone，我们已经有关于RDBMS的工作系统，所以我们已经收集了一些数量的统计数据。你能详细说明一下，更复杂的设计是什么意思？ – Sanctus

仅仅是将数据分解为热场和冷场是构建，维护和增加新开发人员的更多工作。在知道简单的一体化文档设计是否足够之前，为什么会产生这种成本？ –

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

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

更新子文档（＃3选择）与更新顶层属性没有区别 - 您仍在检索和重写文档（子文档只是文档中的另一个属性）。虽然它可能会或可能不会减少RU（您需要进行基准测试，如Larry在评论中指出的那样），但您可以选择将您的热门属性存储在单独的（较小的）文档中（或多个较小的文档）。使用较少的属性时，更新期间消耗的带宽将会减少，索引更新也会减少。但是，由于您现在正在检索多个文档（可能跨越多个调用），因此您可能会发现此活动会将存储在单个文档中的任何RU节省排除在外。

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

来源

2017-01-23 22:12:53

我花了一些时间思考是否存储单独文档是一个好主意。显然 - 不。我确信部分更新是计划中的功能，但显然并非易事。首先制作特殊类型的数据 - 子文档是不合理的。因此它不是普通的JSON对象，而是DocDB中的小文档（即带有_etag和其他_字段）。我想这是可能的并发控制，因为只是部分更新将需要像_etag为每个用户添加文档的属性。然后子文件对CC有效。你怎么看？ – Sanctus

我真的不明白你的后续问题，不是一个普通的JSON对象，也不了解你如何得出单独的文件（一种非常常用的技术）并不是一个好主意，但是......评论不是为了讨论。 –

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

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

所以，如果你有一个DB有两个集合，并且每个集合的性能等级为S1，即$ 25/month。

$ 25×2 = $ 50

情况下，你需要一个更好的性能，并改变一个到S2将向您收取：

$ 50 + $ 25 = $ 75

来源

2017-01-23 20:12:03

不完全是我想要的，但有很好的洞察力 – Sanctus

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

回答

相关问题