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

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

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

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

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

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

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

可以在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