Я использовал N1QL для чтения данных из моей базы данных couchbase и столкнулся с очень плохой производительностью. Я работаю с views 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
}
}
Это было сделано с 4000×5 записей.
«Коллекция» — это то, что я называю «тип».
В запросе используется order by, а механизм запросов должен извлечь все записи и отсортировать их перед возвратом документов, даже если предельное значение невелико, поскольку для этого требуется время.
Какой тип тайм-аута вы видите. Это из индексатора или запроса. Не могли бы вы опубликовать сообщение о тайм-ауте.
В 4.5.0 этот тип запросов работает намного лучше.
Других решений пока нет …