DocumentDB子查询的性能是否足以执行RDMS风格的连接？

Question

DocumentDB有它的长处。我想大多数人都会同意，在文档之间建立联系并不是这些优势之一。

根据我所读到的，常见的策略是保持数据尽可能的非规范化，以及在原始更改时更新非规范化数据的自定义逻辑。

但是，如果您的需要您的数据在某些地方标准化呢？假设我有，People，和一个人有一个FavorityIceCreamFlavor，它是IceCreamFlavor的id。

​

​

据我所知，如果我需要为这个人获取IceCreamFlavor，我需要运行第二个查询来获取IceCreamFlavor。

(单一收集文件b)

SELECT * FROM c c.id = "person-1"

{
  "firstName": "John",
  "lastname": "Doe",
  "favorityIceCreamFlavor": "icecream-4"
}

去拿冰淇淋味-

select * From c WHERE c.id = "icecream-4"

{
  "name": "Chocolate"
}

组合对象-

{
  "firstName": "John",
  "lastname": "Doe",
  "favorityIceCreamFlavor": {
     "name": "Chocolate"
   }
}

显然不理想，但如果我看的是个人资料，这并不是最坏的。此外，有了这种风格的文档存储(documentdb)，我可以创建存储过程，这样我就可以完成这个子查询服务器端。

但是，如果我是一个管理员，我想看到我所有的用户和他们最喜欢的冰淇淋呢？

​

​

这开始看起来像个问题。看起来我需要做11个子查询来获取每个用户的冰淇淋口味。

这可能只是一个文档存储无法有效处理的问题。但我在做这个假设-我不知道documentdb是如何工作的。

我是否应该关注documentdb对存储过程中的每个记录执行查询？

DocumentDB子查询执行得足够好，可以执行RDMS样式连接？

Answer 1

数据库需要执行两个查询才能完成连接。现在，它们都可以在缓存中，或者仅用于索引，在某些情况下也可以用于整个操作。而且，这项工作是在相同的内存空间中完成的，并且非常接近于数据，因此吞吐量约束不会发挥作用。

如果您可以在存储过程中同时执行这两项查询，那么DocumentDB/CosmosDB有非常接近的功能。只有当两个集位于同一个分区，并且它们可以在sproc超时之前(在大型数据库检索到的5K到20K文档之间发生)才能完成，但是如果可以使用存储过程，那么您就位于相同的内存空间中，并且非常接近数据。SQL联接与DocumentDB/CosmosDB sproc中的两次往返之间的延迟差异很小，在一个由100 k文档组成的数据库中，仅为1位数毫秒，在此数据库中，您的查询只会提取我估计的100个文档。

在查询中使用sprocs的另外几个缺点是：( 1)根据连接逻辑的复杂性，它可以消耗更多的RU；2) Sprocs单独执行，这会限制并发性，并降低系统的总体吞吐量。另一方面，即使其他不太强的一致性模型对非sproc查询有效，也可以保证ACID一致性。

如果由于上面讨论的原因不能使用sproc，那么在编写第二个查询之前，需要将数据拉回线路上进行第一个查询。在这种情况下，您将遇到吞吐量约束和额外的延迟。多少取决于很多参数。在DocumentDB/CosmosDB分区中使用与DocumentDB/CosmosDB分区相同的app服务器来保存数据将使其保持在最低限度，但即使这样也会带来损失。它的基数可能是毫秒不同的，但它将产生影响。如果你必须离开数据中心与第一轮，然后再组成第二轮，效果将更大。

每个应用程序都是不同的，但是对于典型的OLTP流量，我总是能够从DocumentDB中获得所需的性能。即使是繁重的分析负载也可以工作，特别是当您仔细选择分区键以获得足够的并行性时。我建议你试一试，一个简单的实验，接近你的最终产品，看看它是如何做到的。

希望这能有所帮助。