Плохая производительность N1QL

Question

Я использовал N1QL для чтения данных с моего db couchbase и столкнулся с очень плохими характеристиками. Я работаю с представлениями atm, но если у кого-то есть идея, почему это происходит, я рад узнать, и, возможно, я вернусь к N1QL. В то время как разбиение на страницы очень медленное с 2M-записями (но работает), разбитый на страницы поисковый запрос выдает @ 2M записей. Couchbase CE 4.1.0

Вот запрос:

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 записей.

«Коллекция» - это то, что я называю «типом».

Answer 1

Запрос использует механизм запросов и запросов для извлечения всех записей и сортировки перед возвратом документов, даже если предельное значение невелико, из-за этого требуется время.

Какой вид времени вы видите. Это от индексатора или запроса. Не могли бы вы отправить сообщение с таймаутом.

В 4.5.0 этот тип запросов выполняется намного лучше.