手机版
你好,游客 登录 注册
背景:
阅读新闻

Solr性能调优

[日期:2013-10-06] 来源:Linux社区  作者:mxsfengg [字体: ]

Schema Design Considerations

indexed fields

indexed fields 的数量将会影响以下的一些性能:

  • 索引时的时候的内存使用量
  • 索引段的合并时间
  • 优化时间
  • 索引的大小

我们可以通过 将 omitNorms=“true” 来减少indexed fields数量增加所带来的影响。 

stored fields

Retrieving the stored fields 确实是一种开销。这个开销,受每个文档所存储的字节影响很大。每个文档的所占用的空间越大,文档就显的更稀疏,这样从硬盘中读取数据,就需要更多的i/o操作(通常,我们在存储比较大的域的时候,就会考虑这样的事情,比如存储一篇文章的文档。)

可以考虑将比较大的域放到solr外面来存储。如果你觉得这样做会有些别扭的话,可以考虑使用压缩的域,但是这样会加重cpu在存储和读取域的时候的负担。不过这样却是可以较少i/0的负担。

如果,你并不是总是使用 stored fields 的话,可以使用stored field的延迟加载,这样可以节省很多的性能,尤其是使用compressed field 的时候。 

Configuration Considerations

mergeFactor

这个是合并因子,这个参数大概决定了segment(索引段)的数量。

合并因子这个值告诉lucene,在什么时候,要将几个segment合并成为一个segment, 合并因子就像是一个数字系统的基数一样。 

比如说,如果你将合并因子设成10,那么每往索引中添加1000个文档的时候,就会创建一个新的索引段。当第10个大小为1000的索引段添加进来的时候,这十个索引段就会被合并成一个大小为10,000的索引段。当十个大小为10,000的索引段生成的时候,它们就会被合并成一个大小为100,000的索引段。如此类推下去。 

这个值可以在 solrconfig.xml 中的 *mainIndex*中设置。(不用管indexDefaults中设置)

mergeFactor Tradeoffs

较高的合并因子

  • 会提高索引速度
  • 较低频率的合并,会导致 更多的索引文件,这会降低索引的搜索效率

较低的合并因子

  • 较少数量的索引文件,能加快索引的搜索速度。
  • 较高频率的合并,会降低索引的速度。

Cache autoWarm Count Considerations

当一个新的 searcher 打开的时候,它缓存可以被预热,或者说使用从旧的searcher的缓存的数据来“自动加热”。autowarmCount是这样的一个参数,它表示从旧缓存中拷贝到新缓存中的对象数量。autowarmCount这个参数将会影响“自动预热”的时间。有些时候,我们需要一些折中的考虑,seacher启动的时间和缓存加热的程度。当然啦,缓存加热的程度越好,使用的时间就会越长,但往往,我们并不希望过长的seacher启动时间。这个autowarm 参数可以在solrconfig.xml文件中被设置。

详细的配置可以参考solr的wiki。

Cache hit rate(缓存命中率)

我们可以通过solr的admin界面来查看缓存的状态信息。提高solr缓存的大小往往是提高性能的捷径。当你使用面搜索的时候,你或许可以注意一下filterCache,这个是由solr实现的缓存。

详细的内容可以参考 solrCaching这篇wiki。

Explicit Warming of Sort Fields

如果你有许多域是基于排序的,那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明显需要预热的查询,这样FieldCache 就会缓存这部分内容。

Optimization Considerations

优化索引,是我们经常会做的事情,比如,当我们建立好索引,然后这个索引不会再变更的情况,我们就会做一次优化了。

但,如果你的索引经常会改变,那么你就需要好好的考虑下面的因素的。

  • 当越来越多的索引段被加进索引,查询的性能就会降低, lucene对索引段的数量有一个上限的限制,当超过这个限制的时候,索引段可以自动合并成为一个。
  • 在同样没有缓存的情况下,一个没有经过优化的索引的性能会比经过优化的索引的性能少10%……
  • 自动加热的时间将会变长,因为它依赖于搜索。
  • 优化将会对索引的分发产生影响。
  • 在优化期间,文件的大小将会是索引的两倍,不过最终将会回到它原来的大小,或者会更小一点。

优化,会将所有的索引段合并成为一个索引段,所以,优化这个操作其实可以帮助避免“too many files”这个问题,这个错误是由文件系统抛出的。

更多详情见请继续阅读下一页的精彩内容http://www.linuxidc.com/Linux/2013-10/91042p2.htm

Solr 的详细介绍请点这里
Solr 的下载地址请点这里

相关阅读:

Solr3.6.1 在Tomcat6下的环境搭建 http://www.linuxidc.com/Linux/2013-01/77664.htm

基于Tomcat的Solr3.5集群部署 http://www.linuxidc.com/Linux/2012-12/75297.htm

在Linux上使用Nginx为Solr集群做负载均衡 http://www.linuxidc.com/Linux/2012-12/75257.htm

Linux下安装使用Solr http://www.linuxidc.com/Linux/2012-10/72029.htm

Ubuntu 12.04 LTS 上通过 Tomcat 部署 Solr 4 http://www.linuxidc.com/Linux/2012-09/71158.htm

Solr实现Low Level查询解析(QParser) http://www.linuxidc.com/Linux/2012-05/59755.htm

基于Solr 3.5搭建搜索服务器 http://www.linuxidc.com/Linux/2012-05/59743.htm

linux
相关资讯       Solr 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留���中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款