2016-07-27 29 views
1

Ich habe N1QL verwendet, um Daten von meinem Couchbase db zu lesen, und stieß auf sehr schlechte Leistung. Ich arbeite mit Sichten atm, aber wenn jemand eine Idee hat, warum das passiert, bin ich glücklich zu wissen und vielleicht werde ich zurück zu N1QL gehen. Während die Paginierung bei 2M-Datensätzen sehr langsam ist (aber funktioniert), wird die paginierte Suche bei @ 2M-Datensätzen ausgemessen. Couchbase CE 4.1.0Bad N1QL Leistung

Hier ist die Abfrage:

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); 
    } 

Die Indizes:

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

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

Mein erklären:

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 
    } 
} 

Dies wurde mit 4000x5 Aufzeichnungen gemacht.

"Sammlung" ist, was ich "Typ" nenne.

Antwort

1

Die Abfrage verwendet Order by und Query Engine muss alle Datensätze abrufen und vor dem Zurücksenden von Dokumenten sortieren, obwohl der Grenzwert klein ist. Daher dauert es einige Zeit.

Welche Art von Zeitüberschreitung Sie sehen. Ist es von Indexer oder Abfrage. Könnten Sie die Zeitüberschreitungsnachricht posten?

In 4.5.0 führt diese Art von Abfragen viel besser.

+0

Aus irgendeinem Grund gibt es kein Timeout mehr, es gibt nur nichts zurück. Es ist ein bisschen schneller ohne ORDER BY, aber ich brauche es. Ich warte auf 4.5.0. –