不良的N1QL性能

我使用N1QL从我的couchbase数据库读取数据，并遇到非常糟糕的表现。我正在处理atm的观点，但如果有人知道为什么发生这种情况，我很高兴知道，也许我会回到N1QL。尽管2M记录（但有效）的分页速度很慢，但分页搜索超过了2M记录。 Couchbase CE 4.1.0不良的N1QL性能

下面是该查询：

public static function findByPage($recordsPerPage, $page) { 
     $query = CouchbaseN1qlQuery::fromString('SELECT * FROM `public_portal` WHERE `collection`=$collection ORDER BY `_id` LIMIT $limit OFFSET $offset'); 
     $query->options['$collection'] = static::COLLECTION_NAME;  
     $query->options['$limit'] = $recordsPerPage;   
     $query->options['$offset'] = $recordsPerPage*($page-1);  
     return self::doQueryAndGetObjects($query); 
    }

的指标：

CREATE INDEX `public_portal_collection` ON `public_portal`(`collection`) USING GSI; 

CREATE INDEX `public_portal_id` ON `public_portal`(`_id`) USING GSI;

我解释：

cbq> EXPLAIN SELECT * FROM `public_portal` WHERE `collection`="tree" ORDER BY `_id` LIMIT 24 OFFSET 24; 
{ 
    "requestID": "ab6df326-8f33-48b6-84a4-c22ac394f803", 
    "signature": "json", 
    "results": [ 
     { 
      "#operator": "Sequence", 
      "~children": [ 
       { 
        "#operator": "Sequence", 
        "~children": [ 
         { 
          "#operator": "IndexScan", 
          "index": "public_portal_collection", 
          "keyspace": "public_portal", 
          "namespace": "default", 
          "spans": [ 
           { 
            "Range": { 
             "High": [ 
              "\"tree\"" 
             ], 
             "Inclusion": 3, 
             "Low": [ 
              "\"tree\"" 
             ] 
            } 
           } 
          ], 
          "using": "gsi" 
         }, 
         { 
          "#operator": "Parallel", 
          "~child": { 
           "#operator": "Sequence", 
           "~children": [ 
            { 
             "#operator": "Fetch", 
             "keyspace": "public_portal", 
             "namespace": "default" 
            }, 
            { 
             "#operator": "Filter", 
             "condition": "((`public_portal`.`collection`) = \"tree\")" 
            }, 
            { 
             "#operator": "InitialProject", 
             "result_terms": [ 
              { 
               "expr": "self", 
               "star": true 
              } 
             ] 
            } 
           ] 
          } 
         } 
        ] 
       }, 
       { 
        "#operator": "Order", 
        "sort_terms": [ 
         { 
          "expr": "(`public_portal`.`_id`)" 
         } 
        ] 
       }, 
       { 
        "#operator": "Offset", 
        "expr": "24" 
       }, 
       { 
        "#operator": "Limit", 
        "expr": "24" 
       }, 
       { 
        "#operator": "FinalProject" 
       } 
      ] 
     } 
    ], 
    "status": "success", 
    "metrics": { 
     "elapsedTime": "6.755603ms", 
     "executionTime": "6.573912ms", 
     "resultCount": 1, 
     "resultSize": 2972 
    } 
}

这与4000x5记录完成的。

“收集”就是我所说的“类型”。

来源

2016-07-27 Mattia_98

查询使用order by和查询引擎需要在返回文档之前获取所有记录并进行排序，即使限制值很小，因为它需要时间。

你看到什么类型的时间。它来自索引器还是查询。你能发布超时消息吗？

在4.5.0中，这种类型的查询性能要好得多。

来源

2016-07-27 16:51:25 vsr

由于某种原因，它不再超时，它只是不返回任何内容。如果没有ORDER BY，它会快一点，但我需要它。我会等4.5.0。 –

不良的N1QL性能

回答

相关问题