我们正在实现一个大型 Lucene/Solr 设置，文档数量超过 1.5 亿。我们还将每天进行适度数量的文件更新。
我的问题实际上分为两部分:
在 Solr 中使用另一个缓存实现有什么含义，即 EHCache 而不是 native Solr LRUCache/FastLRUCache？
Terracotta 宣布了 BigMemory，旨在与 EHCache 一起用作进程内堆外缓存。根据 TC 的说法，这允许您在没有 JVM 的 GC 开销的情况下存储大量数据。这是与 Solr 一起使用的好主意吗？它真的会有帮助吗？
我会特别。喜欢听取具有 EHCache/BigMemory 和/或 Solr Cache 调优实际生产经验的人的意见。
最佳答案
关于这个话题有很多想法。虽然我的回答没有以任何方式利用 EhCache。
首先，我不认为文档应该存储在您的搜索索引中。搜索内容应该存储在那里，而不是整个文档。我的意思是，从您的搜索查询返回的应该是文档 ID。不是文件本身的内容。文档本身应该从第二个系统中存储和检索，可能是从它们开始索引的原始文件存储。这将减少索引大小，减少文档缓存大小，减少主从复制时间(如果您经常更新，这可能会成为瓶颈)，并减少编写搜索响应的开销。
接下来，考虑在 Solr 前面放置一个反向 HTTP 代理。尽管查询缓存允许 Solr 快速响应，但是像位于 Solr 前面的 Varnish 这样的缓存甚至更快。这会卸载 Solr，允许它花时间响应它以前从未见过的查询。第二个效果是您现在可以将大部分内存扔到文档缓存而不是查询缓存。如果您遵循我的第一个建议，您的文档将非常小，允许您将大部分(如果不是全部)保存在内存中。
快速回顾文档大小的信封计算。我可以轻松提供 32 位 int 作为 1.5 亿个文档的 ID。我仍然有 10 倍的文档增长空间。 1.5 亿个 ID 占用 600MB。为 Solr 包装文档添加一个模糊因素，您可能可以轻松地将所有 Solr 文档缓存在 1-2GB 中。考虑到现在获得 12GB-24GB 或 RAM 很容易，我想说您可以在 1 个盒子上完成所有这些并获得令人难以置信的性能。不需要像 EhCache 这样的无关紧要的东西。只需要确保尽可能有效地使用搜索索引。
关于 GC:我没有看到在我的 Solr 服务器上花费了很多 GC 时间。大部分需要收集的是与 HTTP 请求和响应周期相关的非常短的生命周期对象，这些对象永远不会超出 eden 空间。正确调整后，缓存的周转率并不高。唯一的大变化是在加载新索引和刷新缓存时发生的，但这并不是经常发生的。
编辑:作为背景，我花了大量时间为一家销售控制台并每天从他们的 Solr 服务器提供数百万次搜索的大公司调整 Solr 缓存。
关于garbage-collection - Solr 缓存与 EHCache/BigMemory，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4886127/