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

 

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

 

 

本章涵盖了

• Solr有别于传统的数据库技术是什么

•Solr内部索引的基本结构

•Solr如何执行复杂查询使用术语、短语,和模糊匹配

•Solr如何计算分数匹配查询最相关的文档

•如何平衡返回相关结果和返回所有可能的结果

•如何模型内容到规范化的文档

•Solr跨服务器如何处理数十亿的文档和查询

 

现在我们已经Solr启动并运行,获得一个基本的了解是很重要的，搜索引擎如何运作,以及为什么你会选择使用Solr存储和检索你的内容。这一章我们的主要目标是提供理论基础,所以你能理解并最大化使用Solr。

 

如果你在搜索和信息检索有一个坚实的背景,那么您可能希望跳过这一章的部分或全部,但如果没有,它将帮助你了解更先进主题在这本书和最大化的质量用户的搜索体验

 

虽然在本章的内容通常是适用于大多数搜索引擎,我们会是特别关注Solr的每个概念的实现。这一章结尾,你应该有一个坚实的理解Solr的内部索引是如何工作的, Solr如何执行复杂的布尔和模糊查询,Solr的违约相关性如何评分模型作品,Solr的架构使查询保持最快的速度处理数十亿的文件在许多服务器。

 

让我们开始讨论背后的核心概念在Solr搜索,包括如何搜索索引,搜索引擎如何匹配查询和文档,以及如何Solr使强大的查询功能,以便使寻找内容的问题。

3.1。搜索、匹配和发现内容

许多不同种类的系统来帮助我们解决具有挑战性的数据存储和存在检索问题:关系数据库、键值存储- reduce引擎操作在磁盘上的文件,图形数据库,在许多其他人。搜索引擎,Solr特别有助于解决一个特定类的问题相当well-problems要求能搜索大量的非结构化文本和拉回相关的结果。

 

在本节中,我们将描述现代搜索引擎的核心功能,包括一个解释一个搜索“文档”,概述反向搜索索引的核心Solr的快速全文搜索功能,和一个广泛的概述如何倒排搜索索引允许任意复杂的词、短语和partial-matching查询。

3.1.1。一个文档是什么?

我们发布了一些文档Solr在第二章,然后运行示例搜索Solr,所以这不是我们第一次提到的文件。然而,它是我们充分理解的信息我们可以投入Solr搜索(文档)和如何结构化信息重要的。

 

Solr文档存储和检索引擎。每一个数据报Solr处理一个文档。一个文档可能是报纸的一篇文章中,简历或社会配置文件,或者在极端情况下,整本书。

 

每个文档包含一个或多个字段,每个被建模为一个特定的领域类型:字符串,标记化的文本、布尔值、日期/时间,纬度/经度等潜在的数量字段类型是无限的,因为一个字段类型是由零个或多个步骤,分析改变字段中的数据处理和映射到Solr索引。每个字段Solr中定义的模式(在第五章讨论)作为一个特定的字段类型,它允许Solr知道如何处理接收到的内容的。清单3.1显示了一个示例文档,为每个字段定义的值。

 

 

清单3.1。Solr示例文档

<doc>
<field name="id">company123</field>
<field name="companycity">Atlanta</field>
<field name="companystate">Georgia</field>
<field name="companyname">Code Monkeys R Us, LLC</field>
<field name="companydescription">we write lots of code</field>
<field name="lastmodified">2013-06-01T15:26:37Z</field>
</doc>

 当我们运行一个查询Solr,我们可以搜索一个或多个字段(甚至字段不包含在这个特定的文档),Solr将返回在这些字段包含内容匹配查询的文档。

 

 

 

值得注意的是,虽然Solr灵活的模式为每个文档,它不是“非模式化。“所有必须定义字段类型,字段名称(或动态field-naming模式)应该在Solr中指定schema.xml,我们将进一步讨论在第5章。这并不意味着每个文档必须包含各个领域,只有这一点所有可能的领域必须可映射到一个特定的字段类型应该出现在文档,需要处理。Solr包含自动猜测的能力以前看不见的字段名称的字段类型当它第一次收到的文档新字段名。这是通过检查字段和数据类型自动添加字段Solr的模式。因为Solr可能猜出错误的字段类型如果输入是混乱的,这是一个更好的实践来预先确定。

 

一个文档,是一集合字段映射到特定的字段类型中定义模式。文档中每个字段的内容分析根据其字段类型,和这种分析的结果保存到后来搜索索引来检索文档通过发送一个相关的查询。主要从Solr搜索结果返回查询文件包含一个或多个字段。

 

3.1.2。基本的搜索问题

 

在我们深入概述Solr搜索是如何工作的理解很有帮助搜索引擎要解决的基本问题。

 

 

 

比方说你是负责创建搜索功能,帮助用户搜索书。初始原型看起来如图3.1所示。

 

 

图3.1。示例搜索界面,会看到在一个典型的网站上,展示用户如何提交一个查询到您的应用程序

 

 

现在假设一个客户想找一本关于采购一个新家搜索买房。一些潜在相关书名你可能想要返回表3.1列出了。

表3.1。相关书籍查询“买房”

潜在的相关书籍

买房子的初学者的指南

如何购买你的第一个房子吗

潜在的相关书籍

买房

成为一个新的业主

买新房子

装饰你的家

 

其他书名,如表3.2所示,将不会被认为是相关的客户购买新房子感兴趣。

表3.2。书与查询无关的“买房”

无关紧要的书

一个有趣的烹饪指南

如何提高孩子的事情吗

买一辆新车

 

一个天真的方法来实现这种搜索使用传统的SQL数据库查询的用户输入的文本:

SELECT * FROM Books WHERE Name = 'buying a new home';

这种方法的问题是,在你的书的书名目录匹配文本,客户类型,这意味着他们将不会找到任何结果

对于这个查询。此外,客户只会看到未来的查询,如果查询的结果匹配准确完整的书名。

 

也许一个更宽容的方法是在一个客户的查询寻找每一个词:

SELECT * FROM Books

WHERE Name LIKE '%buying%'

AND Name LIKE '%a%'

AND Name LIKE '%home%';

 

前面的查询,虽然相对昂贵的传统数据库来处理因为它不能使用可用的数据库索引,至少会产生一个匹配客户包含所有所需的单词,如表3.3所示。

 

表3.3。结果从数据库查询要求的模糊匹配每个term

匹配的书	没有匹配的书
买新房子	买房子的初学者的指南
	如何购买你的第一个房子吗
	买房
	成为一个新的业主
	一个有趣的烹饪指南
	如何提高孩子的事情吗
	买一辆新车
	装饰你的家

 

当然,你可能会认为, 客户包括在他们的查询要求文档匹配你所有的单词过于严格的。您可以轻松地搜索体验更灵活的只需要一个词存在于任何匹配的书标题,通过发出以下SQL查询:

 

SELECT * FROM Books

WHERE Name LIKE '%buying%'

OR Name LIKE '%a%'

OR Name LIKE '%home%';

 

这个查询的结果中可以看到在表3.4。你会发现这个查询匹配很多比之前的查询书名因为该查询只需要最少的其中一个关键字匹配。此外,由于这个查询的方法是执行部分字符串匹配的每个关键字,任何书名包含字母“a”也返回。前面的示例,它要求所有的条款,也匹配字母“a”,但我们没有经历这个问题返回的结果,因为太多了另一个关键字更严格。

 

表3.4。结果从数据库查询只需要一个模糊匹配的至少一个term

匹配的书	没有匹配的书
一个有趣的烹饪指南	如何购买你的第一个房子吗
装饰你的家
如何提高孩子的事情吗
买一辆新车
买新房子
买房子的初学者的指南
买房
成为一个新的业主

第一个查询(要求所有单词匹配)导致了许多不相关的书籍发现;第二个查询(只需要其中一个单词匹配)导致了许多更相关的书被发现但导致许多无关紧要的书被发现好。

 

这些例子展示几个与这个实现的困难:

•它只执行子字符串匹配和无法区分单词。

•它不懂语言的变化,如“买”与“买”。

•它不理解同义词的单词,如“购买”和“采购”或家”和“房子。”

•不重要的词如“a”(防止结果匹配预期排除等相关结果或不相关的结果,这取决于是否“所有”或“任何”的单词必须匹配)。

•没有意义的相关性排序结果;只有一个匹配的书籍查询词经常出现高于匹配多个或全部的书在客户的查询。

 

随着图书目录的大小或数量客户查询的增长这些查询将变得缓慢,因为查询必须通过每一本书的标题找到扫描部分匹配,而不是使用索引来查找单词。

 

搜索引擎Solr照耀在解决此类问题。Solr是能够执行文本分析内容和搜索查询来确定文本相似的单词,理解和匹配同义词,删除不重要“,”这样的词“的”和“,”,得分每个结果基于传入的查询,以确保它匹配

 

最好的结果返回第一个,你的客户不需要页面无数less-relevant结果找到他们期望的内容。Solr完成所有这些通过使用地图内容的索引文件,而不是映射文件内容在传统的数据库模型。这种反向索引是搜索引擎如何工作的核心。

 

 

3.1.3。反向索引

 

Solr使用Lucene的反向索引其快速搜索功能,以及许多额外的,它提供的查询。虽然我们不会进入许多内部Lucene数据结构在这本书中,重要的是要了解的高层结构的反向索引。(我们建议Lucene in action,第二版,由迈克尔•麦卡Erik孵卵,奥蒂斯Gospodnetić[曼宁,2010]你可以看看)。

 

回忆我们以前book-searching的例子中,我们可以领略到一个索引每个术语映射到每个文档看起来就像从表3.5。

 

表3.5。将多个文档的文本映射到一个反向索引。正确的表包含一个反向搜索索引显示的每一个条款,

连同它的位置,在从左表原始文档。

原始文档	Lucene的反响索引
Doc	内容	Term	Doc	Continued
4 5 6	Cooking
7 8 9	Decorating Your Home How to Raise a Child Buying a New Car Buying a New Home The Beginner’s Guide to Buying a House Purchasing a Home Becoming a New Home Owner How to Buy Your First House	beginner’s buy buying car child cooking decorating first fun ...	8 6 9 4,5,6 4 3 1 2 9 1 ...	home house 2,5,7,8 how new 6,9 3,9 owner 4,5,8 8 purchasing 7 3 6 raise the to 1,6,9 your 2,9

 

而传统数据库的多个文档将包含一个表示文档的ID映射到一个或多个内容字段包含的所有单词/条款

文档,一个反向索引反转这个模型和地图每一个字/词语料库中,似乎所有的文档。你可以告诉从表3.5

,原始输入文本分割空间,每个术语转换成小写字母文本前插入到反向索引,但一切仍相同的。值得注意的是,许多额外的文本转换是可能的,不是只是这些简单的;术语可以被修改,补充说,期间或删除本文的过程,这将在第六章中详细介绍。

 

反向索引两个最终重要的细节应该注意的:

•所有term在索引映射到一个或多个文件。

•在反向索引是辞典编纂的升序排列。

 

这一观点的反向索引是大大简化;3.1.6节中我们将看到这一点附加信息可以存储在索引来提高Solr的查询和得分能力。

 

 

在下一节中您将看到,Lucene的反向索引的结构允许许多强大的查询功能, 关键字搜索最大化的速度和灵活性。