solr in action翻译-第三章Solr的关键概念 3.4

 

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

 

 

3.3.3。合理的平衡

虽然两者之间显然是紧张,精度和召回并不是相互排斥的。在前面的示例中查询只返回文档1、2和3,精度和回忆都是1.0,因为所有的结果是正确的,所有的正确的结果被发现。

 

最大化整整满精度和召回是几乎每个的终极目标search-relevancy-tuning努力。的例子(或一套手工调整结果),这看起来简单,但实际上,这是一个具有挑战性的问题。

 

许多技术可以在Solr中进行改善精度或召回,尽管大多数方面更偏向增加回忆完整的文档集

被返回。积极的文本分析(找到多个变化的话)是一个伟大的的例子,试图找到更多的比赛,尽管这些额外的匹配可能受伤总体精度,如果文本分析是如此咄咄逼人,它匹配不正确的单词变化。

 

一个常见的方法的精度和召回问题Solr是尝试解决两个:测量回忆整个结果集和测量精度只在第一页搜索结果(或几页)。在这个模型中,更好的匹配将提高搜索结果的顶部基于你如何优化您的使用Solr的相关性得分计算,但是你也会发现很多贫穷的比赛出现在你的搜索结果列表的底部如果你去最后一页搜索结果。

 

这是只有一个方法的问题,然而。因为许多搜索网站,例如,似乎想要尽可能多的内容,因为这些网站知道游客永远不会超出了前几页,他们可以显示出精确的结果在前几页,同时还包括许多不精确匹配在后续页面。这导致高回忆成绩在整个结果集被宽松的关键字匹配最初的查询。同时,精确的第一两页的结果仍然是由于海拔高的最佳匹配的顶部长串的搜索结果。

 

决定如何最好地平衡精度和召回最终依赖你的用例。在法律发现等场景,有一个沉重的重点放在回忆,因为有法律后果是否错过了任何文件。其他用例的要求只能找到一些伟大的比赛,这并不什么也没找到精确匹配查询中的每个词。

 

大多数搜索应用程序介于这两个极端之间,和引人注目的平衡精度和召回是一个永无止境的挑战:主要是因为通常是没有一个正确的答案。无论如何,了解精确的概念和回忆,为什么改变你摆动你对这两个之一概念性目标(和可能远离其他)有效提高至关重要你的搜索结果质量。第十六章致力于掌握相关性,这样你就可以当然你会再次见到这个精度和召回表面之间的紧张关系。

 

3.4。大规模搜索

 

Solr的最吸引人的方面,除了它的速度,相关性和强大文本搜索的特性,就是它鳞片。Solr能够处理几十亿的规模文档和无限的查询通过添加服务器。12和13章提供一个深入扩展Solr在生产的概述,但本节将奠定为如何考虑必要的操作一个可伸缩的特点搜索引擎。具体地说,我们将讨论Solr文档作为非正规的性质文档和为什么这跨服务器支持线性扩展,分布式搜索作品的概念从考虑服务器转移到思考的服务器和一些扩展Solr的极限。

3.4.1。规范化的文档

Solr的核心是所有文件被非规范化的概念。一个规范化的文档是一个文档中的所有字段都是独立的,即使这些字段的值复制在许多文件。这个概念的非正规数据是常见的许多NoSQL技术。的一个很好的例子反规范化是一个用户资料文档有城市、国家和邮政编码字段尽管在大多数情况下,将城市和州字段相同的所有文件每一个独特的postalCode价值。这与规范化的文档中文档的各个部分之间的关系可能被拆分为多个较小的文件,可以加入的碎片在查询时间。一个规范化文档只会有一个邮政编码字段和一个单独的文件位置存在于城市和州的每个独特的postalCode所以不需要重复在每个用户资料文档。如果你有任何培训建设关系数据库的规范化表,请离开,训练时在门口考虑建模内容Solr。图3.11演示了一个传统规范化的数据库表模型,一个大的“X”明显,这不是的数据建模策略将使用Solr。

 

 

图3.11。Solr文档不遵循传统的标准化模型关系数据库中。这个图展示了如何不去想Solr文档。相反的思维方面的多个实体相互关系,Solr文档建模为一个平面,规范化的数据结构,如清单3.2所示。

 

 

请注意,图3.11中的信息代表了两个用户在一个公司工作被称为“代码猴子反斗城,LLC。”虽然这图中显示的数据很好地规范化单独的表,员工的个人信息、位置和公司,这是不是我们如何将代表这些用户在Solr文档。清单3.2显示了非规范化表示为映射到每一个员工一个Solr文档。

清单3.2。两个非规范化用户文档

 

 

请注意,所有的公司信息是重复的和第二用户文档,这似乎违背的原则规范化数据库减少数据冗余和最小化数据依赖关系的设计。在传统的关系数据库,可以构造一个查询将加入来自多个表的数据当解决一个查询。尽管一些基本的加入在Solr功能现在存在(在15章将讨论),这只是建议的情况应该不切实际的正规化的内容。但Solr知道术语映射到文档本身并不知道任何文档之间的关系。也就是说,如果你想要寻找所有用户(在前面的例子)为公司工作佐治亚州迪凯特,你需要确保companycity companystate字段填充所有的用户查找成功

 

虽然这听起来可能限制非规范化文档数据模型,它还提供了一个相当大的优势:极端的可伸缩性。因为我们可以假定每个文档是独立的,这意味着我们还可以跨分区文件多个服务器,而无需在同一台服务器上(因为将相关文档文档是相互独立的。这个文档的基本假设独立可以跨多个分区并行查询的文档和多个服务器来提高查询性能,这最终让Solr横向扩展到处理查询数十亿的文档。这种规模的能力多个分区和服务器被称为分布式搜索,下一部分将讨论。

3.4.2。分布式搜索

世界将会是一个简单得多的地方如果每个重要的数据操作可以运行使用一个单独的服务器。在现实中,然而,有时可能会成为你的搜索服务器重载通过太多的一次查询或数据需要在单个服务器处理。

 

在后一种情况下,有必要将你的内容分解成两个或两个以上的独立的Solr索引,每个都包含一个单独的分区的数据。然后每一次搜索运行时,它将被发送到服务器,和单独的结果将被处理吗聚合之前返回的搜索引擎。

 

Solr包括这种分布式的搜索功能。我们将讨论如何手动数据划分为多个分区在12章当我们谈谈吗

关于扩展Solr的生产。从概念上讲,每一个Solr索引(称为一个Solr核心)可以通过它自己的独特的URL,可以告知Solr的核心执行一个聚合搜索其他Solr核心使用下面的语法:

http://box1:8983/solr/core1/select?q=*:*&shards=box1:8983/solr/core1,box2:8983/solr/core2,box2:8983/solr/core3

注意四个特点对前面的示例:

•碎片参数用于指定一个或多个Solr核心的位置。一个碎片是一个分区的索引,所以碎片参数告诉Solr的URL聚合来自多个分区的结果被发现在不同的数据Solr内核。

•Solr核心搜索(box1 core1)也包括在碎片的列表;它不会自动搜索本身,除非明确要求如图所示。

•这种分布式搜索是搜索跨多个服务器。

•没有要求单独Solr核心是位于单独的机器。它们可以在同一台机器上,在core2和core3都一样位于box2。

 

这里的重要外卖与扩展Solr的性质。它应该规模理论上线性因为跨多个Solr内核运行在分布式搜索

在每个索引分区平行。因此,如果你把一个Solr索引分成两个Solr相同的索引的文档数相结合,对面的分布式搜索两个索引应该大约快50%,减去任何聚合开销。

 

这个理论上也应该扩展到其他的服务器数量(在现实中,你会最终达到一个极限)。概念公式确定后总查询速度添加一个额外的索引分区(假设相同的文档总数)(N + 1)索引的查询速度=聚合开销+ N(查询速度索引)/(N + 1)

 

这个公式是有用的估计的好处你可以预期增加将您的数据分区数量各占一半。因为Solr鳞片近线性,您应该能够减少查询时间与额外的成正比Solr的内核数(分区)添加,假设你不受到服务器资源由于沉重的负荷。

3.4.3. Clusters vs. servers

在前面的部分中,我们介绍了分布式搜索的概念,使处理大型文档集的扩展。还可以添加多个或多或少相同的服务器进入你的系统来平衡负载高的查询量。

 

这两个扩展策略依赖于思考的概念转变对考虑服务器和集群的服务器。定义为一个服务器集群多个服务器,在演唱会工作,执行统一的功能。

 

下面的例子,应该类似于3.4.2节的例子:

http://box1:8983/solr/core1/select?q=*:*&shards=box1:8983/solr/core1,box2:8983/solr/core2

这个例子执行分布式搜索在两个Solr核心,core1 box1和core2 box2。当运行这个分布式搜索,查询撞到发生了什么box1如果box2下降?清单3.3显示了Solr的反应在这种情况下,包括错误消息从box2连接失败。

清单3.3。一个失败的分布式搜索(RemoteServer向下)

<response>

<lst name="responseHeader">

<int name="status">500</int>

<int name="QTime">1076</int>

<lst name="params">

<str name="shards">

box1:8983/solr/core1,

box2:8983/solr/core2

</str>

</lst>

</lst>

<lst name="error">

<str name="msg">

org.apache.solr.client.solrj.SolrServerException: IOException

occurred when talking to server at: http://box2:8983/solr/core2

</str>

<str name="trace">...</str>

<int name="code">500</int>

</lst>

</response>

 

请注意,这个用例是相互依赖的服务器。如果一个成为不可用搜索,搜索并开始失败,他们都不可用表示在例外清单。因此,重要的是想要的集群的服务器,而不是单一的服务器在构建了Solr必须的解决方案规模超出了一个盒子,因为这些服务器相结合作为一个计算资源。Solr提供了出色的通过使用内置cluster-management功能Apache的zookeeper,这将在我们的讨论SolrCloud在第13章。

 

当我们结束我们的讨论背后的关键概念搜索的规模,我们应该显然,Solr在这个领域确实有其局限性,其中一些将在下一节讨论。

3.4.4。Solr的极限

Solr是一个令人难以置信的强大的基于文档的NoSQL数据存储,支持全文搜索和数据分析。我们已经讨论了Solr的强大的好处反向索引和复杂,关键字,布尔查询功能。我们还相关性是多么的重要,我们已经看到,Solr规模线性或多或少跨多个服务器来处理额外的内容或查询卷。然后是什么用例的Solr不是一个好的解决方案?Solr的极限是什么?

 

一个限制,正如我们已经看到的,是Solr跨文件以任何方式没有关系。不适合加入大量的数据在不同的字段不同的文档,它不能跨多个服务器执行join操作。虽然这是一个Solr功能限制,与关系数据库相比,这一点假设的独立的文档是常见的许多NoSQL的权衡技术,因为它使他们能够规模远远超出了关系数据库的局限性。

 

我们也已经讨论了Solr文档的规范化的自然:数据必须重复冗余数据应用在每个文档。这可以特别有问题的数据在一个共享的领域在许多文件的变化。

 

假设您创建一个搜索引擎的社交网络用户配置文件和一个你的用户,与另一个用户John Doe,成为朋友叫可可。现在,我不仅需要更新约翰和可可的概要文件,但是我也需要更新“第二级连接”字段的约翰和可可的朋友,这可能代表数百文档更新一个基本操作:两个用户成为朋友。这让人们回到Solr的概念没有关系。

 

Solr的另一个限制是它主要作为document-storage机制;也就是说,您可以插入、删除和更新文档,而不是单一的领域(很容易)。Solr目前有一些最低限度的能力更新单个字段,但是只有字段是归结于这样一种方式,其原始值存储在索引,可以浪费。即便如此,Solr还更新整个文档的基础上重建索引的所有内部存储字段。这意味着,每当一个新领域添加到Solr或现有字段的内容变了,每一个文件吗在Solr索引之前必须完整地再加工的数据将被填充所有文件的新领域。许多其他的NoSQL系统遭受同样的问题,但值得注意的是,添加或改变整个语料库所有文档中的一个字段目前需要一个非平凡的document-update协调确保Solr,更新及时。

 

Solr还优化为一个特定的用例,它正在与小搜索查询数量的搜索词和快速查找每个术语来找到匹配文档,计算相关性分数和排序,然后只返回一个一些结果显示。Solr不是优化的处理很长时间查询(数以千计的术语)或相当大的结果集返回给用户。

 

最后一个Solr值得一提的是它的弹性可伸缩性:限制的能力自动添加和删除服务器和重新分配的内容来处理负载。虽然Solr尺度跨服务器,它不但是弹性伸缩本身全自动的方式。与SolrCloud最近的工作(在第13章)使用Apache饲养员集群管理是一个伟大的这个方向的第一步,但仍有许多功能工作了。例如,Solr还不能自动reshard其内容和增加索引副本的数量增长和查询负载动态处理内容。许多聪明的人在社区正在向这些长期的目标,然而,Solr继续越来越近,每一个版本。

3.5。总结

在这一章,我们讨论了关键搜索概念作为基础Solr的搜索功能。我们讨论了Solr的反向索引的结构如何映射文件条款,允许快速执行复杂的布尔查询。我们还讨论了如何使用模糊查询和短语查询位置信息拼写错误和变化相匹配的术语和短语Solr索引。

 

我们深入研究Solr相关性,布局默认Solr相关性公式使用和解释概念上每一块相关性得分是如何工作的以及为什么存在。

 

然后,我们提供了一个简短的概述的精度和召回的概念,它作为两种对立的力量在信息检索领域,为我们提供一个好的概念框架的判断我们的搜索结果是否会议我们的目标。

 

最后,我们讨论了如何Solr尺度的关键概念,包括讨论的内容反规范化文档内和分布式搜索,以确保查询可以并行执行维护或减少搜索时间,甚至随着内容的增加超出可以合理地处理一个单独的机器中。我们结束讨论思维的集群而不是服务器扩展搜索架构,我们看一些Solr的局限性和Solr可能不是一个用例伟大的健康。

 

 

在这一点上,你应该有所有必要的概念背景来理解Solr的核心特性在这本书的其余部分,应该有扎实的掌握最重要的概念需要构建一个杀手搜索应用程序。在接下来的一章,我们将开始挖掘Solr的关键配置设置,这将使更多细粒度控制的许多功能在本章中讨论。