Azure Cosmos数据库更新模式
我最近开始使用Cosmos DB进行一个项目，并且遇到了一些设计问题。 从SQL背景来看，我知道相关数据应该嵌套在NoSQL数据库的文档中。 这确实意味着文档可能变得相当大。
由于不支持部分更新，因此当您想要更新文档上的单个属性时，实现哪种最佳设计模式？
我是否应该阅读整个文档服务器端，更新值并立即写回文档以执行更新？ 如果文档很大，如果所有的数据都嵌套，那么这看起来有问题。
如果我采用制作很多小文档并基于ID推断关系的方法，我认为这样可以更好地解决读/写问题，但是感觉我反对NoSQL的概念，实质上我构建了一个关系D B。
谢谢
锁定和锁定。 如果部分更新成为可能，那就需要这样做。 锁定<15ms写入延迟SLA是一个困难的工程问题。
如果文档很大，如果所有的数据都嵌套，那么这看起来有问题。
定义您的恐惧请求单元，应用主机内存，入口/出口网络流量？ 你相信这是一个问题，但你没有说明具体的结果。 我并不是说你错了，或者怀疑部分更新方法的效率，我只是说这个论点很薄弱。
通常你想在NoSQL中JOIN任何东西，所以我完全和你在最后一段。
每当你尝试创建一个文档时，都要考虑这一点：
文档部分是否需要单独访问？ 如果是，则创建一个引用文档，如果没有，则创建一个嵌入文档。
如果你想知道选择什么，我认为你应该看看MongoDb的这个问题，但是会帮助你嵌入与引用文档
嵌入或引用是我在NoSQL世界中设计文档结构时面临的最常见问题。
在嵌入式关系中，子实体已嵌入到父文档中。 在引用关系中，单独文档中的子实体和其他文档中的父实体基本上具有两种（或更多）类型的文档。
没有一种关系模式适合所有人。 您应该采取的方法取决于正在设计的数据的检索和更新。
1.您是否需要检索所有子实体以及父实体？ 如果是，则使用嵌入式关系。
2.您的使用案例是否允许单独检索实体？ 这种情况使用关系模式。
我工作过的大多数用例都使用关系模式。 例如：社交图（关系树配置文件），接近点（基于GeoJSON的邻近搜索），分类列表等。
关系模式也更容易更新和维护，因为实体存储在单个文档中。
链接地址: http://www.djcxy.com/p/40139.html