首页 文章

Azure Cosmos数据库更新模式

提问于
浏览 次
12

我最近开始使用Cosmos DB进行项目，我遇到了一些设计问题 . 来自SQL背景，我知道相关数据应该嵌套在NoSQL DB上的文档中 . 这确实意味着文档可能变得非常大 .

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

我是否应该阅读整个文档服务器端，更新值并立即写回文档以执行更新？如果文档很大，这似乎有问题，如果你的所有数据都是嵌套的，那么它们是不可避免的 .

如果我采用制作许多较小文档并根据ID推断关系的方法，我认为这将立即解决读取/写入更新问题，但感觉我反对NoSQL的概念，实质上我正构建一个关系D B .

谢谢

azure azure-cosmosdb

3 回答

  • 0

    Locking and latching. 这是一个很难解决的工程问题，即使用锁定保持<15ms的写延迟SLA .

    如果文档很大，这似乎有问题，如果你的所有数据都是嵌套的，那么它们是不可避免的 .

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

    通常你想在NoSQL中没有 JOIN ，所以我在最后一段完全和你在一起 .

    回复于
  • 2

    每当您尝试创建文档时，请尝试考虑以下事项：

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

    如果你想知道该选择什么，我想你应该看一下这个问题，对于MongoDb，但会帮助你Embedded vs Referenced Document

    回复于
  • 4

    Embed or Reference 是我在NoSQL世界中设计文档结构时遇到的最常见问题 .

    在嵌入式关系中，子实体已嵌入到父文档中 . 在引用关系中，单独文档中的子实体和另一文档中的父实体，基本上具有两种（或更多）类型的文档 .

    没有一种关系模式适合所有人 . 您应采取的方法取决于正在设计的数据的检索和更新 .

    1.您是否需要检索所有子实体以及父实体？如果是，请使用嵌入式关系 .

    2.您的用例是否允许单独检索实体？本案例使用关系模式 .

    我工作过的大部分用例都使用了关系模式 . 例如：社交图（具有关系树的配置文件），邻近点（基于GeoJSON的邻近搜索），分类列表等 .

    关系模式也更容易更新和维护，因为实体存储在单个文档中 .

    回复于

相关问题