搜索查询的缓存策略

Question

我们正在开发一个搜索引擎网络应用程序，使用户能够搜索大约200个门户网站的内容。

我们的业务合作伙伴负责维护和提供solr / lucene实例，该实例正在执行索引数据的主要工作。

我们的应用程序查询solr并以人性化的方式呈现结果。但是，我们想知道如何限制查询量，可能使用某种形式的缓存。结果可以缓存几个小时。

我们想知道的是：缓存查询结果的好策略是什么？显然我们期望方法调用变化很大......是否有意义进行缓存？

是否有一些缓存系统特别适合此用例？我们正在使用Spring 3进行开发。

Answer 1

我要记住，Solr已经内置了很多缓存，以加快常见查询。我建议你在离开之前调查Solr / Lucene的固有功能，reinvent the wheel使用自己的查询缓存。

Here是一个很好的起点。

Answer 2

最简单的解决方案是在您的查询到达Solr之前对其进行改造。

我创建了自己的QueryBuilder方法，在我遇到Solr之前，我通过了我的查询字符串。

所有这些都会爆炸所有参数，然后将它们分类到预定义的组集中。

例如，为了规范化查询以使它们可以缓存，您可以按字母顺序对每个键进行排序，然后重新构建查询字符串，然后使用它来查询Solr。 （实际查询结果将保持不变）。

在实际运行查询之前，您可以创建Solr查询字符串的哈希值，并检查已保存的所有键的内存哈希值。如果您发现自己很可能接近数以百万计的查询密钥，那么您可能希望开始使用BloomFilter来减少密钥空间，并且仍然可以在缓存命中率上保持一定程度的准确性。

或者，您可能希望查看在您和Solr之间放置反向代理缓存。例如，如果您要查询Solr，Spring -> Varnish -> Solr，Varnish可用于缓存，它将使用查询字符串作为哈希。然后，您可以设置2小时的Expires，以便自动刷新/清除/无效结果。

希望这会有所帮助。

Answer 3

我发现在Lucene外部缓存结果或渲染内容效果最佳。拥有一个API搜索服务，该服务使用Lucene索引的结果指向缓存层。

如果将缓存层分开，则可以插入所需的缓存...分布式缓存（Redis，Azure AppFabric，其他云缓存等）。您还可以缓存网页的部分渲染（即ASP.NET中的输出缓存）或使用RESTful约定缓存API调用。然后，缓存升温或主动缓存（基于使用情况）等服务很容易实现。

然后，您的应用程序/索引缓存可以在应用程序的更多层中“重复使用”，而不是仅在索引级别进行缓存。这一切都取决于你的索引更新是如何实时的，如果查询是每个客户端/用户ID的日期级别安全等。如上所述，Solr已经为你做了一些这样的事情。