RavenDb 对重复搜索和页面的优化

Question

给定一个文档结构，它有 15 个属性和 3 个 IEnumerable 属性，其中每个这样的属性最多可以有 20 个值。

当我在 raven 中有 50,000 个这样的文档时，假设用户可以通过提供针对 7 个左右属性的值来构建标准..

假设最常重复执行 30 次唯一搜索，平均而言，用户每次执行搜索都会翻阅 5 页。

现在假设我找到 7000 个结果匹配用户构建的某些条件，如果我选择检索所有符合条件的 7000 个 id（继续跳过 take 以检索我想象的所有内容），然后对条件进行哈希处理并将其用作将 7000 个值存储在 memcached 中的键，然后当再次搜索相同的条件时，我可以简单地从缓存中检索 id，获取用户所在页面的 10 个 id，并通过 raven 的 id 加载结果。此外，当他们翻页时，我可以选择不使用跳过和获取再次执行相同的搜索，而只需转到缓存并获取下一页的 ID，然后转到 raven 进行加载。

换句话说，对于之前没有搜索过的每个条件，我们执行搜索，检索匹配的 id，将它们缓存到作为关键字散列的条件，然后当用户页面搜索结果或另一个用户执行相同的搜索时，我们只需执行raven 通过 id 加载，我们可以通过查找散列标准作为键从 memcached 中检索。

与一直进行搜索、在需要分页时跳过 take 以及让 raven 在重用搜索时重用动态索引的魔力相比，这种方法是否能给我带来任何好处？

注意：我使用的是 LINQ api。

Answer 1

您正在谈论建立自己的索引。使用 memcached 或任何技术来存储索引都没有关系，它只是 -> 一个索引。

Lucene.NET 已经过高度优化，可以非常快速地处理您所描述的查询，因此您会做得更好的可能性很低。你需要考虑非常困难的场景，比如过时的索引、并发等。即使你可以做得更好，真的值得吗？我的意思是，如果您希望搜索执行得更快，那么将另一个 CPU 放入您的机器中会不会便宜得多？

说清楚 - 是的，我绝对认为您应该使用标准 LINQ api 并让 RavenDB 创建动态索引。如果真的那么频繁地使用它们，RavenDB 很快就会将它们推广为永久索引。