我们正在实施一个包含超过 1.5 亿个文档的大型 Lucene/Solr 设置。我们还将每天进行适量的文档更新。
我的问题实际上分为两部分：
在 Solr 中使用另一种缓存实现，即 EHCache 而不是本机 Solr LRUCache/FastLRUCache 的含义是什么？
Terracotta 宣布了 BigMemory，它旨在与 EHCache 一起用作进程内堆外缓存。根据 TC，这允许您存储大量数据而无需 JVM 的 GC 开销。这是与 Solr 一起使用的好主意吗？真的有用吗？
我会特别是。想听听具有 EHCache/BigMemory 和/或 Solr Cache 调整的实际生产经验的人的意见。
【问题讨论】：
标签： garbage-collection lucene solr ehcache
很多关于这个话题的想法。虽然我的回复没有以任何方式利用 EhCache。
首先，我认为文档不应该存储在您的搜索索引中。搜索内容应该存储在那里，而不是整个文档。我的意思是，从您的搜索查询返回的应该是文档 ID。不是文件本身的内容。文档本身应该从第二个系统存储和检索，可能是它们开始索引的原始文件存储。这将减少索引大小，减少文档缓存大小，减少主从复制时间（如果您经常更新，这可能会成为瓶颈），并减少编写搜索响应的开销。
接下来，考虑在 Solr 前面放置一个反向 HTTP 代理。尽管查询缓存允许 Solr 快速响应，但像 Varnish 这样的缓存位于 Solr 前面甚至更快。这将卸载 Solr，使其能够花时间响应以前从未见过的查询。第二个效果是您现在可以将大部分内存放在文档缓存而不是查询缓存中。如果您遵循我的第一个建议，您的文档将非常小，即使不是全部，您也可以将大部分（如果不是全部）保存在内存中。
快速了解文档尺寸的信封计算。我可以轻松地为 1.5 亿个文档提供一个 32 位 int 作为 ID。我还有 10 倍的文档增长空间。 1.5 亿个 ID 占用 600MB。为 Solr 包装文档添加一个软糖因素，您可以轻松地将所有 Solr 文档缓存在 1-2GB 中。现在考虑获得 12GB-24GB 或 RAM 很容易，我想说你可以在 1 个盒子上完成这一切并获得令人难以置信的性能。不需要像 EhCache 这样无关紧要的东西。只需确保尽可能高效地使用搜索索引。
关于 GC：我没有看到很多 GC 时间花在我的 Solr 服务器上。大多数需要收集的是与 HTTP 请求和响应周期相关的非常短暂的对象，它们永远不会超出伊甸园空间。正确调整时缓存的周转率不高。唯一较大的变化是在加载新索引并刷新缓存时，但这并不是经常发生的。
编辑：作为背景，我花了相当多的时间为一家销售控制台并每天从其 Solr 服务器提供数百万次搜索的大公司调整 Solr 缓存。
【讨论】：
我不确定是否有人尝试过。当然，我们很乐意与 Solr 人员合作，以了解这将是多么有用。我们甚至可以针对用例对其进行优化。
【讨论】：