【问题标题】:couchbase not returning some documents when using specific index使用特定索引时,couchbase 不返回某些文档
【发布时间】:2019-01-01 17:57:23
【问题描述】:

根据我所做的测试,这些似乎是特别大的文档(~2mb),并且当查询使用特定索引(在我的例子中是数组索引)时。
当文档较小时,它似乎工作正常。
这发生在 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'

它返回文档,我在列表或 urls 中看到 url 13319。

但是在运行的时候

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 MB,所以我相信这不是问题(无论哪种方式,在使用其他索引时都会返回)。

查看查询日志时,我看到我正在使用的这个特定索引有 1 个副本(我在这个集群上总共有 3 个索引节点)。


我会调查这个索引并查看哪些文档在索引上调整大小,但我不知道该怎么做。

【问题讨论】:

  • 不确定这是否相关,但我有点困惑,为什么您的最后一个查询会检查文档键以外的任何内容。既然知道key,为什么还要加上其他条件呢?
  • 您检查过问题是索引而不是查询吗?如果只有主索引,查询返回正确答案会不会很慢?
  • 另外,只有在使用带有奇怪字符的名称时才需要反引号,例如 -+%$。我认为您可以删除上述所有陈述中的反引号。
  • @MatthewGroves 这是一个印刷错误,我编辑了它。谢谢
  • @JohanLarson “主索引”指的是什么?我有 3 个与此查询相关的 GSI 索引(urls.id、meta().id、docType),它们都是不同的变体。只有当我在 urls.id 上使用索引时,我才没有得到预期的结果。据我所知,我没有使用反引号,我使用的是单引号。

标签: couchbase n1ql


【解决方案1】:

检查您的 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 索引可能没有用。您可以使用 USE KEYS。

如果文档很小,你可以像这样结合其他索引,看看它是否有效,避免交叉扫描。

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/

【讨论】:

  • 谢谢。这确实是问题所在。你知道这个 max_array_seckey_size 限制的原因吗?为什么它有专门针对数组的限制?是因为数组更可能消耗高内存吗?我是否应该犹豫将其更改为更大的数字(例如 1GB)?
  • 如果keysize越大,索引记录的大小就越大,这会影响性能。您应该尝试使用已放宽此限制的最新版 CB。
【解决方案2】:

好的,我在这里只做我最简单的猜测,但是在这个查询中

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.urls”中的“c”是否正确?还是第一行应该写SELECT * FROM content c

【讨论】:

  • 那是一个印刷错误,我现在用固定查询编辑它
猜你喜欢
  • 2020-03-07
  • 1970-01-01
  • 2021-12-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-08-19
相关资源
最近更新 更多