ndb.OR使查询成本更高 [英] ndb.OR makes query costs more

问题描述

使用AppEngine appstats，我对查询进行了概要分析，并注意到尽管文档说查询一次读取一次，但使用ndb.OR(或扩展为OR的.IN)进行查询，却要花费n次读取(n等于OR子句的数量) ).

Using AppEngine appstats I profiled my queries, and noticed that although the docs say a query costs one read, queries using ndb.OR (or .IN which expands to OR), cost n reads (n equals the number of OR clauses).

例如:

votes = (Vote.query(ndb.OR(Vote.object == keys[0], Vote.object == keys[1]))
     .filter(Vote.user_id == user_id)
     .fetch(keys_only=True))

此查询的读取次数为2(与0个实体匹配).如果我将Ndb.OR替换为Vote.object.IN，则读取的次数等于我传递给读取的数组的长度.

This query costs 2 reads (it matches 0 entities). If I replace the ndb.OR with Vote.object.IN, the number of reads equals the length of array I pass to read.

这种行为与文档相矛盾.

This behavior is kind of contradicts the docs.

我想知道是否还有其他人经历过同样的事情，这是否是AE，文档或我的理解中的错误.

I was wondering if anyone else experienced the same, and if this is a bug in AE, docs, or my understanding.

谢谢.

推荐答案

ndb的查询文档不是特别明确，但此段是您的最佳答案

The query docs for ndb are not particularly explicit but this paragraph is your best answer

除了本机运算符外，API还支持！=运算符， 使用布尔或"运算和IN组合过滤器组 操作，测试是否与可能值列表之一相等 (例如Python的"in"运算符).这些操作不会将1:1映射到 数据存储的本机操作；因此它们有点古怪而缓慢 相对地.它们是使用内存中的结果合并来实现的 流.注意，将p！＝ v实现为"p ＜v或p＞ v". (这 对于重复属性很重要.)

In addition to the native operators, the API supports the != operator, combining groups of filters using the Boolean OR operation, and the IN operation, which test for equality to one of a list of possible values (like Python's 'in' operator). These operations don't map 1:1 to the Datastore's native operations; thus they are a little quirky and slow, relatively. They are implemented using in-memory merging of result streams. Note that p != v is implemented as "p < v OR p > v". (This matters for repeated properties.)

在此文档中 https://developers.google.com/appengine/docs/python/ndb/queries

这篇关于ndb.OR使查询成本更高的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！