couchbase не возвращает некоторые документы при использовании определенного индекса - PullRequest
0 голосов
/ 01 января 2019

В результате проведенных мною тестов создается впечатление, что это конкретно большие документы (~ 2 МБ), и когда запрос использует определенные индексы (в моем случае индекс массива).
Кажется, что все работает нормально, когда документменьше.
Это происходит либо на панели управления Couchbase, либо в cbq, либо в scala SDK, который я использую.
Я использую Couchbase 4.6.0 с Индексы, оптимизированные для памяти .


У меня есть следующие индексы, относящиеся к этому запросу:

CREATE INDEX `cache_partial_specific`
ON `content`(`docType`,`entityType`,`entityId`) 
WHERE (`docType` = "feedCachePartial") WITH { "defer_build"=true }  

CREATE INDEX `feed_cache_partial_meta`
ON `content`(`meta().id`)
WHERE (`docType` = `feedCachePartial`)  

CREATE INDEX `cache_partial_index`
ON `content`((distinct (array (`url`.`id`) for `url` in `urls` end)))
WHERE (`docType` = "feedCachePartial") WITH { "defer_build"=true }

Последний вызывает проблемы


Проблема:

Например, при запуске
SELECT * FROM content WHERE meta().id = 'cached:topic:297:grp:all'

или

SELECT * FROM content WHERE docType='feedCachePartial' AND entityId=297 and entityType='topic'

он возвращает документы, и я вижу URL 13319 в списке или URL-адресах.

Но при работе

SELECT * FROM content
WHERE docType='feedCachePartial'
AND ANY url IN urls SATISFIES url.id = 13119 END

или любой вариации с условием ANY url IN urls SATISFIES url.id = 13119

документ cached:topic:297:grp:all не возвращается.


max_indexer_doc_size установлен на 20 МБ, поэтому я считаю, что это не проблема (и в любом случае он возвращается при использовании других индексов).

При просмотре журнала запросов я вижу, что этот конкретный индекс, который я использую, имеет 1 реплику (у меня всего 3 узла индекса в этом кластере).


Я бы исследовалэтот индекс и посмотреть, какие документы изменить размер индекса, но я не знаю, как это сделать.

Ответы [ 2 ]

0 голосов
/ 02 января 2019

Проверьте ваш indexer.log и посмотрите, не пропустил ли конкретный индекс ключ документа из-за ограничений размера ключа индекса. Если индекс не проиндексирован, запрос не найдет этот документ.Если вы уже знаете, что ключ документа и запрос не покрыты, лучшим вариантом будет указание USE KEYS и удаление предиката META (). Id, что экономит время.

Поскольку ваши документы большие и пытаются выполнить индексацию ARRAY, возможно, они пропущены.Если вы знаете ключ документа, нет необходимости в Array Index напрямую извлекать документ с помощью USE KEYS и применять предикаты.Если документ пропущен из-за ограничения размера, проверьте этот пост https://forums.couchbase.com/t/how-to-read-max-array-seckey-size-setting-version-4-5-1-2844-community-edition-build-2844/16374

SELECT * FROM content USE KEYS "cached:topic:297:grp:all" WHERE .... 

Если вы не выполняете поиск по META (). Id (пример: META (). Id LIKE "xyz%") feed_cache_partial_meta indexможет не быть полезным.Вы можете использовать USE KEYS.

Если документы маленькие, вы можете объединить другие индексы, как это, и посмотреть, работает ли он, и избегать Intersectscans.

CREATE INDEX `cache_partial_index`
ON `content`(`docType`,`entityType`,`entityId`, DISTINCT ARRAY url.id FOR url IN urls END)
WHERE (`docType` = "feedCachePartial") WITH { "defer_build"=true };

В следующих блогах есть полезная информация

https://blog.couchbase.com/create-right-index-get-right-performance/ https://blog.couchbase.com/n1ql-practical-guide-second-edition/

0 голосов
/ 02 января 2019

Хорошо, я просто приму здесь простейшее предположение, но в этом запросе

SELECT * FROM content
where docType='feedCachePartial'
and meta().id = 'cached:topic:297:grp:all'
AND entityId=297
and entityType='topic'
AND ANY url IN c.urls SATISFIES url.id = 13119 END

правильна ли буква "c" в "c.urls"?Или в первой строке должно быть написано SELECT * FROM content c?

...