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

Question

当我们在Couchbase DB上进行基准测试时，我们尝试通过它们的id / key来比较对项的搜索，并通过使用辅助索引的查询来搜索项。

在这篇关于Couchbase中的索引和性能的文章之后，我们认为两者的性能是一样的。

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

例如，~3MS使用索引搜索，~0.3MS按键搜索(这是10倍因子)。

问题是，这种差异并不存在。按键搜索从0.3MS到15 to不等。

我们想知道：

1. 是否应该有更好的关键字搜索性能，而不是二级索引搜索？
2. 关键字搜索之间应该有这样的时间差吗？

Answer 1

你得到的结果与我所期望的是一致的。当您使用id执行任何操作时，Couchbase充当键值存储。键值存储基本上是一个大的分布式hashmap，在这个数据结构中，您可以在使用id时获得/保存/删除非常好的性能。

每当您存储新文档时，couchbase都会散列密钥并为其分配一个虚拟桶(类似于碎片)。当您需要取回这个文档时，它使用相同的算法来查找文档位于哪个虚拟桶中，因为SDK有集群映射，并且知道哪个节点有哪个碎片，您的应用程序将直接将文档请求到拥有它的节点。

另一方面，当您查询数据库时，Couchbase必须在内部创建一个map/还原，以找出文档的位置，这就是由id执行操作更快的原因。

对于从0.3ms到15ms的结果问题，如果不调试环境，很难判断。然而，有若干因素可能促成这一进程。例:文档缓存/不缓存，节点尺寸过小，等等。

Answer 2

要添加到@deniswrosa的答案中，次要索引总是要慢一些，因为首先必须根据查询遍历索引以找到文档键，然后执行键查找。如果您已经有了键，那么只执行键查找就更快了。遍历索引的工作量可能会根据索引的选择性、整个索引是否在内存中等而有所不同。内存优化索引可以确保整个索引在内存中，如果您有足够的内存支持这一点。

当然，如果所讨论的文档不在缓存中，并且需要从存储中进入内存，那么即使简单的密钥查找也可能更慢。

Answer 3

可以实现亚毫秒级的二级查找，但需要对查询、索引和一些可能的Couchbase系统参数进行一些调优。考虑以下简单示例：

userBucket中的示例文档：

“用户：：000000000001”：{“电子邮件”："benjamin1@couchbase.com"，"userId“："000000000001”}

此查询：

从userId中选择userBucket，其中email = "benjamin1@couchbase.com“和userId不为空；

...should能够通过适当调整二级索引来实现亚毫秒的性能：

在userBucket上创建索引userBucket(电子邮件，userId)；

由于索引完全覆盖了查询，所以查询引擎不需要从K/V存储中获取文档。然而，“选择*.”将始终导致查询服务获取文档，因此比简单的k/v GET("user::000000000001")要慢。

为了获得最佳延迟，请确保检查查询计划(使用解释语法)，并确保查询不是FETCHing。https://docs.couchbase.com/server/6.0/n1ql/n1ql-language-reference/explain.html