第一章Solr简介

本章内容：

         数据由搜索引擎处理的特点

      通用搜索引擎的用例

      Solr的关键组件

      选择Solr的理由

      功能概述


与快速增长的技术,如社交媒体、云计算、移动应用程序和大数据,在性能上的挑战，这些都是激动人心的,。软件架构师所面临的主要挑战之一是在全球用户基础上处理海量巨大的消费和产生的数据,。此外,在线用户期望应用程序总是可用和即使响应的。解决可伸缩性和可用性需求的现代web应用程序中,我们看到越来越多的兴趣专业、非关系数据存储和处理技术,统称为NoSQL。这些系统有一个共同的设计模式匹配特定类型的数据存储和处理引擎而不是强迫所有数据使用once-standard关系模型。

换句话说,NoSQL技术优化解决一个特定类的问题为特定类型的数据。规模导致的需要混合架构组成的各种NoSQL和关系数据库,一去不复返了的日子放之四海而皆准的数据处理的解决方案。

 

这本书是关于Apache Solr,特定的NoSQL技术。Solr,正如它非关系弟兄,是为一个独特的优化类问题。具体来说,Solr是一个可伸缩的、便于部署的企业搜索引擎优化的搜索卷text-centric数据并返回结果按相关性排序。下面分解他的基本组成部分。

Scalable------ Solr尺度分配工作(索引和查询处理)多个服务器集群。

        Ready to deploy ----Solr是开源的,很容易安装和配置,提供了一个预配置的例子来帮助你开始。

优化搜索- Solr是快速和可以执行复杂的查询次秒级的速度,通常只有几十毫秒。

大量的文件- Solr旨在处理索引包含数以百万计的文件。

 Text-centric - Solr是优化搜索自然语言文本,如电子邮件、网页、简历、PDF文档和微博或博客等社会信息。

结果按相关度排序- Solr返回文档为基础的排名顺序每个文档是多么重要用户的查询。

 

在这本书中,您将了解如何使用Solr来设计和实现可伸缩的搜索解决方案。你将会学习和用例Solr支持的类型的数据。这将帮助您了解Solr融入现代应用程序的大局架构，Solr旨在解决这问题。

 

 

1.1。我为什么需要一个搜索引擎?

因为你看这本书,我们怀疑你已经知道为什么了你需要一个搜索引擎。而不是猜测你为什么考虑Solr,我们会使用合适的方式来回答你这个困难的问题，为了决定一个搜索引擎是否适合你。最后,它归结为了解您的数据和用户,选择一种有效的技术。让我们首先看的属性数据,搜索引擎优化处理。

1.1.1。管理text-centric数据

现代应用程序架构的一个特征匹配存储和处理引擎数据。如果你是一个程序员,你知道选择最好的数据结构基于你如何使用一个算法中的数据;也就是说,您不要使用链表你需要快速随机查找。同样的原则适用于搜索引擎。搜索像Solr的引擎优化处理数据表现出四个主要特点:

1。Text-centric

2。Read-dominant

3。面向文档的

4。灵活的模式

可能第五个特点是有大量的数据处理,即“大数据,“但我们的重点是让搜索引擎特别NoSQL技术。不用说,Solr可以处理大量数据。

 

尽管这些数据的四个主要特点,搜索引擎喜欢Solr处理有效,你应该认为它们是粗略的指导方针,而不是严格的规则。让我们挖每看到为什么他们重要的搜索。现在,我们将专注于高层概念,我们将进入“如何”在以后的章节。

 

Text-centric

毫无疑问你会遇到这个词非结构化用于描述数据的类型这是由一个搜索引擎。我们认为非结构化有点模糊,因为任何文本文档基于人类语言具有隐式结构。你能想到的非结构化从计算机的角度,认为文本流字符。字符流必须使用特定于语言的解析规则提取的结构和搜索,这正是搜索引擎。

 

我们认为text-centric更适合描述Solr处理的数据类型,因为搜索引擎是专门设计用于提取文本的隐含的结构到它的索引来提高搜索。Text-centric意味着文档的文本数据包含用户感兴趣的信息。当然,一个搜索引擎支持非文本数据,例如日期和数字,但它的主要力量是处理基于自然语言的文本数据。

 

中心部分章节是很重要的,因为如果用户不感兴趣的信息文本,搜索引擎可能不是最好的解决你的问题。考虑一个应用程序的员工创建旅行费用报告。每个报告都包含一个数量的结构化的数据字段,如日期、费用类型、货币和金额。在另外,每个费用可能包括一个notes字段,员工可以提供一个简短的费用的描述。这将是一个例子的数据包含文本,但不是text-centric,它不太可能,会计部门需要搜索笔记当生成月度费用报告。仅仅因为数据包含文本字段并不意味着数据是一个适合一个搜索引擎。

 

考虑您的数据是否是text-centric。是否考虑的主要问题中的文本字段数据包含用户想要查询的信息。如果是的,那么一个搜索引擎可能是一个不错的选择。您将看到如何解锁的文本结构使用Solr的文本分析能力在5和6章。

 

Read-dominant

另一个关键方面的数据,搜索引擎有效地处理数据read-dominant,因此为了有效地访问,而不是更新频繁。我们要清楚,Solr并允许您更新现有文档索引。认为read-dominant意味着文档阅读往往远远超过他们创建或更新。但这并不意味着你不能写大量的数据或你经常限制您可以编写新的数据。事实上,的一个关键接近实时的特性在Solr 4(NRT)搜索,你可以成千上万的索引文档每秒钟,让他们立即搜索”。

 

read-dominant数据背后的关键是,当你写数据到Solr,它的为了阅读和重读无数倍。认为一个搜索引擎被优化的执行查询(一个读操作),,而不是存储数据(一个写操作)。还有,如果你必须在一个搜索引擎更新现有数据通常,这可能表明一个搜索引擎可能不是你需求最好的解决方案。另一种NoSQL技术,如Cassandra,可能是一个更好的选择

你需要快速随机写入现有数据。

 

面向文档的

直到现在,我们已经谈到了数据,但是在现实中,搜索引擎使用的文档。在一个搜索引擎,一个文档是一个自包含的字段的集合,每个字段只有拥有数据和不包含嵌套的字段。换句话说,文档在搜索引擎像Solr平面结构和不依赖于其他文档。平坦的概念在Solr略有放松,在一个领域可以有多个值,不但是字段包含分支学科。你可以存储多个值在一个领域,但你不能窝字段

在其他领域。

 

,面向文档的方法在Solr的数据处理文档格式,如网页,博客,或PDF文档,但是建模归一化数据存储在关系数据库中?在这种情况下,您应该需要正规化数据分布在多个表成一个平面,独立的文档结构。我们将

学习如何处理这样的问题在第三章。

你也要考虑哪些字段必须存储在Solr和在你的文档应存储在另一个系统,如数据库。一个搜索引擎并不是存储数据的地方,除非是有用的搜索和显示结果;例如,如果您有一个在线视频的搜索索引,你不想在Solr中存储二进制视频文件。相反,大型二进制字段应该存储在另一个系统,如内容分布网络(CDN)。一般来说,你应该存储的最小集合为每个文档信息需要满足搜索需求。这是一个明确的的例子,不是治疗Solr一般数据存储技术;Solr的工作是发现感兴趣的视频,而不是管理大型二进制文件。

Flexible schema

搜索引擎数据最后的主要特征是,它有一个灵活的模式。这意味着在搜索索引文件不需要有一个统一的结构。在一个关系数据库中,表中的每一行都有相同的结构。Solr文档可以有不同的字段。当然,应该有一些字段之间的重叠在相同的索引文件,但它们不必是相同的。

 

想象一个搜索应用程序寻找房屋出租或出售。上市显然会分享等位置、数量的卧室和浴室的数量,但他们也会根据清单类型有不同的字段。房屋出售字段清单价格和年度房产税,而房子租金每月会有一个字段租金和宠物政策。

 

总之,搜索引擎一般和Solr特别是进行了优化处理数据有四个具体特点:text-centric read-dominant,面向文档的,和灵活的模式。总的来说,这意味着Solr不是一个通用的数据存储和处理技术。

 

拥有这样一个各种选择的要点是,存储和处理数据你没有找到一个放之四海而皆准的技术。搜索引擎擅长某些别人的东西,很可怕的。这意味着,在大多数情况下,你会发现这一点Solr互补关系和NoSQL数据库超过它取代他们。

 

既然我们已经讨论了Solr优化处理的数据的类型,让我们思考主要用例像Solr是专为搜索引擎。这些用例旨在帮助您了解如何不同于其他搜索引擎数据处理技术。

 

1.1.2。通用搜索引擎的用例

在本节中,我们看的事你可以去做一个搜索引擎。与我们的1.1.1节中讨论的类型的数据,使用这些指导方针,没有严格的规定。在我们进入细节之前,我们应该提醒你记住,好的卓越在搜索很高。现代用户习惯于等网络搜索引擎谷歌和必应被现代web-information需要快速和有效的服务。此外,最受欢迎的网站有帮助人们找到强大的搜索解决方案快速的信息。当你评估一个搜索引擎喜欢Solr和设计搜索解决方案,确保你把用户体验作为一个高优先级。

 

基本的关键字搜索

这一点显而易见指出,搜索引擎支持关键词搜索,这是它的主要目的,但值得一提的是,因为关键词搜索是最典型的用户将开始处理您的搜索方式的解决方案。这将是罕见的一个用户要填写一个复杂的搜索表单。考虑到基本的关键字搜索最常见的用户将与你的搜索引擎,它的原因此功能必须提供一个良好的用户体验。

 

一般来说,用户需要输入一些简单的关键字然后返回结果。这可能听起来像一个简单的任务匹配查询条件的文件,但考虑的几个必须解决的问题提供一个良好的用户体验:

•必须迅速返回相关的结果,在大多数情况下在2秒或者更少的时间返回。

•拼写校正是必要的,以防用户写错的一些查询条件。

•Autosuggestions保存按键,特别是对于移动应用程序。

•同义词的查询条件必须认可。

•包含查询术语的语言变体的文档必须匹配。

•词处理是必要的,也就是说,用户想要匹配所有文件单词或任何的单词短语。

•查询常用单词像“一”,“一个”,“的”和“必须处理正常。

•,如果结果不令人满意，应该返回top10结果或者更多的结果供用户选择。

 

正如您可以看到的,存在许多问题,使一个看似基本特征很难没有专门的方法实现。但与Solr等搜索引擎相比,这些功能,很容易实现。一旦你给用户一个强大工具来执行关键字搜索,您需要考虑如何显示结果。这给我们带来了我们的下一个用例:排名根据他们的相关用户的结果查询。

检索排序

搜索引擎是独立作为一种为一个查询返回“顶级”文档。在SQL查询到一个关系数据库中,一行匹配查询或者不,和结果基于一个或多个列进行排序。搜索引擎返回的文档进行排序降序排列的分数表示的强度匹配的文档查询。如何匹配计算的强度取决于许多因素,但总的来说更高的分数意味着文档更多相关查询。

 

排名文档的相关性是很重要的几个原因:

•现代搜索引擎通常存储大量的文档,经常数百万或数十亿的文档。没有排名文档与查询的相关性,用户可以成为超载的结果没有明确的导航方式。

•用户更熟悉和习惯的结果搜索引擎只使用一些关键字。用户是不耐烦和期望搜索引擎“做我的意思是,不是我说什么。“这是真正的搜索解决方案支持的移动应用程序,用户将进入短查询潜在的拼写错误和期望它简单的工作。

 

影响排名,您可以分配更多的重量,或提高,某些文件,字段,或特定条款。你可以提高结果的年龄对推动新文档搜索结果的顶部。您将了解排名在第三章的文件。

 

除了关键字搜索

与Solr等搜索引擎,用户可以输入几个关键字,为许多用户返回结果。,这仅仅是第一步的交互式会话

搜索结果给他们继续探索的能力。的主要用例之一搜索引擎来驱动一个information-discovery会话。频繁,用户不会确切地知道他们正在寻找什么,通常不知道什么信息包含在您的系统。一个好的搜索引擎可以帮助用户在他们狭窄信息需求


这里的中心思想是要从最初的查询,返回文档以及工具来帮助用户改进自己的搜索。换句话说,除了返回匹配的文档,你还返回工具,让用户了解下一步该做什么。例如,您可以分类搜索结果使用文档允许用户缩小他们的特性结果。这就是所谓的面向方面的搜索,Solr的主要优势之一。你会看到的一个例子在上雕琢平面的搜索房地产在1.2节。这方面都包含在在第8章。

 

不要使用一个搜索引擎……

让我们考虑一些用例中,搜索引擎也不会有用。首先,搜索发动机被设计成每查询返回一组文件,通常10 - 100。更多的文件相同的查询可以使用Solr的内置分页检索的支持。考虑一个查询相匹配的一百万个文档;如果你要求所有的文件回来一次,你应该准备好等待很长一段时间。查询本身可能会快速执行,但从基础索引重建一百万个文档结构将是极其缓慢的,就像引擎Solr字段存储在磁盘的格式它很容易创建一些文档,但它需要很长时间吗重建许多文档时产生的结果。

 

另一个用例中,您不应该使用一个搜索引擎是深度分析的任务需要访问大量的子集索引(除非你有很多的内存)。即使你避免之前的问题通过分页的结果,底层的数据结构搜索索引不是用于检索索引的很大一部分。

 

我们已经接触了这之前,但我们会重申,搜索引擎不是替换查询在文档之间的关系。Solr支持查询使用

27日亲子关系,但不支持导航复杂的关系结构与SQL是可能的。在第三章中,您将学习技术来适应关系数据使用Solr的平坦的文档结构。

 

同样, 至少Solr没有直接支持大多数搜索引擎文档级安全,。如果你需要细粒度权限文件,然后你必须

处理外部的搜索引擎。

 

 

现在,我们看到的数据类型和用例的搜索引擎是正确的(或错误)的解决方案,这是时间去探究什么Solr以及它如何在高水平。在下一节中,您将了解什么功能Solr提供以及它的方法等重要software-design原则与外部系统的集成,可伸缩性和高可用性。