Mixing
couchbase not returning some documents when using specific index
By the tests I made, it seems that these are specifically large documents (~2mb) and when the query uses specific indexes (in my case an array index).
It seems to be working ok when the document is smaller.
This happens either in Couchbase dashboard, cbq or the scala SDK i'm using.
I'm using Couchbase 4.6.0 with Memory optimized indexes.
I have these indexes relevant to this query:
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 }
The last is the one causing troubles
The problem:
For example When runningSELECT * FROM content WHERE meta().id = 'cached:topic:297:grp:all'
or
SELECT * FROM content WHERE docType='feedCachePartial' AND entityId=297 and entityType='topic'
it returns the documents and I see the url 13319 in the list or urls.
But when running
SELECT * FROM content
WHERE docType='feedCachePartial'
AND ANY url IN urls SATISFIES url.id = 13119 END
or any variation with the condition ANY url IN urls SATISFIES url.id = 13119
the document cached:topic:297:grp:all is not returned.
The max_indexer_doc_size is set to 20 MB so I believe this is not the issue (and either way it is being returned when using the other indexes).
When viewing the query log I see that this specific index i'm using has 1 replica (I have total of 3 index nodes on this cluster).
I would have investigate this index and see which documents resize on the index but I don't know how to do that.
couchbase n1ql
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
|
show 3 more comments
By the tests I made, it seems that these are specifically large documents (~2mb) and when the query uses specific indexes (in my case an array index).
It seems to be working ok when the document is smaller.
This happens either in Couchbase dashboard, cbq or the scala SDK i'm using.
I'm using Couchbase 4.6.0 with Memory optimized indexes.
I have these indexes relevant to this query:
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 }
The last is the one causing troubles
The problem:
For example When runningSELECT * FROM content WHERE meta().id = 'cached:topic:297:grp:all'
or
SELECT * FROM content WHERE docType='feedCachePartial' AND entityId=297 and entityType='topic'
it returns the documents and I see the url 13319 in the list or urls.
But when running
SELECT * FROM content
WHERE docType='feedCachePartial'
AND ANY url IN urls SATISFIES url.id = 13119 END
or any variation with the condition ANY url IN urls SATISFIES url.id = 13119
the document cached:topic:297:grp:all is not returned.
The max_indexer_doc_size is set to 20 MB so I believe this is not the issue (and either way it is being returned when using the other indexes).
When viewing the query log I see that this specific index i'm using has 1 replica (I have total of 3 index nodes on this cluster).
I would have investigate this index and see which documents resize on the index but I don't know how to do that.
couchbase n1ql
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
Not sure if this is related, but I'm a little confused why your last query would be checking anything other than the document key. Since you know the key, why add the other conditions?
– Matthew Groves
Jan 1 at 21:02
Have you checked that the problem is the index and not the query? If you just have the primary index, does the query return the correct answer slowly?
– Johan Larson
Jan 1 at 23:48
Also, you only need the back-ticks when you are using names with weird characters, like -+%$. I think you could remove the back-ticks in all the statements above.
– Johan Larson
Jan 1 at 23:57
@MatthewGroves that was a misprint, I edited it. Thanks
– Achi Even-dar
Jan 2 at 9:41
@JohanLarson What do you refer to by "primary index"? I have 3 GSI indexes related to this query (urls.id, meta().id, docType), on all of it's different variations. Only when i'm using the index on urls.id I don't get the expected result. And I'm not using back-ticks as far as I am aware, i'm using single quotes.
– Achi Even-dar
Jan 2 at 10:16
|
show 3 more comments
By the tests I made, it seems that these are specifically large documents (~2mb) and when the query uses specific indexes (in my case an array index).
It seems to be working ok when the document is smaller.
This happens either in Couchbase dashboard, cbq or the scala SDK i'm using.
I'm using Couchbase 4.6.0 with Memory optimized indexes.
I have these indexes relevant to this query:
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 }
The last is the one causing troubles
The problem:
For example When runningSELECT * FROM content WHERE meta().id = 'cached:topic:297:grp:all'
or
SELECT * FROM content WHERE docType='feedCachePartial' AND entityId=297 and entityType='topic'
it returns the documents and I see the url 13319 in the list or urls.
But when running
SELECT * FROM content
WHERE docType='feedCachePartial'
AND ANY url IN urls SATISFIES url.id = 13119 END
or any variation with the condition ANY url IN urls SATISFIES url.id = 13119
the document cached:topic:297:grp:all is not returned.
The max_indexer_doc_size is set to 20 MB so I believe this is not the issue (and either way it is being returned when using the other indexes).
When viewing the query log I see that this specific index i'm using has 1 replica (I have total of 3 index nodes on this cluster).
I would have investigate this index and see which documents resize on the index but I don't know how to do that.
couchbase n1ql
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
By the tests I made, it seems that these are specifically large documents (~2mb) and when the query uses specific indexes (in my case an array index).
It seems to be working ok when the document is smaller.
This happens either in Couchbase dashboard, cbq or the scala SDK i'm using.
I'm using Couchbase 4.6.0 with Memory optimized indexes.
I have these indexes relevant to this query:
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 }
The last is the one causing troubles
The problem:
For example When runningSELECT * FROM content WHERE meta().id = 'cached:topic:297:grp:all'
or
SELECT * FROM content WHERE docType='feedCachePartial' AND entityId=297 and entityType='topic'
it returns the documents and I see the url 13319 in the list or urls.
But when running
SELECT * FROM content
WHERE docType='feedCachePartial'
AND ANY url IN urls SATISFIES url.id = 13119 END
or any variation with the condition ANY url IN urls SATISFIES url.id = 13119
the document cached:topic:297:grp:all is not returned.
The max_indexer_doc_size is set to 20 MB so I believe this is not the issue (and either way it is being returned when using the other indexes).
When viewing the query log I see that this specific index i'm using has 1 replica (I have total of 3 index nodes on this cluster).
I would have investigate this index and see which documents resize on the index but I don't know how to do that.
couchbase n1ql
couchbase n1ql
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
edited Jan 2 at 10:10
Achi Even-dar
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
asked Jan 1 at 17:57
Achi Even-darAchi Even-dar
1141315
1141315
Not sure if this is related, but I'm a little confused why your last query would be checking anything other than the document key. Since you know the key, why add the other conditions?
– Matthew Groves
Jan 1 at 21:02
Have you checked that the problem is the index and not the query? If you just have the primary index, does the query return the correct answer slowly?
– Johan Larson
Jan 1 at 23:48
Also, you only need the back-ticks when you are using names with weird characters, like -+%$. I think you could remove the back-ticks in all the statements above.
– Johan Larson
Jan 1 at 23:57
@MatthewGroves that was a misprint, I edited it. Thanks
– Achi Even-dar
Jan 2 at 9:41
@JohanLarson What do you refer to by "primary index"? I have 3 GSI indexes related to this query (urls.id, meta().id, docType), on all of it's different variations. Only when i'm using the index on urls.id I don't get the expected result. And I'm not using back-ticks as far as I am aware, i'm using single quotes.
– Achi Even-dar
Jan 2 at 10:16
|
show 3 more comments
Not sure if this is related, but I'm a little confused why your last query would be checking anything other than the document key. Since you know the key, why add the other conditions?
– Matthew Groves
Jan 1 at 21:02
Have you checked that the problem is the index and not the query? If you just have the primary index, does the query return the correct answer slowly?
– Johan Larson
Jan 1 at 23:48
Also, you only need the back-ticks when you are using names with weird characters, like -+%$. I think you could remove the back-ticks in all the statements above.
– Johan Larson
Jan 1 at 23:57
@MatthewGroves that was a misprint, I edited it. Thanks
– Achi Even-dar
Jan 2 at 9:41
@JohanLarson What do you refer to by "primary index"? I have 3 GSI indexes related to this query (urls.id, meta().id, docType), on all of it's different variations. Only when i'm using the index on urls.id I don't get the expected result. And I'm not using back-ticks as far as I am aware, i'm using single quotes.
– Achi Even-dar
Jan 2 at 10:16
Not sure if this is related, but I'm a little confused why your last query would be checking anything other than the document key. Since you know the key, why add the other conditions?
– Matthew Groves
Jan 1 at 21:02
Not sure if this is related, but I'm a little confused why your last query would be checking anything other than the document key. Since you know the key, why add the other conditions?
– Matthew Groves
Jan 1 at 21:02
Have you checked that the problem is the index and not the query? If you just have the primary index, does the query return the correct answer slowly?
– Johan Larson
Jan 1 at 23:48
Have you checked that the problem is the index and not the query? If you just have the primary index, does the query return the correct answer slowly?
– Johan Larson
Jan 1 at 23:48
Also, you only need the back-ticks when you are using names with weird characters, like -+%$. I think you could remove the back-ticks in all the statements above.
– Johan Larson
Jan 1 at 23:57
Also, you only need the back-ticks when you are using names with weird characters, like -+%$. I think you could remove the back-ticks in all the statements above.
– Johan Larson
Jan 1 at 23:57
@MatthewGroves that was a misprint, I edited it. Thanks
– Achi Even-dar
Jan 2 at 9:41
@MatthewGroves that was a misprint, I edited it. Thanks
– Achi Even-dar
Jan 2 at 9:41
@JohanLarson What do you refer to by "primary index"? I have 3 GSI indexes related to this query (urls.id, meta().id, docType), on all of it's different variations. Only when i'm using the index on urls.id I don't get the expected result. And I'm not using back-ticks as far as I am aware, i'm using single quotes.
– Achi Even-dar
Jan 2 at 10:16
@JohanLarson What do you refer to by "primary index"? I have 3 GSI indexes related to this query (urls.id, meta().id, docType), on all of it's different variations. Only when i'm using the index on urls.id I don't get the expected result. And I'm not using back-ticks as far as I am aware, i'm using single quotes.
– Achi Even-dar
Jan 2 at 10:16
|
show 3 more comments
2 Answers
2
active
oldest
votes
Check your indexer.log and see if the specific index is skipped your document key due to index key size limitations.If the index is not indexed query will not find that document. If you already know the document key and query is not covered best option will be specifying USE KEYS and removing META().id predicate this saves time.
As your documents are large and trying to do ARRAY indexing it might have skipped. If you know document key no need to Array Index directly fetch the document with USE KEYS and apply predicates. If document is skipped due to size limitation check this post 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 ....
Unless you are doing Search on META().id (example: META().id LIKE "xyz%") feed_cache_partial_meta index may not be useful. You can use USE KEYS.
If documents are small, you can combine the other indexes like this and see if it works and avoid 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 };
The following blogs has useful info
https://blog.couchbase.com/create-right-index-get-right-performance/
https://blog.couchbase.com/n1ql-practical-guide-second-edition/
answered Jan 2 at 19:00
vsrvsr
1,49634
Thanks. That was indeed the problem. Do you know the reason for this max_array_seckey_size limit? Why does it have a limit specifically for arrays? Is it because arrays are more likely to consume high RAM? Should I hesitate to change it to a bigger number (e.g 1GB)?
– Achi Even-dar
Jan 9 at 18:38
If the keysize is bigger size of index record is bigger which impacts performance. You should try with latest version of CB which has been relaxed this restriction.
– vsr
Jan 10 at 19:10
add a comment |
OK, I'll just take my simplest guess here, but in this query
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
is the "c" in the "c.urls" correct? Or should the first line say SELECT * FROM content c?
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
That was a misprint, I edited it now with the fixed query
– Achi Even-dar
Jan 2 at 9:42
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53997684%2fcouchbase-not-returning-some-documents-when-using-specific-index%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Check your indexer.log and see if the specific index is skipped your document key due to index key size limitations.If the index is not indexed query will not find that document. If you already know the document key and query is not covered best option will be specifying USE KEYS and removing META().id predicate this saves time.
As your documents are large and trying to do ARRAY indexing it might have skipped. If you know document key no need to Array Index directly fetch the document with USE KEYS and apply predicates. If document is skipped due to size limitation check this post 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 ....
Unless you are doing Search on META().id (example: META().id LIKE "xyz%") feed_cache_partial_meta index may not be useful. You can use USE KEYS.
If documents are small, you can combine the other indexes like this and see if it works and avoid 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 };
The following blogs has useful info
https://blog.couchbase.com/create-right-index-get-right-performance/
https://blog.couchbase.com/n1ql-practical-guide-second-edition/
answered Jan 2 at 19:00
vsrvsr
1,49634
Thanks. That was indeed the problem. Do you know the reason for this max_array_seckey_size limit? Why does it have a limit specifically for arrays? Is it because arrays are more likely to consume high RAM? Should I hesitate to change it to a bigger number (e.g 1GB)?
– Achi Even-dar
Jan 9 at 18:38
If the keysize is bigger size of index record is bigger which impacts performance. You should try with latest version of CB which has been relaxed this restriction.
– vsr
Jan 10 at 19:10
add a comment |
Check your indexer.log and see if the specific index is skipped your document key due to index key size limitations.If the index is not indexed query will not find that document. If you already know the document key and query is not covered best option will be specifying USE KEYS and removing META().id predicate this saves time.
As your documents are large and trying to do ARRAY indexing it might have skipped. If you know document key no need to Array Index directly fetch the document with USE KEYS and apply predicates. If document is skipped due to size limitation check this post 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 ....
Unless you are doing Search on META().id (example: META().id LIKE "xyz%") feed_cache_partial_meta index may not be useful. You can use USE KEYS.
If documents are small, you can combine the other indexes like this and see if it works and avoid 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 };
The following blogs has useful info
https://blog.couchbase.com/create-right-index-get-right-performance/
https://blog.couchbase.com/n1ql-practical-guide-second-edition/
answered Jan 2 at 19:00
vsrvsr
1,49634
Thanks. That was indeed the problem. Do you know the reason for this max_array_seckey_size limit? Why does it have a limit specifically for arrays? Is it because arrays are more likely to consume high RAM? Should I hesitate to change it to a bigger number (e.g 1GB)?
– Achi Even-dar
Jan 9 at 18:38
If the keysize is bigger size of index record is bigger which impacts performance. You should try with latest version of CB which has been relaxed this restriction.
– vsr
Jan 10 at 19:10
add a comment |
Check your indexer.log and see if the specific index is skipped your document key due to index key size limitations.If the index is not indexed query will not find that document. If you already know the document key and query is not covered best option will be specifying USE KEYS and removing META().id predicate this saves time.
As your documents are large and trying to do ARRAY indexing it might have skipped. If you know document key no need to Array Index directly fetch the document with USE KEYS and apply predicates. If document is skipped due to size limitation check this post 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 ....
Unless you are doing Search on META().id (example: META().id LIKE "xyz%") feed_cache_partial_meta index may not be useful. You can use USE KEYS.
If documents are small, you can combine the other indexes like this and see if it works and avoid 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 };
The following blogs has useful info
https://blog.couchbase.com/create-right-index-get-right-performance/
https://blog.couchbase.com/n1ql-practical-guide-second-edition/
answered Jan 2 at 19:00
vsrvsr
1,49634
Check your indexer.log and see if the specific index is skipped your document key due to index key size limitations.If the index is not indexed query will not find that document. If you already know the document key and query is not covered best option will be specifying USE KEYS and removing META().id predicate this saves time.
As your documents are large and trying to do ARRAY indexing it might have skipped. If you know document key no need to Array Index directly fetch the document with USE KEYS and apply predicates. If document is skipped due to size limitation check this post 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 ....
Unless you are doing Search on META().id (example: META().id LIKE "xyz%") feed_cache_partial_meta index may not be useful. You can use USE KEYS.
If documents are small, you can combine the other indexes like this and see if it works and avoid 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 };
The following blogs has useful info
https://blog.couchbase.com/create-right-index-get-right-performance/
https://blog.couchbase.com/n1ql-practical-guide-second-edition/
answered Jan 2 at 19:00
vsrvsr
1,49634
edited Jan 2 at 22:39
answered Jan 2 at 19:00
vsrvsr
1,49634
answered Jan 2 at 19:00
vsrvsr
1,49634
answered Jan 2 at 19:00
vsrvsr
1,49634
1,49634
Thanks. That was indeed the problem. Do you know the reason for this max_array_seckey_size limit? Why does it have a limit specifically for arrays? Is it because arrays are more likely to consume high RAM? Should I hesitate to change it to a bigger number (e.g 1GB)?
– Achi Even-dar
Jan 9 at 18:38
If the keysize is bigger size of index record is bigger which impacts performance. You should try with latest version of CB which has been relaxed this restriction.
– vsr
Jan 10 at 19:10
add a comment |
Thanks. That was indeed the problem. Do you know the reason for this max_array_seckey_size limit? Why does it have a limit specifically for arrays? Is it because arrays are more likely to consume high RAM? Should I hesitate to change it to a bigger number (e.g 1GB)?
– Achi Even-dar
Jan 9 at 18:38
If the keysize is bigger size of index record is bigger which impacts performance. You should try with latest version of CB which has been relaxed this restriction.
– vsr
Jan 10 at 19:10
Thanks. That was indeed the problem. Do you know the reason for this max_array_seckey_size limit? Why does it have a limit specifically for arrays? Is it because arrays are more likely to consume high RAM? Should I hesitate to change it to a bigger number (e.g 1GB)?
– Achi Even-dar
Jan 9 at 18:38
Thanks. That was indeed the problem. Do you know the reason for this max_array_seckey_size limit? Why does it have a limit specifically for arrays? Is it because arrays are more likely to consume high RAM? Should I hesitate to change it to a bigger number (e.g 1GB)?
– Achi Even-dar
Jan 9 at 18:38
If the keysize is bigger size of index record is bigger which impacts performance. You should try with latest version of CB which has been relaxed this restriction.
– vsr
Jan 10 at 19:10
If the keysize is bigger size of index record is bigger which impacts performance. You should try with latest version of CB which has been relaxed this restriction.
– vsr
Jan 10 at 19:10
add a comment |
OK, I'll just take my simplest guess here, but in this query
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
is the "c" in the "c.urls" correct? Or should the first line say SELECT * FROM content c?
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
That was a misprint, I edited it now with the fixed query
– Achi Even-dar
Jan 2 at 9:42
add a comment |
OK, I'll just take my simplest guess here, but in this query
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
is the "c" in the "c.urls" correct? Or should the first line say SELECT * FROM content c?
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
That was a misprint, I edited it now with the fixed query
– Achi Even-dar
Jan 2 at 9:42
add a comment |
OK, I'll just take my simplest guess here, but in this query
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
is the "c" in the "c.urls" correct? Or should the first line say SELECT * FROM content c?
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
OK, I'll just take my simplest guess here, but in this query
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
is the "c" in the "c.urls" correct? Or should the first line say SELECT * FROM content c?
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
answered Jan 2 at 0:03
Johan LarsonJohan Larson
1,3731813
1,3731813
That was a misprint, I edited it now with the fixed query
– Achi Even-dar
Jan 2 at 9:42
add a comment |
That was a misprint, I edited it now with the fixed query
– Achi Even-dar
Jan 2 at 9:42
That was a misprint, I edited it now with the fixed query
– Achi Even-dar
Jan 2 at 9:42
That was a misprint, I edited it now with the fixed query
– Achi Even-dar
Jan 2 at 9:42
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53997684%2fcouchbase-not-returning-some-documents-when-using-specific-index%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Not sure if this is related, but I'm a little confused why your last query would be checking anything other than the document key. Since you know the key, why add the other conditions?
– Matthew Groves
Jan 1 at 21:02
Have you checked that the problem is the index and not the query? If you just have the primary index, does the query return the correct answer slowly?
– Johan Larson
Jan 1 at 23:48
Also, you only need the back-ticks when you are using names with weird characters, like -+%$. I think you could remove the back-ticks in all the statements above.
– Johan Larson
Jan 1 at 23:57
@MatthewGroves that was a misprint, I edited it. Thanks
– Achi Even-dar
Jan 2 at 9:41
@JohanLarson What do you refer to by "primary index"? I have 3 GSI indexes related to this query (urls.id, meta().id, docType), on all of it's different variations. Only when i'm using the index on urls.id I don't get the expected result. And I'm not using back-ticks as far as I am aware, i'm using single quotes.
– Achi Even-dar
Jan 2 at 10:16