Solr/Lucene fieldCache OutOfMemory在动态字段上的错误排序

我们有一个Solr核心，大约有250个

TrieIntField

s（声明为

dynamicField

）。我们的Solr索引中大约有1400万个文档，许多文档在这些领域中都有一定的价值。我们需要在一段时间内对所有这250个字段进行排序

我们面临的问题是，底层lucene

fieldCache

很快就会被填满。我们有一个4GB的盒子，索引大小是18GB。在对这些动态字段中的40或45个进行排序后，内存消耗约为90%，我们开始摆脱内存错误

目前，如果总内存消耗超过80%，我们每分钟都会运行一个cron作业，重新启动tomcat

从我所读到的内容中，我了解到限制可排序Solr字段上不同值的数量会降低

fieldCache

空间。这些可排序字段中的值可以是0到33000之间的任意整数，并且分布非常广泛。我们考虑了一些扩展解决方案，但处理整个问题的最佳方法是什么

更新：我们认为不进行排序，如果我们这样做，它将不会进入fieldCache。因此，与其发出类似的查询

select？q=name:alba&sort=relevance\u 11 desc

我们试过了

select？q={！boost相关性_11}名称：alba

---

但不幸的是，boosting也会填充字段缓存：（

我认为您有两种选择：

1） 添加更多内存。
2） 通过指定

facet.method=enum

，强制Solr不使用字段缓存

还有一个讨论同样问题的小组

---

除非你的指数很大，否则我会选择选项1）。RAM现在很便宜。

我们有一种方法可以通过保留单个排序字段来重新编写模式。我们拥有的动态字段类似于

相关性\u CLASSID

。当前架构有一个唯一的键

NODEID

和一个多值字段

CLASSID

——相关性得分针对这些类ID。如果我们改为每个节点ID每个classId保留一个文档，即新模式将使用

nodeId:classId

作为唯一键，并使用相同的

nodeId

跨文档存储一些冗余信息，然后，我们可以在单个字段上排序

相关性

，并对CLASSID进行筛选查询。

难道

facet.method

仅适用于facet查询吗？如何为排序查询禁用字段缓存？虽然增加内存是一个明显的解决方案，但我们的服务器由rackspace托管，4 GB服务器的成本为175美元/月，而15 GB服务器（几乎可以容纳整个Solr索引）的成本为657美元/月（请参阅）。在花更多的钱来解决这个问题之前，我们甚至不需要缓存，我想知道如何完全避免它。埃里克·埃里克森说：“考虑到这些限制，我确实看不出这能起什么作用。为了保存这些值，假设每个文档在150个字段中保存一个值，您需要150*4*14000000或8.4G的内存，而您没有那么多的内存可供使用。对于1400万文档来说，切分似乎很愚蠢，但这可能是必要的。或者获得具有大量内存的硬件。或者重新定义问题，这样就不必对这么多字段进行排序。我不太清楚该怎么做，但是“所以我们现在正在重新设计我们的模式！我接受你的回答谢谢分享，这很有趣。”。