Java SOLR性能调整

我读过以下内容：

我对一些事情有疑问：

如果我使用JVM选项

-XX:+UseCompressedStrings

我可以节省多少内存？举一个简单的例子，如果我有一个索引字段（字符串）和一个存储字段（字符串），其中omitNorms=true和omitTf=true，那么在索引和文档缓存中可以节省多少钱？我猜大概是50%，但这可能太乐观了

Solr筛选器缓存具体在什么时候运行？如果我只是用AND和几个OR做一个简单的查询，然后按分数排序，我需要它吗

如果我想在文档缓存中缓存所有文档，我将如何计算所需的空间？使用上面的例子，如果我有2000万个文档，使用压缩字符串，并且存储字段的平均长度是25个字符，那么基本上需要的空间是（25字节+小的管理开销）*20M吗

如果所有文档都在文档缓存中，那么查询缓存有多重要

如果我想将每个文档自动预热到文档缓存中，自动预热查询

*：*

会这样做吗

伸缩lucene和solr的文章说FuzzyQuery很慢。如果我使用solr的拼写检查功能，那么我基本上使用的是模糊查询权限（因为拼写检查进行相同的编辑距离计算）？那么拼写检查和模糊查询是否同样“慢”

描述字符串的lucene字段缓存的部分有点混乱。我是否正确理解了所需的空间基本上是索引字符串字段的大小+等于该字段中唯一项数量的整数arry

最后，在“最大化吞吐量”下，有一句话是关于为操作系统磁盘缓存留出足够的空间。它说，“总的来说，对于一个大规模索引，最好确保您至少有几GB的RAM超出了您提供给JVM的容量。”。因此，如果我有一台12GB的内存机器（作为一个例子），我应该给操作系统至少2-3GB的内存？我可以通过查看磁盘索引大小来估计操作系统所需的磁盘缓存空间吗

唯一确定的方法就是尝试一下。但是，我希望索引中的节省很少，因为索引每次只包含一次实际字符串，其余的是文档中该字符串位置的数据。它们在指数中所占比例不大

筛选器缓存仅缓存筛选器查询。它可能对您的精确用例没有用处，但许多人确实发现它们很有用。例如，按国家、语言、产品类型等缩小结果范围。如果您经常使用查询结果，Solr可以避免重新计算此类查询结果

实际上，你只需要尝试一下，然后用轮廓仪测量一下。如果没有对所使用的数据结构的深入了解，其他任何东西都是纯粹的SWAG。你的计算和其他人一样好，不需要分析

文档缓存仅在计算查询后构成结果时节省时间。如果您将大部分时间花在计算查询上，那么文档缓存对您没有什么好处。查询缓存仅对重复使用的查询有用。如果没有重复任何查询，那么查询缓存就没有用处

是的，假设您的文档缓存足够大，可以容纳所有文档

6-8不是阳性

---

根据我自己在Solr性能调优方面的经验，您应该让Solr处理查询，而不是文档存储。您的大多数问题都集中在文档如何占用空间上。Solr是一个搜索引擎，而不是文档存储库。如果您希望Solr速度快，占用的内存最少，那么它唯一应该保留的就是用于搜索目的的索引信息。文档本身应该在别处存储、检索和呈现。最好是在专门为该工作优化的系统中。Solr文档中应该存储的唯一字段是用于从文档存储系统检索的ID。

缓存

通常，缓存看起来是提高性能的好主意，但这也有很多问题：

• 缓存的对象可能会进入旧一代的垃圾收集器，而垃圾收集器的收集成本更高
• 管理插入和逐出会增加一些开销

此外，除非查询中存在模式，否则缓存不太可能大大改善搜索延迟。相反，如果20%的流量是由一些查询引起的，那么查询结果缓存可能会很有趣。配置缓存要求您非常了解查询和文档。如果不这样做，可能应该禁用缓存

即使禁用所有缓存，由于操作系统I/O缓存，性能仍然可以相当好。实际上，这意味着，如果反复读取文件的同一部分，很可能只有第一次从磁盘读取，然后从I/O缓存读取。禁用所有缓存可以减少JVM的内存，从而为I/O缓存提供更多内存。如果您的系统有12GB的内存，并且您为JVM提供2GB的内存，这意味着I/O缓存可能能够缓存多达10G的索引（取决于运行的其他也需要内存的应用程序）

我建议您阅读本文，以获得有关应用程序级缓存与I/O缓存的更多信息：

字段缓存

字符串的字段缓存大小为（一个长度为maxDoc的整数数组）+（一个数组用于所有唯一字符串实例）。因此，如果索引中有一个字符串字段，平均有N个大小为S的实例，并且如果索引中有M个文档，那么该字段的字段缓存大小大约为

M*4+N*S

字段缓存主要用于面和排序。即使是非常短的字符串（少于10个字符），这意味着您应该