0

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

这以前在我们创建的视图中运行良好，但现在我们被要求使用 Cloudant 查询选择器来做同样的事情。

我们提出了下面的解决方案，其中包含了可以找到文档引用的所有可能路径。查询是动态生成的，以包含“外键”引用的所有可能路径，但这意味着它需要扩展到潜在的 +100 个唯一路径（即，$or 运算符数组可能以 +100 个项目结束）

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

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

2 回答 2

1

那么，让我来做对了——您之前使用视图进行简单查找，效果很好，高效且易于验证，但您被要求创建一个包含数百个子句的 CQ 选择器？

为什么？这简直是​​疯了。这是视图的工作。

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

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

于 2018-01-15T14:59:20.817 回答
0

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

于 2018-02-06T17:28:47.967 回答