第一章 Solr 简单介绍
本章速览：
·搜索引擎处理的数据特性
·常见搜索引擎用例
·Solr核心模块介绍
·选择Solr的理由
·功能概述
伴随着社交媒体、云计算、移动互联网和大数据等技术的快速发展。我们正迎来一个令人激动的计算时代。软件架构师们開始面对的主要挑战之中的一个，便是怎样处理全球巨大的用户基数所产生及使用的海量数据。此外，用户们開始期待在线软件应用永远都是稳定可用的。而且可以一直保持响应，这相应用就提出了更高的可扩展性和稳定性需求。为了满足这些需求，一些专用的非关系型数据存储及处理技术，统称为NoSQL（Not
Only SQL）技术。開始获得越来越多的青睐。这些系统并不强制要求将全部的数据都存储在以前成为其实标准的关系型数据模型其中。而是共用了一个通用的设计模式。在数据存储处理引擎和特定的数据类型之间进行匹配。换句话说，NoSQL技术为处理特定数据类型的特定类别问题做了性能优化。因为对可扩展性的需求和性能的需求不断添加，导致各种NoSQL技术和传统关系型数据库開始混合使用。这样的跨界架构变得越来越流行。
过去那种一种数据处理方案就能吃遍天下的时代已经一去不复返了。
本书主要讨论一种特殊的NoSQL技术。即Apache Solr。和她的其它非关系型兄弟们一样，Solr也为一类特定问题的处理做了优化。详细来说，Solr 是一个可扩展的，可高速部署的，对搜索海量文本中心的数据和对返回结果做相关性排序方面做了优化的企业级搜索引擎。
这句话读上去有点拗口。只是没关系。我们把这个定义中的亮点分解出来看：
·可扩展性：Solr能够把建立索引和查询处理的运算分布到一个集群内的多台server上。
·高速部署：Solr是开源软件，安装和配置都非常方便，能够依据安装包内的Sample配置直接上手。
·优化的搜索功能：Solr搜索够快。对于复杂的搜索查询，Solr能够做到亚秒级的处理。通常几十毫秒就能处理完一次复杂查询
·海量文本：Solr是针对百万级以上的海量文本处理而设计的，能够非常好地处理海量数据。
·文本中心的数据：Solr为搜索包括自然语言的文本内容做了优化，比方电子邮件。网页，简历，PDF文档，或是推特、微博、博客这些社交内容等等。都适合用Solr来处理。
·结果是按相关性排序的：Solr的搜索返回结果是依照结果文档与用户查询之间的相关程度度做排序的，保证最相关的结果会优先返回。
在本书中，你将学到怎样使用Solr来设计实现一个可扩展的搜索方案。
我们的学习旅程从了解Solr支持的数据类型和典型用例開始。
这样你能更好的理解在整个现代软件应用架构全景图中Solr所处的位置，以及Solr究竟是设计来处理哪些问题的。
1.1我究竟须要一个搜索引擎吗？
我们推測你已经有了些想法要准备使用搜索引擎了，否则你也不会翻开这本书。因此。我们就不浪费时间来揣度你究竟是为什么開始考虑用Solr的了，我们直接来讨论点干货。看看关于你的数据和用例方面。 有哪些问题是你在决定是否使用搜索引擎之前所必需要回答的。这终于会归结为怎样深刻理解你的数据和你的用户。以选用一个合适的技术来同一时候满足二者的需求。
我们先从讨论一下哪些数据属性是搜索引擎适合处理的。
-
1.1.1 管理文本中心的数据
合理选用同数据匹配的存储及处理引擎，是现代软件应用架构的标志性要求之中的一个。假设你是一个优秀的程序猿，那么你应该知道要依据在算法中使用数据的方式来选取最合适的数据结构。比方，假设你须要实现高速随机查找，你就不会使用链表结构来存储数据。
相同的道理也适用于搜索引擎的选取。这里列出了适合用类似Solr这种搜索引擎来处理的数据的4种主要特点：
-
文本中心的数据
-
读取远多于写入的数据
-
面向文档的数据
-
灵活的Schema
或许在这儿应该加上第五个数据特性，即：海量数的据量。也就是”大数据“，可是我们主要关注的是Solr差别于其它NoSQL技术的主要特性。而能够处理海量的数据并非它们的主要差别之中的一个。
尽管这里列出了类似Solr这种搜索引擎能够有效处理的数据类型的4个主要特点，可是这仅仅是一个粗略的准则，并非一个严格的标准。
我们来深入的讨论一下这些数据特性，看看为什么它们对于搜索来说这么重要。我们如今仅仅关注概念，详细的实现细节在稍后的章节讨论。
文本中心的数据
你肯定见过有人用“非结构化数据“这个术语来描写叙述搜索引擎处理的数据。我们觉得“非结构化”这个词有些模糊不清，由于不论什么一个基于人类语言产生的文档都是隐含有一定的结构的。
要理解“非结构化”这个术语你能够觉得这是从计算机的角度来看的。
在计算机眼中，文本文档就是一个字符流。这个字符流必须通过特定的语言规则解析出语义结构。才干被检索到。而这正是搜索引擎的工作所在。
我们觉得“文本中心的数据”这个词更适合用来描写叙述Solr处理的数据类型。由于搜索引擎的设计初衷就是用来提取文本数据的隐含结构，并生成相关索引以提高查询检索的效率。“文本中心的数据”这个词隐含表明了文档中的文本信息包括用户感兴趣的查询内容。
当然，搜索引擎也支持非文本数据，比方数字类型的数据。可是其主要强项，还是在于处理基于自然语言的文本数据。
前面说的都是“文本”。事实上“中心”这个部分也非常重要，由于假设你的用户对于文本部分的内容不感兴趣，那么搜索引擎可能就不是处理你的问题的最佳选择。举个样例，对于一个给员工用来创建差旅支出报告的应用，每份报告都包括一些结构化的数据，比方日期。费用类型，汇率，数量等等，另外每项费用后面可能会包括一些备注信息。用于描写叙述该项费用的大致情况。
这样一个应用就是一个包括文本信息。但并非“文本中心的数据”的一个样例。由于会计部门在使用这些员工的支出费用报告来生成月度支出报告时，并不会通过查找备注里的文本信息来做，文本在这里并非其关心的主要内容。简单来说。就是不是全部包括文本信息的数据都适合搜索引擎来处理。
所以如今先花几分钟好好想想你的数据是否是“文本中心的数据”。考虑的重点主要就是数据中的文本信息用户是不是会拿来做检索。
假设答案是YES，那么搜索引擎非常可能是一个好的方案选择。
我们在第5章和第6章会讨论怎样利用Solr的文本分析来提取文本数据的结构的细节。
读取远多于写入的数据:
另外一个搜索引擎能够高效处理的数据特性是“读取远多于写入的数据”。首先，须要声明的是Solr是同意你更新索引中的现有文档内容的。你能够把“读取远多于写入”解读为对于文档的读取操作频率要远远高于创建文档和更新文档的频率。可是别狭隘的理解为你就全然不能写入数据了，或是你会被限制在一个特定频率之下更新数据。其实Solr4的一个关键特性就是“近乎实时的查询”。这个功能能够同意你每秒钟为数千的文档建立索引而且差点儿立马就能查询到这些新增加的文档。
“读取远多于写入的数据”背后的关键点是你的数据在写入Solr后，在其生命周期内应该是要被反复读取非常多次的。
你能够理解为搜索引擎并非主要用来存储数据的。而是主要用于查询存储的数据的（查询请求是一种读取操作）。所以假设你须要非常频繁的更新数据。那么搜索引擎可能不太适合你的需求，其它的NoSQL技术，比方Cassandra，可能更适合你的高速随机写入的需求。
面向文档的数据
到眼下为止，我们一直使用更通用的“数据”这一术语，可是实际中搜索引擎处理的都是文档数据。在搜索引擎中。一个文档是由值域(field)组成的独立集合，每个值域都仅仅保存数据值。不能再嵌套包括其它值域。换句话说。在Solr这种搜索引擎中，文档都是扁平结构的，文档之间不存在相互依赖关系。Solr中“扁平”的概念是比較宽松的。一个值域能够保存多个数据值，可是值域不能再嵌套包括子值域。
也就是说你能够在一个值域里存储多个数据值。可是你不能往值域里头嵌套别的值域。
Solr中这样的扁平化的、面向文档的方式能够非常好的处理已经文档化的数据。比方网页，博客。pdf文档等等。那么假设要用solr来处理关系型数据库中已经结构化好的数据应该怎么办呢？这样的情况下你须要先把关系型数据库中跨表存储的数据取出来，去结构化。然后放到扁平化的自包括文档结构里。我们会在第三章学习怎么处理这样的问题。
你还须要考虑你的文档数据中的哪些值域须要存储在Solr中，哪些值域须要存储在其它系统中（比方数据库中）。简单来说。搜索引擎仅仅存储须要被检索到的数据，以及用于显示检索结果的数据。
举个样例。假设你有一个在线视频的搜索索引。你应该不会希望把视频文件本身存储在Solr中。合理的方案应该是把大的视频文件都放在内容分发网络（CDN）中。通常你仅仅须要在搜索引擎中存储满足搜索需求的最少数据就可以。刚才这个在线视频的样例清楚的说明了不要把Solr当成通用数据存储技术，Solr的工作是找到用户感兴趣的视频文件，而不是存储视频文件本身。
灵活的Schema
最后一个搜索引擎数据的主要特性是有灵活的schema。
这意味着查询索引中的文档不须要拥有统一的结构。在关系型数据库中，表中的每一行数据都必须拥有同样的结构。而在Solr中，文档们能够有不同的值域。当然同一个索引中的文档们至少应该拥有一部分大家都有的值域以便于检索，可是并不要求全部文档中的值域结构全然一样。
举个样例。假如要做一个用于查找出租和出售房源的搜索应用。显然每条房源文档都会有地段。房间数，卫生间数等一些共同拥有的值域，可是依据类型是出租还是出售的不同。不同的房源文档会有不同的值域。一条出售的房源会有售价值域，財产税值域。而一条出租的房源文档则会有月租金和宠物政策等等不同的值域。
总结一下，Solr这种搜索引擎是专门优化用于处理文本中心的，读取远多于写入的，面向文档的。拥有灵活Schema的数据用的。Solr并非一种通用数据存储处理技术，这也是差别于其它NoSQL技术的主要因素。
有众多不同的数据存储和处理方案可供选择的优点是你不再须要费劲脑汁地寻找一种能够满足全部需求的通用技术方案。搜索引擎在某些特定任务上表现出色。可是在其它一些方面性能非常差。这意味着在大多数情况下，你能够用Solr来作为关系型数据库和其它NoSQL技术的有力补充，而并非要代替后者。
既然我们已经谈到了Solr所针对优化处理的数据类型，那我们就接着来讨论一下像solr这种搜索引擎主要是设计来解决哪些实际用例的。
理解这些用例能够帮助你理解搜索引擎技术是怎样差别于其它数据处理技术的。
-
1.1.2 常见的搜索引擎用例
在这一节中，我们来看看Solr这种搜索引擎都能干些什么。正如我们在1.1.1节中所提到的那样。这些讨论仅仅是一种指南性质的建议，不要把它们当成严格的使用规则来看。在我们開始之前。你须要意识到想做出一个优秀的搜索服务，其门槛是非常高的。
如今的用户都习惯于使用像Google和Bing这样又快又高效的网络搜索引擎。而非常多受欢迎的站点也有自己强大的搜索方案来帮助用户高速的获取想要的信息， 所以用户对搜索服务并不陌生而且会非常的挑剔。当你在评估像Solr这种搜索引擎时，或是在设计你自己的搜索方案时，一定要有根弦儿。要把用户体验放在高优先级上来考虑。
主要的keyword查询
非常明显，作为一个搜索引擎来说， 首先必需要可以支持主要的关键词查询。
这也是搜索引擎的主要功能之中的一个。只是关键词查询功能还是值得在这里强调一下的，由于这是用户使用搜索引擎最典型的方式。
非常少实用户想要会一上来就填写一个非常完整的复杂搜索表单来进行搜索的。考虑到关键词搜索功能将会是用户和你的搜索引擎之间最常见的交互方式。这个基本功能必须可以提供给用户以非常好的用户体验才行。
一般来说，用户希望仅仅输入几个简单的关键词就能获取到非常好的搜索结果。
这或许听上去像是一个简单的匹配任务：把查询字串和文档进行匹配就可以。只是请考虑一下要实现良好的用户体验所必须解决的几个问题：
· 相关结果必须迅速返回，大多数情况下要求一秒钟之内就行返回
· 用户的查询字串出现拼写错误时可以自己主动纠错
· 用户输入时通过自己主动补全建议来降低用户的输入负担，这在移动应用中非经常见
· 处理查询字串中的同义词近义词
· 对包括查询字串的语言变异的文档进行匹配（译者注：语言变异是语义学术语，即用词不全然一样的近似表达）
· 短语处理。用户是希望匹配短语中全部的单词，还是仅仅要匹配短语中的部分单词即可
· 对一些通用介词的处理，比方“a,” “an”, “of”, “the”等等
· 假设最靠前的查询结果用户不惬意。 怎样给用户返回很多其它的查询结果
就像你看到的那样，不使用特定的处理方法的话。这样一堆问题会使得看上去如此简单的功能实现起来变得非常困难。然而利用像Solr这种搜索引擎，这些功能就能立等可取，实现起来变得非常easy。当你给用户提供了一个强大的关键词搜索工具之后，接下来你就须要考虑怎样去展示查询的结果，这就引出了下一个用例，依照结果同查询请求之间的相关性顺序。对搜索返回的查询结果进行排序。
排序的检索结果
搜索引擎为查询返回“最靠前“的结果。在SQL查询关系型数据库的时候，某一行数据记录要么匹配查询被返回，要么不匹配查询被忽略，查询结果也是依照数据记录的某一列属性来排序的。而对于搜索引擎来说，返回的结果文档是依照得分做降序排列的。该得分表示文档和查询的匹配程度。匹配程度得分根据一系列的因子来计算。只是一般说来得分越高。表明结果文档同查询之间的相关度越高。
有好几个因素决定了将结果文档依照相关度排序的方式非常重要。首先，现代搜索引擎一般都存储着海量的文档，都是上百万甚至数十亿记的。假设不正确查询结果进行相关度排序。那用户就会被海量的返回结果所淹没，无法清晰有效的浏览搜索的结果。其次。用户使用其它搜索引擎的经验使得用户已经习惯于使用少数的几个关键词就能获得不错的查询结果。也使得用户普遍比較缺乏耐心。
他们会期待搜索引擎依照他们想要的意思来工作，而无论其所输入的信息是否全然正确。比方对于移动应用的后台搜索服务来说，用户会期待在输入了简短的几个可能还包括有拼写错误的查询词之后，搜索服务就行返回正确的搜索结果。
假设要人工干预排序的结果，你能够给特定的文档、值域、或者查询字串添加权重，或着直接提高某个文档的相关度分值。比方你假设希望把新添加的文档推送到最靠前的位置，就能够通过依照创建时间来提高文档排序的方式实现。我们在第三章中会学习关于文档排序的知识。
除了关键词查询之外
利用像Solr这种搜索引擎，用户能够输入少数几个关键词就能获取到一些搜索结果。然而对于非常多用户来说这不过一个查询交互的第一步。他们须要在查询结果中能够继续地浏览。驱动一个信息发现的交互会话过程也是搜素引擎的一个主要应用场景。通经常使用户在搜索前并非非常精确的知道想要查询的信息什么样的。他们事先也不知道你的系统中究竟存储了哪些信息。一个好的搜索引擎能够帮助用户不断地细化信息需求，一步步到达最须要的信息。
这里的核心思想是在返回用户最初的查询所相应的文档结果的同一时候，提供给用户一个工具，使其可以不断地改进查询以获得更须要的信息。换句话说。在返回匹配的文档之外，你应该返回一个工具让用户知道下一步该怎么办。举个样例。你可以对查询结果依照属性进行分类，便于用户依据需求做进一步的浏览。
这样的功能称之为分类检索（Faceted-Search），这也是Solr的功能亮点之中的一个。
我们会在1.2节中看到一个关于房地产的分类检索实例，在第八章中会具体介绍分类检索功能的细节。
搜索引擎不适合做的事…
最后。我们来讨论一下不适合应用搜索引擎的一些用例场景。
首先。搜索引擎一般的设计是，为每一个查询返回一个小的文档集，通常包括10个到100个的结果文档。很多其它的结果文档可以通过Solr自带的结果分页功能来获取。对于一个查询结果有好几百万个文档的情况。假设你要求全部的匹配文档都要可以一次返回，那么你会等待非常长的时间。
查询本身会运行的非常快，可是从索引结构中重建上百万的文档绝对是一件非常耗时间的事情。由于Solr这种搜索引擎在硬盘上存储值域的方式仅仅适用于高速生成少量的文档结果，假设须要一次生成大量的查询结果。在这种存储方式之下生成大量文档结果就会耗费大量的时间。
还有一个不适合应用搜索引擎的使用场景是须要读取索引文件的大部分子集的才干完毕的深度分析任务场景。
即使你通过结果分页技术避免了刚刚说的那个问题。假设一次分析须要读取索引文件里的大量数据。你也会遇到非常大的性能问题，由于索引文件的底层数据结构就不是为一次大量读取来设计的。
我们前面有提到过一点。可是在这里还是要再次强调一下。那就是搜索引擎技术并不适合用于在文档的相互关系之间进行查询。Solr确实是能够支持基于父子关系的查询。可是并不支持在复杂的关系型数据结构之间查询。在第三章。你会学习到怎样将关系型数据结构适配到适合solr处理的扁平型文档结构中进行查询。
最后，绝大多数搜索引擎都没有直接的文档级安全支持，至少Solr是没有。
假设你须要严格管理文档的权限，那你仅仅能在搜索引擎之外来想办法。
到这里我们已经了解了适合搜索引擎处理的用例场景和数据类型，下一步该是时候讨论Solr究竟能做些什么。以及这些功能是怎样实现的了。在下一节中，你将学习到Solr究竟有哪些主要功能。以及她是怎样实现外部系统集成、可扩展性、以及高可用性等软件设计原则的。
