我读过以下内容:
http://wiki.apache.org/solr/SolrPerformanceFactors
http://wiki.apache.org/solr/SolrCaching
http://www.lucidimagination.com/content/scaling-lucene-and-solr
我对以下几点有疑问:
-
如果我使用JVM选项
-XX:+UseCompressedStrings
我可以节省多少内存?举一个简单的例子,如果我有一个索引字段(字符串)和一个存储字段(字符串),omitNorms = true和omitTf = true,我可以期望在索引和文档缓存中节省多少?我太乐观了 . -
Solr过滤器缓存究竟在做什么?如果我只是使用AND和一些OR进行简单查询,并按分数排序,我是否还需要它?
-
如果我想缓存文档缓存中的所有文档,我将如何计算所需的空间?使用上面的例子,如果我有20M文件,使用压缩字符串,并且存储字段的平均长度是25个字符,基本上是所需的空间(25字节small_admin_overhead)* 20M?
-
如果所有文档都在文档缓存中,查询缓存有多重要?
-
如果我想将每个文档自动装配到文档缓存中,会自动调查
*:*
的查询吗? -
scaling-lucene-and-solr文章称FuzzyQuery很慢 . 如果我'm using the spellcheck feature of solr then I'm基本上使用模糊查询权(因为拼写检查执行相同的编辑距离计算)?所以假设拼写检查和模糊查询都同样"slow"?
-
描述字符串的lucene字段高速缓存的部分有点令人困惑 . 我是否正确读取所需空间基本上是索引字符串字段的大小,整数是否等于该字段中唯一项的数量?
-
最后,在最大化吞吐量的情况下,有一个关于为操作系统磁盘缓存留出足够空间的声明 . 它说,"All in all, for a large scale index, it's best to be sure you have at least a few gigabytes of RAM beyond what you are giving to the JVM." . 所以如果我有一台12GB的内存机(作为例子),我应该给操作系统至少2-3GB?我可以通过查看磁盘索引大小来估计操作系统所需的磁盘缓存空间吗?
2 回答
唯一可以确定的方法就是尝试一下 . 但是,我希望索引节省很少,因为索引每次只包含一次实际字符串,其余的是文档中该字符串位置的数据 . 它们不是指数的重要组成部分 .
过滤器缓存仅缓存筛选器查询 . 它可能对您的精确用例没有用,但许多人发现它们很有用 . 例如,按国家/地区,语言,产品类型等缩小结果 . 如果您经常使用它们,Solr可以避免重新计算此类事件的查询结果 .
实际上,您只需要尝试并使用分析器进行测量 . 如果没有完全了解所使用的数据结构,那么其他任何东西都是纯SWAG . 你的计算与没有其他任何人的计算一样好 .
文档缓存仅在计算查询后节省了构成结果的时间 . 如果您将大部分时间花在计算查询上,那么文档缓存对您来说没什么用 . 查询缓存仅对重用查询有用 . 如果没有重复查询,则查询缓存无效
是的,假设您的文档缓存足够大以容纳它们 .
6-8不正面 .
根据我自己的Solr性能调优经验,您应该让Solr处理查询,而不是文档存储 . 您的大多数问题都集中在文档如何占用空间 . Solr是一个搜索引擎,而不是文档存储库 . 如果你希望Solr是FAST并占用最少的内存,那么它应该保留的唯一内容是用于搜索目的的索引信息 . 应该在其他地方存储,检索和呈现文档本身 . 优选地,在专门针对该工作优化的系统中 . 您应该在Solr文档中存储的唯一字段是用于从文档存储系统中检索的ID .
Caches
一般来说,缓存看起来是改善性能的好主意,但这也存在很多问题:
缓存对象很可能会进入旧一代垃圾收集器,收集成本更高,
管理插入和驱逐会增加一些开销 .
此外,除非您的查询中有模式,否则缓存不太可能大大提高您的搜索延迟 . 相反,如果您的流量的20%是由于一些查询,那么查询结果缓存可能会很有趣 . 配置缓存需要您非常了解您的查询和文档 . 如果不这样做,您应该禁用缓存 .
即使你禁用所有缓存,由于OS I / O缓存,性能仍然可以很好 . 实际上,这意味着如果您反复读取文件的相同部分,则可能是第一次从磁盘读取,然后从I / O缓存读取 . 并且禁用所有缓存允许您为JVM提供更少的内存,以便为I / O缓存提供更多内存 . 如果你的系统有12GB的内存,如果你给JVM 2GB,这意味着I / O缓存可能能够缓存最多10G的索引(取决于其他运行需要内存的应用程序) .
我建议您阅读此内容以获取有关应用程序级缓存与I / O缓存的更多信息:
https://www.varnish-cache.org/trac/wiki/ArchitectNotes
http://antirez.com/post/what-is-wrong-with-2006-programming.html
Field cache
字符串的字段高速缓存的大小是(一个长度为maxDoc的整数数组)(所有唯一字符串实例的一个数组) . 因此,如果您的索引包含一个字符串字段,其中N个实例平均大小为S,并且如果索引具有M个文档,则此字段的字段高速缓存大小约为
M * 4 + N * S
.字段缓存主要用于构面和排序 . 即使非常短的字符串(少于10个字符)are more than 40 bytes,这意味着如果您对具有大量唯一值的字符串字段进行排序或分面,您应该期望Solr需要大量内存 .
Fuzzy Query
FuzzyQuery is slow in Lucene 3.x, but much faster in Lucene 4.x.
这取决于你选择的Spellchecker实现,但我认为Solr 3.x拼写检查器使用N-Grams来寻找候选者(这就是为什么它需要一个专用索引)然后只计算候选人在这个集合上的距离,所以性能仍然相当不错 .