Solr缓存

2019-03-27 01:27|来源: 网路

缓存在 Solr 中充当了一个非常重要的角色,Solr 中主要有这三种缓存:
Filter cache(过滤器缓存),用于保存过滤器(fq 参数)和层面搜索的结果
Document cache(文档缓存),用于保存 lucene 文档存储的字段
Query result(查询缓存),用于保存查询的结果
还有第四种缓存,lucene 内部的缓存,不过该缓存外部无法控制到。
通过这 3 种缓存,可以对 solr 的搜索实例进行调优。调整这些缓存,需要根据索引库中文档的数量,每次查询结果的条数等。
在调整参数前,需要事先得到 solr 示例中的以下信息: 索引中文档的数量 每秒钟搜索的次数 过滤器的数量 一次查询返回最大的文档数量
不同查询和不同排序的个数,这些数量可以在 solr admin 页面的日志模块找到。

假设以上的值分别为:
索引中文档的数量:1000000
每秒钟搜索的次数:100
过滤器的数量:200
一次查询返回最大的文档数量:100
不同查询和不同排序的个数:500
然后可以开始修改 solrconfig.xml 中缓存的配置了,
第一个是过滤器缓存:
第二个是查询结果缓存:
第三个是文档缓存:
这几个配置是基于以上的几个假设的值进行调优的。


转自:http://www.solr.cc/blog/?p=999

相关问答

更多
  • 推荐学习夜行侠老师的《solrcloud5.2.1+zookeeper一部精通》这套课程
  • 推荐学习夜行侠老师的《solrcloud5.2.1+zookeeper一部精通》这套课程
  • Solr是一个独立的企业级搜索应用服务器,它对外提供类似于Web-service的API接口。 用户可以通过http请求,向搜索引擎服务器提交一定格式的XML文件,生成索引;也可以通过Http Get操作提出查找请求,并得到XML格式的返回结果。
  • 唯一可以肯定的就是尝试一下。 但是,我期望在索引中节省很少,因为索引每次只包含一次实际字符串,其余的是该文本中字符串位置的数据。 它们不是指数的很大一部分。 过滤器缓存只缓存过滤器查询。 它可能对您的确切用例没有用处,但许多确实有用。 例如,根据国家,语言,产品类型等缩小结果。如果经常使用它们,Solr可以避免重新计算这类事情的查询结果。 实际上,你只需要尝试一下并用探查器进行测量。 如果没有深入了解所使用的数据结构,其他任何内容都是纯粹的SWAG。 你的计算和没有分析的人一样好。 文档缓存仅在计算查询之后 ...
  • 除了其他原因,为什么否是一个答案,也是变化的粒度。 Lucene(底层库)以只读形式存储数据。 Solr在其上添加了可更新的文档,但是使它们可见仍然是一个繁重的操作。 Solr的最新版本通过软提交使其变得更容易和更快,但是使可见变化的代价仍然是非常重要的。 因此,它实际上没有针对更新/缓存单个值进行优化。 数据结构针对多文档更新进行了优化,然后通过缓存超过该临时只读状态进行快速搜索。 In additions to other reasons why No would be an answer, is al ...
  • 只需使用Solr缓存wiki中提到的{!cache=false} localParam标志 Just use {!cache=false} localParam flag as mentioned in the Solr caching wiki
  • 而问题是? 只需将'fl'参数定义为要返回的字段列表,在这种情况下为'id'。 如果你从未真正返回其他字段,请不要费心存储它们,只将它们定义为索引。 如果您确实需要存储但很少需要它们,请使用solrconfig.xml中的 enableLazyFieldLoading设置进行测试 And the problem is? Just define the 'fl' parameter to be the list of fields you want to return, in which case 'id'. ...
  • 我能够确定我的返回函数出了什么问题:我没有在结果中正确循环。 最好的方法是使用map函数迭代它们。 $("#Keyword").autocomplete({ minLength: 3, source: function(request, response) { $query = "http://127.0.0.1:8080/solr/terms/?jsoncallback=?&terms=true&terms.prefix=" + $("#Keyword").val(); ...
  • 这些DB服务器的用途不同,它在很大程度上取决于您的应用程序(以及您存储的数据类型)是否应该仅使用Solr或MySQL。 MySQL可以很好地存储具有大量关系和表格的数据(彼此相关的表格)。 Solr很适合文本搜索(正如你所说:快速索引),如果你没有很多“相关数据”,你确实可以将这些数据存储在相同的文档中。 有些人确实只使用Solr来存储他们的数据库...但我仍然认为RDBM可以很好地用于某些类型的数据。 例如:如果您想允许快速搜索系统用户并存储他们的完整个人资料,以及一些信息详细信息......最好使用So ...
  • 已经很晚了,但是我遇到了同样的问题,所以我会在这里发布答案。 这里 :“您应该记住,只有在未缓存过滤器查询时,成本属性才有效。” 和这里 因此,“成本”仅适用于非缓存过滤器。 It's late, but I've faced with the same question, so I'll post answer here. Here : "You should remember that cost attribute work only when the filter query is not cache ...