代码之家 › 专栏 › 技术社区 › riorio

couchbase按键获取和按索引选择的性能差异

couchbase indexing

riorio · 技术社区 · 7 年前

当我们在我们的 Couchbase DB,我们试着用他们的 id / key 并通过使用辅助索引的查询搜索项。

以下是关于 indexing and performance 在库奇基地,我们认为两人的表现将是一样的。

然而,在我们的测试中,我们发现有时 key/id 比使用二级索引的搜索快得多。

例如,使用索引搜索大约3ms,使用键搜索大约0.3ms。(这是10倍的系数)

关键是这种差异是不一致的。按键搜索的时间从0.3毫秒到15毫秒不等。

我们想知道:

按键搜索应该比按二级索引搜索有更好的性能?
关键字搜索之间应该有这样的时间差?

3 回复 | 直到 7 年前

deniswsrosa 7 年前

你得到的结果和我预期的一致。couchbase在使用id执行任何操作时都用作键值存储。键值存储大致是一个大的分布式hashmap,在这个数据结构中,使用id时可以获得非常好的get/save/delete性能。

无论何时存储新文档,couchbase都会散列密钥并为其分配一个虚拟bucket(类似于shard)。当您需要取回此文档时,它使用相同的算法来确定文档位于哪个虚拟存储桶中,因为sdk具有集群映射,并且知道哪个节点具有哪些碎片,所以您的应用程序将直接向拥有该文档的节点请求该文档。

另一方面,当您查询数据库时,couchbase必须在内部创建一个map/reduce来找出文档的位置,这就是为什么id操作更快的原因。

关于0.3ms到15ms结果的问题,如果不调试您的环境,很难分辨。然而,有许多因素可能会对其产生影响。例如:文档已缓存/未缓存、节点过小等。

EbenH 7 年前

要添加到@deniswrosa的答案中,第二个索引总是比较慢,因为首先必须根据查询遍历索引以查找文档密钥,然后执行密钥查找。如果您已经有了密钥,那么只进行密钥查找会更快。遍历索引的工作量可以根据索引的选择性、整个索引是否在内存中等而变化。内存优化索引可以确保整个索引在内存中,如果您有足够的内存来支持它。

当然,如果所讨论的文档不在缓存中,并且需要从存储器中放入内存,那么即使是简单的密钥查找也会比较慢。

Benjamin Bryant 7 年前

可以在scale上实现亚毫秒级的二次查找,但需要对查询、索引和couchbase的一些系统参数进行一些调整。考虑下面的简单示例:

用户桶中的示例文档:

“用户::000000000001”:{ “email”:“benjamin1@couchbase.com”, “用户ID”:“000000000001” }

此查询:

选择用户ID 从用户桶在哪里? 电子邮件=“benjamin1@couchbase.com” 用户id不为空 ;

…应该能够通过适当调整的二级索引实现亚毫秒的性能:

在userbucket上创建索引idx01(email,userid);

由于索引完全覆盖了查询,因此查询引擎不需要从k/v存储中获取文档。但是“select*…”总是会导致查询服务获取文档,因此比简单的k/v get(“user::000000000001”)要慢。

为了获得最佳的延迟,请确保检查您的查询计划(使用explain语法)并确保您的查询没有被提取。 https://docs.couchbase.com/server/6.0/n1ql/n1ql-language-reference/explain.html