首页 文章

Cosmos DB：如何使用DocumentDB API在单独的集合中引用文档

提问于
浏览 次
3

我是使用DocumentDB API的Azure Cosmos DB的新手 . 我计划对我的数据建模，以便一个文档引用另一个文档 . 这很简单，如Modeling document data中所述 . 但是，我还想将相关文档分成不同的集合（这个决定与数据如何partitioned有关） .

Edit 7/24/2017 ：回应一条评论，想知道为什么我选择使用单独的集合：单独集合的推理主要归结为分区键和读/写优先级 . 由于需要在集合中的所有文档中存在某个分区键，因此将所选分区键不属于的文档分开是有意义的 . 在对权重进行了大量权衡之后，我决定使用的分区密钥是一种可以优化写入速度并在分片间均匀分布数据的分区密钥 - 但不幸的是，它在逻辑上并不属于我的"Metadata"文档 . 由于元数据和测量之间存在一对一的关系，我选择在测量中使用对元数据的引用而不是嵌入 . 并且因为很少（或永远）不会将元数据附加到每个测量中，所以我认为额外往返DB的费用非常低 .

由于引用是一个未经数据库验证的“弱链接”，是否可以并且明智地存储其他信息，例如集合名称？也就是说，我们可以使用一种路径而不是只有一个字符串id？

Metadata document in collection "Metadata":
{
  "id": "metadata1",
  ...
}

Measurement document in collection "Measurements":
{
  "id": "measurement1",
  "metadata-id" : "../Metadata/metadata1",
  ...
}

然后，当我解析我的应用程序/脚本中的数据时，我知道要查询的集合和文档 .

最后，我假设有其他/更好的方法可以解决这个问题，我欢迎您的建议（例如下划线，而不是斜线;使用符号来表示集合，如$ Metadata;等等） . 或者，我使用的关系跨越集合代码气味？

谢谢！

Edit ：对于downvoter，你能解释一下你的推理吗？我的问题是不知情的，不清楚的，还是没有用的？为什么？

azure azure-cosmosdb

2 回答

  • 2

    你必须在每个收集级别收费，因此必须这样做 . 你应该做的是选择一个更通用的分区键 . 像 key 或 partitionKey 之类的东西 . 这里的权衡是你_2790846好的） . 您可以继续使用您最初为测量文档选择的值，并为元数据文档设置不同的值 .

    我对有效和大规模使用宇宙的最大误解之一 . 在许多Cosmos示例中，他们谈论选择像 deviceId 或 postal code 这样的partitionKey并不意味着你正在处理同类文档 .

    请参考我回答的关于homogeneous vs heterogeneous in documentdb的这个问题 . 这种模式的最大争论是在Cosmos中添加了新的Graph API，这需要在单个集合中包含许多不同的实体，并且完全支持您将成为所有适用于所有文档的单个属性的用例 . 分区键，这就是你需要通用的原因 .

    回复于
  • 1

    你要做的是可行的 . 您使用的约定并不是特别重要，只要您可以找出参考 . 但请记住，使用这种类型的“关系”会相当慢，因为您需要从一个集合中获取所有文档，然后在单独的查询中获取相关文档 . 它会对您的应用程序产生严重影响 .

    另一种可能性是优化您的数据以供阅读：您可以将元数据文档嵌入到其他文档中 . 您的数据将被复制，因此如果您更新这些文档，则必须在两个集合中更新它们，但您可能写的频率低于您阅读的频率（可能，如果不是这样，则此设置会更糟） .

    您的文档如下所示：

    Metadata document in collection "Metadata":
{
  "id": "metadata1",
  ...
}

Measurement document in collection "Measurements":
{
  "id": "measurement1",
  "metadata" : {
      "id": "metadata1",
      ...
  },
  ...
}
    回复于

相关问题