Question

在我们的系统中，我们需要知道数据库中是否存在对特定文档ID的引用。（例如允许/拒绝删除）

以前使用我们创建的视图工作正常，但现在我们被要求使用Cloudant查询选择器执行相同的操作。

我们提出了下面的解决方案，其中包含了可以找到文档参考的所有可能路径。动态生成查询以包括＆＃34;外键的所有可能路径＆＃34;参考，但这意味着它需要扩展到潜在的+100个唯一路径（即，$或运算符数组最终可能会有+100个项目）

我想知道这么大的查询是否会起作用以及潜在的性能影响。如果还有另一种我们想知道的方式。

{
   "selector": {
      "$or": [
         {
            "content": {
               "$elemMatch": {
                  "accounts": {
                     "$elemMatch": {
                        "bank": "bank12345"
                     }
                  }
               }
            }
         },
         {
            "content": {
               "$elemMatch": {
                  "partners": {
                     "$elemMatch": {
                        "someEntity": "someReference12345"
                     }
                  }
               }
            }
         }
      ]
   },
   "fields": [
      "_id",
      "_rev"
   ]
}

Answer 1

所以，让我做对了 - 你之前使用了一个视图进行简单的查找，效果很好，高效且易于验证，而且你被要求用数百个条款制作一个CQ选择器？

为什么呢？那太疯狂了。这是视图的工作。

暂时搁置一段时间，我假设您正在使用JSON索引。你的表现几乎肯定是非常糟糕的，顺便说一句。您需要为您希望能够查询的所有位预先创建索引，否则您最终可能会使用完整的数据库扫描而不是索引查找。

如果没有看到您的文件，就很难提供更多的通用建议。听起来您的文档很大，和/或包含您在最坏情况下随时间更新的数组。我想不出为什么你会考虑使用一个带有多个子句的选择器的任何其他似是而非的方式。您可以将partners数组拆分为单独的文档吗？

Answer 2

作为对此讨论的更新，我想报告我们测试了许多条件的Cloudant查询，并且执行只花了11毫秒，所以虽然这很多但我们仍然需要了解内部工作对于选择器，只要所有查询的字段都是索引而不会对性能产生重大影响，您似乎可以执行此类查询。但是因为这是一个简单的测试，所以不要引用我这个。 ;-)

Cloudant / Mango查询选择器大小限制

2 个答案: