不良的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性能

回答

相關問題