Azure Cosmos数据库更新模式

我最近开始使用Cosmos DB作为项目，我遇到了一些设计问题。从SQL背景来看，我知道相关数据应该嵌套在NoSQL数据库的文档中。这确实意味着文档可能变得相当大。Azure Cosmos数据库更新模式

由于不支持部分更新，因此当您要更新文档上的单个属性时，要实现哪种最佳设计模式？

我应该在阅读整个文档服务器端，更新值并将文档写回来以便执行更新吗？如果文档很大，如果所有的数据都嵌套，那么这看起来有问题。

如果我采用制作许多小文档和根据ID推断关系的方法，我认为这样可以更好地解决读/写问题，但感觉就像我反对NoSQL的概念，实质上是我我正在构建一个关系数据库。

感谢

2017-08-03 Ross

出色的问题。看起来好像社区也在问：https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6693091-be-able-to-do-partial-updates-on-document 这里的含义是，'小文件/推断关系'模式是现在走的路。看到白皮书或类似“小文件”的小文章会很可爱。 – Holf

请注意，Cosmos DB中文档的限制为2 MB，因此您不得不使用相对较小的文件。 – influent

锁定和锁定。如果部分更新成为可能，那就是需要发生的事情。用锁定保持写入延迟时间为15毫秒的SLA是一个困难的工程问题。

这似乎有问题，如果文件很大，如果你所有的数据都嵌套，这是不可避免的。

定义你的恐惧—烧毁请求单元，应用主机内存，入口/出口网络流量？你相信这是一个问题，但你没有说明具体的结果。我并不是说你错了，或者怀疑部分更新方法的效率，我只是说这个论点很薄弱。

通常你想JOIN没有在NoSQL，所以我完全与你在最后一段。

来源

2017-08-03 11:12:32 evilSnobu

感谢您的回复。这不是一个真正的争论，更多的是一个问题。我想所有你所定义的恐惧都是有效的，我只是从Cosmos DB的规模经验的人那里寻找建议。有人可以说“是的，你必须阅读整个文档，遍历嵌套属性中的列表，更新列表中的项目上的单个标志并将整个文档写回”。如果这是“正确”的方式或推荐的方式来处理更新宇宙数据库然后我很高兴。 – Ross

每当你要创建一个文档尽量考虑这一点：

是否文档的部分需要单独的访问。如果是，则创建一个引用文档，如果没有，则创建一个嵌入文档。

如果你想知道该怎么选择，我想你应该需要看看这个问题的MongoDB的，但是会帮助你Embedded vs Referenced Document

来源

2017-08-03 12:12:17 vikscool

Azure Cosmos数据库更新模式

回答

相关问题