solr in action翻译- 第四章配置Solr 4.4

 

转载请声明出处，谢谢。翻译也很辛苦 

 

4.3。管理搜索

<query>元素包含设置允许您使用缓存技术来优化查询性能,懒加载,和新搜索器变暖。不用说,设计优化查询性能从一开始你的搜索应用程序的成功是至关重要的。在本节中,您将了解管理搜索者,这是最重要的一个技术优化查询性能。

4.3.1。新搜索器概述

在Solr,查询处理的组件称为搜索者。只有一个“活跃”搜索者在Solr在任何给定的时间。查询所有组件都对主动搜索者搜索请求处理程序执行查询。

 

主动搜索者的只读视图底层Lucene索引的快照。因此,如果您添加一个新的文档Solr,那么它不是从当前搜索者搜索结果中可见。这就提出了一个问题:新文档如何成为出现在搜索结果中?答案是关闭当前的搜索器,打开一个新的一个只读视图的索引更新。这是意味着什么Solr提交文档。Solr的提交过程比我们所描述的更复杂,但我们可以节省一次彻底的讨论为下一章提交的细微差别。现在,认为提交是一种暗箱操作,使新文档和任何更新现有索引出现在搜索结果中打开一个新搜索。

图4.10显示了collections的核心包括主动搜索MBean服务器的示例中,可用插件的核心Plugins / Stats页面。

 

 

图4.10。检查积极搜索MBean Solr的collection1核心包括管理控制台

 在核心页面,注意searcherName属性(图中,Searcher@25082661主要)。让我们触发器的创建一个新的搜索者通过重新发送所有文件到你的服务器的例子中,当我们在2.1.4节:

cd $SOLR_INSTALL/example/exampledocs

 java -jar post.jar *.xml

现在,刷新核心页面,注意searcherName属性已经改变了一个不同的搜索器的实例。创建新搜索器,因为这个职位。jar命令发送提交后添加示例文档。

现在我们知道提交创建一个新的搜索者让新文档和更新,让我们考虑创建一个新搜索器的影响。首先,旧的搜索者必须被摧毁。但可以查询当前执行反对旧的搜索器,所以Solr必须等待所有正在进行的查询完成。

 

任何缓存的对象,是基于当前搜索的索引的视图必须失效。我们将了解更多关于Solr缓存管理下一节。现在,考虑从一个特定的查询缓存结果集。一些文件的缓存的结果可能被删除,新文档现在可能匹配的查询,它应该清楚缓存结果集不是有效的新搜索器。

 

因为预先计算的数据,比如缓存查询结果集,必须作废并重新计算,顺理成章地,打开一个新的搜索索引可能是一个昂贵的操作。这对用户体验有直接的影响。想象一个用户通过搜索结果分页,想象一个新搜索器打开后点击页面2但是之前请求页面3。当用户请求下一个页面时,前面计算的所有过滤器和缓存文件不再有效。如果你不照顾,用户可能会经历一些缓慢,特别是如果他们的查询是复杂的。

 

好消息是,Solr有许多工具来帮助缓解这种情况。首先,Solr支持气候变暖的概念新搜索器在后台并保持当前的搜索活动,直到新的充分加热。

4.3.2。变暖的新搜索器

Solr的方法,最好的结果比允许短时间内查询性能大幅减缓。这意味着Solr不关闭当前搜索器,直到一个新的搜索热身准备执行查询和最佳性能。

 

变暖的新搜索器就像一个在田径短跑运动员热身。短跑运动员开始比赛之前,他们确保肌肉热身,准备全速执行时开始开枪。以同样的方式,Solr不激活“冷”搜索。

 

一般来说,有两种类型的活动:变暖autowarming新缓存从旧缓存和执行cache-warming查询。我们将了解更多关于autowarming缓存在下一节中,我们深入Solr的cache-management特性。

 

cache-warming查询是一个预配置查询(xml),对一个新的执行搜索者为了填充新搜索器的缓存。下面的清单显示了示例cache-warming查询的配置服务器。

清单4.11。为newSearcher事件定义一个侦听器来执行变暖查询

 清单注册一个名为列表的配置设置(< arr name = "查询" >)的查询执行时在Solr newSearcher事件发生时,如后提交。另外,请注意查询注释掉了!这是故意的,因为有一个执行成本变暖的查询,和Solr开发者希望确保您配置变暖查询显式地为您的应用程序。cache-warming查询特定于应用程序的,例如开箱即用的违约是严格的目的。你负责配置自己的暖化查询。

 

选择变暖查询

拥有温暖的新搜索者通过执行查询的工具是唯一的一个很好的特性,而如果你能辨认出查询,将有助于提高查询性能。作为一个经验法则,变暖的查询应该包含query-request参数(q,fq、排序等)所经常使用的应用程序。因为我们还没有覆盖Solr查询语法,我们将表变暖查询,直到第7章的讨论,您将了解Solr的查询语法。阅读第七章之后,你就会知道如何构造变暖查询。现在,足以使精神注意,您需要重新审视这个话题一旦你更透彻地了解Solr查询建设。

 

我们还应该提到,你不需要有任何变暖查询您的应用程序。如果查询性能开始遭受提交后,然后你就会知道是时候考虑使用变暖查询。

太多的变暖查询

少即是多适用于变暖的古训查询。每个查询需要时间来执行,所以有许多变暖查询配置会导致长延迟开放新的搜索。最好保持变暖的列表查询的最小集搜索应用程序最重要的查询。

 

您可能想知道什么问题是新搜索器长时间热身。事实证明气候变暖同时太多的搜索者在您的应用程序可以消耗太多资源(CPU和内存),导致退化的搜索体验。

第一个搜索器

还有气候变暖的概念在Solr初始化或第一个搜索程序后重新加载一个核心。我们将让你来决定如果有价值配置变暖第一搜索查询。大多数Solr用户使用相同的变暖新和第一搜索查询。之前我们将注意力转向Solr的缓存管理,我们要提到两个附加在solrconfig searcher-related元素。xml:< useColdSearcher >和< maxWarmingSearchers >。

 

Solr支持使用XInclude将XML元素从其他文件到XML。而不是复制你的变暖为新和第一搜索查询的列表,例如,你可以保持在一个单独的文件列表和XInclude它在这两个地方,使用< xi:包括href = " warming-queries。xml " xmlns = " http://www.w3.org/2001/XInclude " >。

 

useColdSearcher

< useColdSearcher >元素包含一个新的搜索请求的情况下,目前没有注册搜索者。如果< useColdSearcher >是假的,那么Solr将阻塞,直到变暖搜索者已完成执行所有变暖查询;这是默认配置示例Solr服务器:< useColdSearcher > < / useColdSearcher >。

 

maxWarmingSearchers

可以想象,一个新的提交发行new-searcher变暖过程完成之前,这意味着另一个搜索者需要热身。这是真的特别是如果你搜索需要相当长的时间来热身。< maxWarmingSearchers >元素允许您控制搜索的最大数量,可以同时在后台热身。一旦达到这个阈值时,新的提交请求将失败,这是一件好事,因为太多的变暖搜索者可以在后台运行可以迅速耗尽服务器上的内存和CPU资源。Solr附带一个默认的2,这是一个很好的价值开始:

<maxWarmingSearchers>2</maxWarmingSearchers>

 

如果你发现你的服务器达到最大阈值往往,重新审视你的变暖逻辑是否new-searcher变暖是耗时太长。

 

希望你现在有一个很好的感觉对什么是搜索者和如何配置管理Solr搜索者正确地为您的应用程序。现在让我们看看更多的方法来优化查询性能使用缓存。

4.4. Cache management

Solr提供了大量的内置缓存来提高查询性能。之前的细节具体Solr缓存,重要的是要了解在Solr cache-management基本面。

4.1.1。缓存基础

有四个主要关注当使用Solr缓存:

•缓存大小和拆迁政策

•命中率和驱逐

•Cached-object失效

•Autowarming新缓存

 

一般来说,适当的缓存管理在Solr不是一种“决定完了就不再过问”的过程。你需要关注你的缓存和微调他们根据实际使用Solr。记住,Solr管理控制台是你的朋友时,监控重要的组件(比如缓存和搜索。

 

缓存大小

缓存的大小,你不希望你的缓存太大,他们在您的JVM使用所有可用的内存。Solr保持所有缓存对象在内存和磁盘不溢出,尽可能与一些缓存框架。因此,Solr需要你设置一个上限的数量在每个缓存对象。Solr将驱逐对象当缓存达到上限,使用最近最少使用或至少常用的拆迁政策。

 

最近最少使用(LRU)清除对象当缓存达到它的最大阈值基于一个对象的时候最后一次请求从缓存中。当缓存已满,添加一个新对象,LRU政策将删除最老的条目,年龄是由最后一次请求缓存中的每个对象。Solr的LRU策略是默认配置。

 

Solr还提供了一个最常用(LFU)政策,根据频率就清除对象请求从缓存中。这是有益的对于想为主更受欢迎的应用程序缓存中的条目,而不是只有那些最近被使用。Solr的过滤器缓存是一个很好的候选人使用LFU拆迁政策,因为过滤器创建和存储通常是昂贵的,所以你要保持滤波器缓存小和优先考虑在应用程序中最受欢迎的过滤器。我们将在下一节中学习更多关于过滤器缓存。

 

缓存大小的一个常见的误解是,你应该让你的缓存大小很大如果你有可用的内存。这种方法的问题是,一旦提交后缓存就失效,可以有许多JVM需要垃圾收集的对象。记住,关闭搜索无效所有缓存值。没有适当的调优的垃圾收集,这可能导致出现长时间的停顿在您的服务器,由于完整的垃圾收集。我们将了解更多关于微调垃圾收集参数在12章Solr。现在,重要的教训是避免定义过于大缓存和定期让一些缓存中的对象被驱逐。

命中率和拆迁

命中率是缓存读请求的比例,结果找到一个缓存值。命中率表明应用程序多少好处是获得从缓存中。理想情况下,

你想让你的命中率是尽可能接近1(100%)。低命中率表明Solr不是从缓存中受益。

 

驱逐计数显示有多少缓存已经被赶出对象基于先前所描述的拆迁政策。由此可见,拥有大量的拆迁是表明你的缓存的最大大小为您的应用程序可能太小。驱逐计数和命中率是相互关联的,作为一个高驱逐计数会导致次优的命中率。优化你的命中率将在12章更详细地介绍。

Cached-object失效

在大多数cache-management场景中,您需要担心如何使一个缓存对象,以便您的应用程序不返回的数据。但在Solr,这不是一个问题,因为所有缓存中的对象都与一个特定的搜索器实例和搜索器关闭时立即失效。回想一下,搜索是一个只读视图的索引的快照;因此,所有缓存对象仍然有效,直到搜索器关闭。

Autowarming新缓存

正如我们在4.3节中讨论的,提交后Solr创建一个新的搜索器,但它不关闭旧的搜索器,直到新的搜索者完全是温暖的。的一些键soon-to-be-closed搜索器的缓存可以用来填充新搜索器的缓存中,这一过程称为autowarming Solr。注意autowarming缓存是不同的比使用查询来填充一个缓存,变暖4.3.2节中我们讨论了。

 

每一个Solr缓存支持autowarmCount属性表明取自对象的最大数量或比例的旧缓存大小hit。对象是如何autowarmed取决于特定的缓存。很快我们将了解更多关于cache-specific autowarming策略。现在的关键是,您可以配置Solr的缓存刷新缓存对象的一个子集,当打开一个新搜索器,但与任何优化技术,你需要小心,不要夸大其辞。

 

此时,您应该有一个基本的了解Solr cache-management概念。现在让我们来了解特定类型的缓存Solr用来优化查询性能,首先最重要的一个缓存:缓存过滤器。

10/24/11。过滤器缓存

在Solr,过滤器限制搜索结果的文档满足过滤条件,但这并不影响得分。2.2.1节中我们看到一个这样的例子在我们的第一个

示例查询过滤制造商文档字段(manu)设置为贝尔金使用fq=manu:Belkin,可以看到在这个清单。

清单4.12。示例查询使用过滤查询fq字段

 Solr执行该查询时,计算和缓存一个高效的数据结构,表明文档索引匹配滤波器。为服务器的例子中,有两个文档匹配这个过滤器。

 

现在考虑如果另一个查询发送到Solr相同的过滤查询(fq =马努:贝尔金),但不同的查询,如q = USB。不是很好,如果第二个查询可以使用过滤查询从第一个查询的结果吗?这是Solr的过滤器缓存的目的!看到这个缓存,文物核心包括导航到查询页面,并提交查询如图4.11所示。

图4.11。执行一个查询过滤查询fq条款看到过滤器缓存。

 接下来,导航到Plugins / Stats包括统计页面缓存并单击链接。图4.12显示了filterCache MBean的属性和数据。重新执行查询几次,你就会看到filterCache统计数据的变化。

 

 

很难完全理解缓存过滤小指数的价值,但是如果你想象一个索引数以百万计的文件,您可以看到如何缓存过滤器可以帮助优化查询性能。事实上,使用过滤器来优化查询是Solr中最强大的功能之一,这主要是因为在查询过滤器是可重用的。现在,我们可以节省一个更深层次的讨论第7章的过滤器,把我们的重点在xml过滤器缓存是如何配置。清单4.13显示了过滤器的缺省配置缓存。

清单4.13。过滤器缓存的初始设置服务器实例

 Autowarming过滤器缓存

一个过滤器可以优化查询的一个强大的工具,但是你也可以遇到麻烦如果你不正确地管理缓存的过滤器。过滤器可以是昂贵的创建并存储在内存中如果你有大量的文件索引,或者过滤条件是复杂的。如果过滤器是一般足以适用于应用程序中的多个查询,可以缓存结果过滤。此外,您可能希望hit的一些缓存当打开一个新的搜索过滤器。

 

让我们看下罩过滤缓存的理解发生了什么在autowarming过滤器对象的缓存。现在,你应该知道对象不容易从旧到新的缓存,因为底层指标发生了变化,无效的缓存对象像过滤器。每个对象缓存的一个关键。过滤器缓存,关键是过滤查询,如马努:贝尔金。温暖的新缓存,键的一个子集从旧的缓存和对新搜索器,执行recomputes过滤器。Autowarming过滤器缓存要求Solr重新执行过滤查询新搜索器。因此,autowarming过滤器缓存可以是一个来源Solr的性能和资源利用率问题。

 

想象这样的场景你数以百计的过滤器缓存和autowarmCount将取自100年。当气候变暖的新搜索器,Solr必须执行100年过滤查询。假设需要65秒执行100年过滤查询和应用程序提交改变每一分钟。在这种情况下,你很快就会遇到问题的变暖太多在后台搜索者。

 

我们建议您启用autowarming过滤器的缓存,但设置autowarmCount属性取自少数开始。此外,我们认为,LFU驱逐政策更适合过滤缓存,因为它允许您保持滤波器缓存小,优先考虑在应用程序中最受欢迎的过滤器。以下是推荐的配置设置过滤器缓存:

 

 

你需要尝试这些参数,取决于有多少过滤器应用程序使用和频率你提交你的索引。

 

每个缓存的内存使用过滤器,Solr根据的大小有不同的滤波器表示匹配文档集。作为一个上限,你可以图,任何过滤器匹配许多文档索引需要MaxDoc(指数)文档的数量的内存。例如,如果您的索引1000万个文档,然后一个过滤器需要1000万位的内存,或者大约1.2 MB的内存。

11/17/11。查询结果缓存

查询结果缓存包含一个查询的结果集。如果您执行查询清单4.12不止一次,后续结果从查询结果缓存,而不是re-executing相同的查询与索引。这可以减少计算的成本昂贵的一个强大的解决方案查询。查询结果缓存被定义为

<queryResultCache class="solr.LRUCache"

size="512"

initialSize="512"

autowarmCount="0"/>

 

在幕后,查询结果缓存包含查询关键和内部Lucene文档id的列表值。内部Lucene文档id可以改变从一个搜索器,所以缓存值时必须重新计算变暖查询结果缓存。

 

温暖的查询结果缓存,Solr需要重新执行查询,它可以是昂贵的。同样建议我们给对过滤器保持autowarmCount属性取自小缓存适用于查询结果缓存。说,我们做的推荐设置autowarmCount属性取自这个缓存比默认为零,其他的东西,这样你得到一些受益于autowarming最近查询。

 

除了大小之外,Solr提供杂项设置来帮助你调整你的查询结果缓存的使用。

查询结果窗口大小

2.2.4节中我们强调在Solr分页搜索结果的重要性,以确保最佳的查询性能。< queryResultWindowSize >元素允许您准备额外的页面,当你执行一个查询。

 

想象你的应用程序每页显示10文档和在大多数情况下用户只看第一和第二页。你可以设置< queryResultWindowSize > 20来避免重新执行查询来检索结果的第二页。一般来说,你想要的

这个元素来两三次使用的页面大小最重要的查询。但是如果你设置的太大,那么每个查询都是付出代价的加载文件比你显示给用户。如果你的用户很少超越第1页,那么最好是将该元素设置为页面大小。您可以确定查询的比例附加页的结果通过搜索Solr日志文件,开始寻找一个参数大于零。

Query result max docs cached

4.1.1节中我们讨论了,你必须设置一个最大尺寸为Solr缓存,但这并不影响缓存中的每个条目的大小。可以想象,一个结果集持有数以百万计的文件缓存将极大地影响在Solr可用内存。< queryResultMaxDocsCached >元素允许您限制文档的数量为每一个条目在缓存查询结果缓存。用户只看前两页在大多数搜索应用程序,所以一般情况下应该将这个参数设置为不超过两个或两个页面大小的三倍。

 

Enable lazy field loading

Solr中常见的设计模式是有一个查询返回字段为每个文档的子集。例如,在我们的示例查询(清单4.12),我们请求的名称,价格,功能,和得分字段。但是索引中的文档有很多领域,例如类别,流行,manufacturedate等等。如果您的应用程序采用这种常见的设计模式,你可能想要< enableLazyFieldLoading >设置为true,以避免加载不必要的字段。我们的示例文档没有许多领域,所以很容易忽略此设置的好处。在实践中,大多数文档有很多领域,所以这是一个好主意懒洋洋地加载字段。

 

4.4.4. Document cache

查询结果缓存包含一个内部文件id列表匹配查询,所以即使查询结果缓存,Solr仍然需要从磁盘加载文件产生的搜索结果。文件缓存用于存储文件从磁盘加载在内存中键控内部文档id。由此可见,查询结果缓存使用文档缓存找到缓存版本的文件缓存结果集。

 

这就提出了一个问题:是否有意义温暖文件缓存。有一个好论点,反对autowarming这个缓存,因为没有办法确保文档你变暖有任何关系查询和过滤从查询结果和过滤autowarmed缓存。如果你总是索引,查询返回的文档是不断变化的,你可能会花时间重新创建文档,可能不利于你的温暖过滤和查询结果缓存。另一方面,如果你的索引是相对静态的,文档缓存可能提供价值。

 

4.4.5. Field value cache

最后一个缓存我们提到的是字段值,严格使用Lucene和不是由Solr。字段值缓存提供了快速访问存储字段值由内部文档ID。这是排序和在构建期间使用响应文件。因为这是一个高级主题,我们将请Lucene JavaDoc(org.apache.lucene.search.FieldCache)的更多信息。

 

在这一点上,你知道Solr流程查询使用请求处理管道,你知道如何优化查询性能和缓存使用new-searcher变暖。

4.5。剩余的配置选项

 

我们已经介绍了很多在solrconfig最常用的设置。xml文件在这一章,但有很多附加功能,我们尚未涉及。Solr包含许多的专家级设置,不幸的是超出了我们所能覆盖的范围在这本书。Solr的一个非常有用的特性是,solrconfig示例。xml附带Solr包含大量的注释解释这些额外的设置控制以及如何配置它们。我们鼓励您花时间探索solrconfig。xml自己更多地了解所有的旋钮可以用来优化Solr的性能和使新特性。

因为solrconfig。xml是如此如何在Solr中启用新功能的核心,这不是最后一次我们将看到这个文件。我们覆盖了Solr在行动的新特性,您将看到如何在xml启用这些功能。您将看到如何配置响应格式,如何定义新的搜索处理程序和搜索组件专门为你的搜索应用程序,以及如何正确地优化您的Solr服务器对生产环境和最佳的相关性。简而言之,有更多了解配置Solr,但是你现在应该有一个很好的掌握什么样的配置选项是可用的和重要的最初启动并运行Solr。

 

4.6。总结

肯定给自己一个表扬工作之后通过这章相对较长!我们知道学习配置不是最有趣的话题。此时,您应该有一个坚实的理解如何配置Solr,尤其是优化方法的性能。具体地说,您了解了Solr的请求处理管道是由一个统一的请求调度程序和高度可配置的请求处理程序。我们看到一个search-request处理程序有四个阶段,每个阶段你可以定制。/浏览Solritas应用程序处理程序作为一个很好的例子,使用默认参数和自定义组件(比如拼写检查),使一个功能丰富的搜索体验,简化client-application代码。

 

我们也学会了如何Solr处理查询请求与组件使用的只读视图索引搜索者。只有一个活跃在Solr搜索者在任何时候,和一个新的搜索器之前需要创建索引的更新是可见的。关闭当前活动搜索开放一个新的可以是一个昂贵的操作,影响查询性能。对查询性能的影响降到最低,Solr允许您配置静态查询热身新搜索器。妥善管理新的搜索热身过程是最重要的一个配置任务你需要为你的搜索应用程序处理。因此,我们将讨论在12章这进一步。

 

Solr还提供了许多重要的缓存,为您的应用程序需要调整。我们看着过滤器、查询结果文档,字段值缓存。对于每一个缓存,您需要设置一个最大尺寸和拆迁政策基于应用程序的真正用法。Solr管理控制台提供了关键的统计数据,例如命中率,可以帮助你确定你的缓存大小正确。

 

缓存可以温暖当创建一个新的搜索器,这也有助于优化查询性能。例如,您可以使用缓存autowarming预填充Solr的过滤器缓存查询在您的应用程序使用的最流行的过滤器。缓存autowarming虽然强大,也会导致大量等待时间,而新搜索器温度升高。我们建议你先小autowarmCount价值观和取自密切监测搜索器预热时间。缓存优化也将在第十二章进一步覆盖。

 

虽然在本章给出的配置选项代表最重要的设置通常会想调整,本章远远低于覆盖每一个可用的配置选项(这不是我们的目标,这一章甚至这本书)。我们的目标是让你舒服Solr的配置是如何工作的,而推迟报道许多额外的配置选项,直到我们介绍相应的功能在这本书的其余部分,了解它们的性能影响。

 

当我们开始提到的这一章,我们也选择在solrconfig跳过与索引相关的设置。xml直到我们覆盖索引的基础知识。在

 

下一章,你将学习关于Solr索引过程和与索引相关的配置设置。