Solr使用EHCache/BigMemory进行缓存

6
我们正在实施一个具有1.5亿以上文档的大规模Lucene/Solr设置,每天还会有适量的文档更新。我的问题实际上有两个部分:使用Solr内的其他缓存实现(如EHCache)对使用LRUCache/FastLRUCache的本地Solr缓存有什么影响?Terracotta已经宣布了BigMemory,旨在与EHCache一起用作进程内非堆缓存。据TC称,这使您可以在没有JVM GC开销的情况下存储大量数据。 在Solr中使用这种缓存是一个好主意吗? 它真的有帮助吗?我特别想听听具有EHCache/BigMemory和/或Solr缓存调优实际生产经验的人的意见。
2个回答

8
对于这个话题,我有很多想法。虽然我的回答没有以任何方式利用EhCache。
首先,我不认为文档应该存储在您的搜索索引中。搜索内容应该存储在那里,而不是整个文档。我的意思是,从您的搜索查询返回的应该是文档ID,而不是文档本身的内容。文档本身应该存储在第二个系统中,并从中检索,可能是它们最初被索引的原始文件存储库。这将减少索引大小,减少文档缓存大小,减少主从复制时间(如果您经常更新,则可能会成为瓶颈),并减少编写搜索响应的开销。
接下来,请考虑在Solr前面放置一个反向HTTP代理。虽然查询缓存允许Solr快速响应,但像Varnish这样的缓存比Solr更快。这将卸载Solr,使其有时间响应它以前没有看到的查询。第二个效果是,现在您可以将大部分内存投入文档缓存而不是查询缓存。如果您遵循我的第一个建议,您的文档将非常小,允许您将大多数甚至全部文档保存在内存中。
对于文档大小的快速估算。我可以轻松地提供一个32位int作为150万个文档的ID。我仍然有10倍的余地用于文档增长。 150万个ID占用600MB。加上Solr包装文档的调整因素,您可能可以轻松地将所有Solr文档缓存到1-2GB中。考虑到现在很容易获得12GB-24GB或RAM,我认为您可以在一台机器上完成所有操作并获得出色的性能。没有必要使用像EhCache这样的任何不必要的东西。只需确保尽可能有效地使用搜索索引。
关于GC:我没有看到我的Solr服务器上花费了很多GC时间。大部分需要收集的是与HTTP请求和响应周期相关的非常短暂的对象,它们永远不会离开伊甸园空间。当正确调整缓存时,缓存没有高周转率。唯一的大更改是加载新索引并刷新缓存,但这并不经常发生。
编辑:背景是,我花了相当多的时间来调整Solr缓存,为一家销售游戏机并从其Solr服务器每天提供数百万次搜索服务的大型公司工作。

由于我们实际上还没有构建任何东西,因此我们肯定会考虑这个选项。但是,这将涉及启动数据库实例。谢谢。 - nvalada
根据我所概述的,它并不需要。您可以使用URL或文件路径作为您的ID。它会占用更多的空间,但仍然是合理的。 - rfeak
@rfeak:在我们公司,我们不仅使用Solr进行搜索,还用它来进行文本高亮。我认为将文档从索引中分离的方法会导致这种能力消失。如果您有时间,能否解释一下如何解决大型索引问题,同时利用Solr的文本高亮功能? - iralls

0

我不确定是否有人尝试过这个。当然,我们很乐意与Solr团队合作,以找出这对于使用者有多么有用。我们甚至可以为此优化。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接