【问题标题】:Individual datatsore query oder for large number of properties大量属性的单个数据存储查询顺序
【发布时间】:2016-11-02 12:16:24
【问题描述】:

我有一个拥有超过 25 个属性的实体。在这 25 个属性中,有 15 个属性显示在前端表中。这些表将允许对每个属性进行排序(ASC 和 DESC)。

为了在后端处理这个问题,我正在检查订单类型并针对 ASC 和 DESC 订单的每个属性编写查询。为了处理 15 条记录排序,我有很多看起来相似的行代码。唯一不同的是订单类型。

代码如下:

@classmethod
def retrieve(cls, order, limit, offset):
    if order == '-property_1':
        results = cls.query(ancestor=parent).order(-cls.property_1).fetch(limit, offset=offset)
    elif order == 'property_1':
        results = cls.query(ancestor=parent).order(cls.property_1).fetch(limit, offset=offset)
        .
        .
        .
        .
    elif order == '-property_15':
        results = cls.query(ancestor=parent).order(-cls.property_15).fetch(limit, offset=offset)
    elif order == 'property_15':
        results = cls.query(ancestor=parent).order(cls.property_15).fetch(limit, offset=offset)

并为每个属性创建 2 个数据存储索引。

- kind: EntityName
  ancestor: yes
  properties:
  - name: property_1

- kind: EntityName
  ancestor: yes
  properties:
  - name: property_1
    direction: desc

我的问题是有没有更好的方法来处理这种情况?

【问题讨论】:

    标签: python google-app-engine optimization query-optimization google-cloud-datastore


    【解决方案1】:

    不,您正在以正确的方式处理索引。

    如果您的数据规模较小且增长相对有限,如果您想避免创建 15*2 索引,则可以切换到客户端排序。

    或者,如果父母(实体组)的数量很少并且您可以最终保持一致,您可以省略祖先=父母子句并简单地在客户端中按父母进行过滤。这将使您能够使用属性的内置索引(两个顺序方向),而不需要复合索引。

    【讨论】:

    • 这个答案的第一行似乎在提倡不必要的重复代码;显然有更好的方法来做到这一点(见格雷格的回答)。
    • @ChrisC73 我只是在讨论索引/查询方面 - 我已经更新了第一行以反映这一点。
    • 同意;所需的潜在索引数量绝对是一个问题
    【解决方案2】:

    如果您传递的参数始终与您的属性名称匹配,那么您可以将 if 语句替换为以下内容:

    desc = False
    if order[0] == '-':
      order = order[1:]
      desc = True
    
    query = cls.query(ancestor=parent)
    order = getattr(cls, order)
    if desc:
      order = -order
    
    query = query.order(order)
    results = query.fetch(limit, offset=offset)
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2019-09-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多