-
Solr究竟是什么？
在本节中，我们通过从头设计一个搜索应用来介绍Solr的关键组件。这个过程将有助于你理解Solr的功能，以及设计这些功能的初衷。只是在我们開始介绍Solr的功能特性之前，还是要先澄清一下Solr并不具有的一些性质：
1） Solr并非一个像Google或是Bing那样的web搜索引擎
2） Solr和站点优化中常常提到的搜索引擎SEO优化没有不论什么关系
好了。如今如果我们准备为潜在的购房客户设计一个不动产搜索的网络应用。该应用的核心用例场景是通过网页浏览器来搜索全美国范围内的房子。图1.1描写叙述了这个虚拟应用的界面截图。
不用太在意UI界面的简陋，这仅仅是一个便于我们讨论的可视化模型。重点是通过这个样例，我们来看看Solr究竟能够提供哪些类型的搜索体验。
让我们先高速浏览一下图1.1描绘了哪些Solr的关键特性。
我们从左上角開始。沿顺时针方向看。首先。Solr提供了强大的功能来支持keyword搜索框。正如我们在1.1.2中讨论的那样，一个表现出色的keyword搜索功能，须要背后强大的复杂架构的支持。
好在Solr所提供的这个复杂架构能够迅速的安装使用。
详细来说，Solr提供了拼写检查功能、用户输入的自己主动补全建议功能、同义词近义词处理功能、短语查询功能、以及用于处理类似”buying a house“和”purchase a home“这种语言变异的文本分析功能。
此外Solr也提供了强大的地理位置查询功能。在图1.1中，符合查询条件的房屋列表在地图上依照与指定坐标点中心的经纬度距离的远近显示出来。依靠Solr的地理位置支持，你能够根据地理位置的距离来进行查询，甚至能够根据地理位置的远近对文档结果进行排序。对于地理位置查询来说，高速地返回搜索结果。以及同意用户通过在地图上缩放或移动地图上的位置来进行新的查询，这些功能都非常重要。
一旦用户发起了一个查询。其查询结果就能够依靠Solr的分类检索功能来依照结果文档集的不同特性进行分类显示，这样更便于用户浏览搜索返回的结果。分类检索是一种将结果集按特性分类显示的方法，能够帮助用户进一步的细化查询已获得更加符合自己需求的信息。
在图1.1中，查询结果依照房屋特征，房型和文件夹类型进行了分类显示。
如今我们对于房地产查询应用应该支持哪些功能有了一个主要的了解。接下来我们来看看怎样利用Solr来实现这些功能特性。
首先我们须要弄清楚Solr是怎么在索引中的房屋列表和用户的查询之间进行匹配的。这一原理也是全部搜索应用的基础。
-
1.1.1 信息检索引擎
Solr是在Apache 下大名鼎鼎的Java开源信息检索库Lucene的基础之上开发出来的。在第三章中会具体讨论什么是信息检索。
如今我们先看看一篇关于现代搜索引擎概念的权威学术论文是怎样定义信息检索的。从中我们能够了解到一些关键的概念：
信息检索（IR）是指从海量的数据集合（通常存储在计算机系统中）中。依据某种非结构化的本质属性（一般是文本内容）查找出满足信息需求的材料（一般是文档） 的过程。
---摘自信息检索简单介绍，曼宁出版社2008年出版
在我们的房地产搜索应用中。用户的主要信息需求是依据地段、房型、房屋功能特性、还有价格这些因素来查找要购买的房子。我们的索引包括了全美全部的房源，绝对算的上是“海量“数据了。 简而言之，Solr利用Lucene提供的核心架构。对文档建立索引。处理查询请求。实现文档的搜索功能。
Lucene底层用JAVA实现倒排索引的建立和管理。
倒排索引即倒排表。是用于匹配文本查询的特殊数据结构。图1.2展示了我们的房地产搜索应用中所用的到的Lucene 倒排索引的简要示意图。
在第三章中你将具体地学习到倒排索引是怎样工作的。可是如今看懂图1.2中的内容就足够了。这里展现的是一条新的文档记录（图中的第44号记录）增加到索引文件里的过程。以及文档是怎样通过倒排索引进行查询匹配的过程。
你或许在想，这不是利用关系型数据库中的SQL语句也能做到吗？对于这个简单的样例来说是这种。可是Lucene索引查询和数据库查询的一个关键差别是：在Lucene中。查询结果是依照与查询的匹配程度排序的，而数据库查询的结果则仅仅能根据数据表中的某一列属性进行排序。
换句话说。根据相关性对结果进行排序是信息检索的一个关键特性，也是差别于其它查询的重要特征。
-建立全网数据的倒排索引
你或许会感觉到吃惊。由于像Google那样的搜索引擎也是利用倒排索引来查询网页的。其实，建立全网数据的倒排索引的需求，直接导致了MapReduce技术的产生。
MApReduce是一个编程模型，通过Map和reduce两个阶段，将大规模的数据处理操作分配到商用机server集群上去，实现分布式执行。Google利用MapReduce技术来建立其巨大的倒排索引，用以支撑网络查询的需求。
在使用MapReduce技术时，先在Map阶段生成一系列的数据段并在全部数据段出现的地方标上该数据段唯一的文档ID。在Reduce阶段。全部数据段会做排序，拥有同样文档ID的数据段会被发送到同一个reducer进行处理，这样reducer会加和全部拥有同一文档ID的数据段，为之建立倒排索引。
Apache的Hadoop项目就提供了一个开源的Mapreduce实现，而且Apache Nutch开源项目就是用Hadoop来为全网数据的查询建立Lucene倒排索引。
关于Haddop和Nutch的讨论超出了本书的范围。只是我们建议读者最好还是去研究一下这些开源项目，会对你建立大规模的搜索索引有帮助的。
如今我们知道了Lucene为搜索提供了核心的架构，那么让我们看看Solr在Lucene之上又附加了哪些价值。
我们从使用Solr灵活的schema.xml配置文件来管理索引建立的方式開始。
-
1.1.2 灵活的Schema管理
尽管Lucene提供了建立文档索引和运行查询的核心架构， 但它并没有提供一个方便的接口来设置索引应该怎样建立。
要使用Lucene，你须要写一些JAVA代码来定义值域。还要定义怎样分析这些值域。而Solr则提供了简单的声明方式来定义索引的结构，你也能够依照需求来指定怎样分析索引中的值域。这一切都能够通过一个名叫schema.xml的XML配置文件来完毕。Solr在其底层实现中将schema.xml中的配置翻译成Lucene的index。
这样的方式节省了你编程的时间，也使得你的索引结构更加可读。另外一方面，Solr建立的索引与编程实现的Lucene索引是百分之中的一个百兼容的。
此外Solr在核心的Lucene索引功能之上还加入了其它一些不错的功能。详细来说，Solr提供了Copy Fields和Dynamic Fields两种新的值域类型。Copy Fields提供了一种方法，能够将一个或多个值域中的原始文本内容赋值到还有一个新的field值域中。Dynamic Fields则同意你无须在schema.xml里显式的声明。就能够将同一值域类型赋予多个不同的值域。这在为拥有多个值域的文档建立模型时很实用。我们将在第五章和第六章中深入介绍schema.xml文件。
在我们的房地产搜索应用中，你可能会吃惊于我们没对Solr的演示样例schema.xml做不论什么改动就直接使用了。
这事实上恰好展示了Solr的schema配置是多么的灵活，应为Solr的演示样例schem是为产品搜索设计的，可是我们的房地产搜索应用拿过来一样能够直接使用。
到眼下为止，我们知道了Lucene提供了强大的搜索库，用以支持文档索引的建立。运行查询，以及对结果进行排序。
还有，利用schema.xml，你可以灵活的定义索引结构。仅仅须要改动XML配置就可以。不须要针对LuceneAPI进行编程。
接下来你须要可以通过网络来获取这些服务。所以在下一节，我们就来学习Solr作为Java web应用是怎样执行的。以及她是怎样通过XML。JSON,HTTP等标准技术来与其它系统集成在一起的。
-
1.1.3 Java web应用
Solr作为一个Java web应用，既能够执行在随意一个现代JAVA Servlet引擎之上，比方Jetty或是Tomcat，也能够执行在JBoss或是Oracle AS之类的完整的J2EE应用server上。图1.3展示了Solrserver的主要软件模块。
图1.3可能在第一眼看上去时显得内容有点多。我们能够花点时间先过一遍，先熟悉熟悉名词和术语。假设有看不懂的术语或是概念也不用操心。等你读完本书的时候，图1.3中的全部概念和术语你都会有非常深的理解。
正如我们在本章开头介绍中所提到的那样， Solr的设计者们指出Solr非常适合集成到现有的系统中，作为现有系统的一个有力补充。
其实，你非常难找出一个Solr无法集成进去的系统。
正如我们将在第二章里看到的那样。你在下载Solr之后仅仅须要花上几分钟，就能够启动一个演示样例的Solr系统了。
为了达到易于集成的目标，Solr的核心服务须要可以被不同的应用和编程语言訪问。Solr提供简单的类REST服务。支持XML。JSON，HTTP等标准。顺便说一句，我们并不使用RESTFul一词来描写叙述Solr基于HTTP的 API。由于它并不严格遵守全部的REST(Representatonal state transfer)原则。比如，在Solr中会用到HTTP POST来删除文档。而不是用HTTP DELETE。
类REST的接口对于基本功能来说已经足够好用了。可是开发人员们常常会希望可以用自己熟悉的编程语言来编写一些调用网络服务和处理返回的模版化工具。好消息是针对很多流行的编程语言。Solr都提供了对应的库，包含Python， JAVA, .NET, 还有Ruby等等。
-
1.1.4 同一server上建立多份索引
现代软件应用架构的一个显著特点就是面对高速变化的需求的灵活性。Solr在这方面有个非常实用的特性，就是你不必仅仅通过一份单一的索引来完毕Solr中全部的任务。Solr支持在单一的Solr 引擎上执行多个Solr 核心。在图1.3中， 我们描写叙述了多个solr核心在同一个Java web应用环境中作为不同的层同一时候执行的场景。
每个核心都有一个独立的索引和配置，在一个Solr实例中能够存在多个Solr 核心。这样你仅仅须要一个Solrserver就能够管理多个核心， 能够方便的实现server资源共享，以及及监控维护服务的共享。Solr有专门的API用于创建和管理多个Core。
Solr多核心支持功能的一个应用是数据分区，比方用一个core来负责近期更新的文档，而用另外的core来处理之前生成的文档。这个功能被称为按时间顺序分片。
在我们的房地产搜索应用中。我们也能够使用多个core来分别处理不同的类型的房屋资源，每一类用一个单独的索引文件来管理。
比方说针对农村用地的房地产信息来说，买一块农业用地的流程和买一套商品房的流程是不同的。我们全然能够用一个单独的索引来管理农业用地的相关信息，将其保存在一个单独的core里。
-
1.1.5 可扩展性（通过插件扩展功能）
图1.3展示了Solr种最基本的三个子系统：文档管理，查询处理，和文本分析。当然。这些子系统是对Solr中复杂的子系统所做的宏观抽象。我们会在稍后的章节中一一研究这些子系统。这当中的每个都是由一系列功能模块的流水线串成的。你能够在流水线中串入新的功能模块。
这意味着假设你想给solr增加新的功能的话，根本不须要重写整个查询处理引擎，仅仅须要在合适的位置串入自己的新功能模块就可以。这样一来Solr的核心功能模块扩展和定制起来都非常方便。能够全然依照你的特定应用需求进行定制。
-
1.1.6 可伸缩性
Lucene是一个查询速度很快的搜索库。而Solr全然发挥出了Lucene的强劲性能。
可是抛开Lucene的性能不谈，作为一个server来说，因为CPU和I/O的限制，同一时刻可以响应的用户数和请求数都是有限制的。
Solr实现可伸缩性的第一张牌是灵活的cache管理功能。该功能能够避免server反复进行耗费资源的操作。详细来说就是Solr预先设置了一些cache来节省开销非常大的反复计算。比方Solr会缓存查询过滤器的计算结果。
我们会在第四章学习Solr的缓存管理功能。
缓存的作用是有限的。为了处理很多其它的文档和获得更高的查询吞吐能力，你须要可以通过扩展server来横向扩展系统的性能。
如今我们来研究一下Solr扩展时最常见的两个方面。
第一个是查询的吞吐能力扩展，也就是你的引擎每秒钟可以处理的最大查询数是多少。
尽管Lucene可以非常快的处理每个查询请求。单台服务可以同一时候并发处理的请求出还是会限制总体的查询吞吐能力。假设须要得到更高的查询吞吐能力，你须要添加查询server和索引的拷贝数量。以便让很多其它的server来同一时候处理很多其它的请求。
这意味着假设你的索引拷贝到了三台server上。那么你每秒钟大约可以处理原来三倍的请求数量，由于每台server如今的负荷是总的查询量的三分之中的一个。在实际应用中非常少可以获得如此完美的现行扩展能力，所以使用三台server可能大约能达到原来2.5倍左右的性能。
还有一个扩展维度是被索引的文档数。假设你正在处理海量的文档， 那么当单个Solr实例中索引的文件数量多到一定程度的时候，查询性能的瓶颈也会出现。解决的方案是能够把索引文件切分成一个个被称为“分片”的小块，然后把查询请求分布到这些分片上进行操作。
使用虚拟化的商用硬件进行扩展
现代计算机技术的一个趋势就是构建能够在虚拟化的商用硬件上进行横向扩展的软件架构。
简单来说。就是能够通过加入普通的商用机server就能够处理很多其它的流量。类似于Amazon EC2这种云计算服务提供商通过使用虚拟化的商用硬件来满足这种趋势的需求。尽管Solr能够再虚拟化硬件上执行。可是须要注意的是Solr对于I/O和内存非常敏感。
因此。假设在你的企业中搜索性能被放到了最高优先级来考虑，那你应该考虑在配备有高性能磁盘（比方SSD固态硬盘）的高端硬件上去部署Solr。部署Solr时硬件方面须要考虑的问题将会在第13章中进行讨论。
可伸缩性非常重要，可是出错后的自己主动恢复能力在现代系统中也非常重要。
在下一节中。我们来讨论一下Solr是怎样处理软件和硬件中的错误的。
-
1.1.7 容错性
除了可伸缩性，我们还须要考虑假设当server中的一个或多个出了问题时应该怎么处理。
尤其是你准备把Solr部署到虚拟化的商用硬件上时更要考虑这个问题。
最低的要求是你至少要打算去处理这些错误。
即便是使用高端的硬件配上最棒的架构，错误还是会发生的。
我们假定你的系统中一共同拥有4个分片的情况。假设2号分片所在的server断电了，那么此时Solr就不能继续正常的建立文档索引了。也不能响应查询服务了。所以这个时候能够说，你的搜索引擎就算“挂掉了”。要避免这样的情况。你能够给每个分片做备份。回到我们的这个样例中，当2号分片挂掉时，Solr会把全部指向2号分片的索引建立请求和查询请求重定向到它的备份哪儿。备份这个时候并没有挂掉。还能正常工作， 所以整个搜索服务还在。出错所产生后索引服务和查询服务仍然能够工作，只是可能不会像之前那么快了。由于少了一台server来处理请求。我们会在第16章中更具体的讨论各种故障情况。
到此为止。你已经看到了Solr具有一个设计良好地现代软件架构，可以非常好地做横向扩展以及处理容错。尽管这些在你决定使用solr之后都是必需要考虑的重要因素，可是你可能还是没有非常坚定Solr究竟是不是你的正确选择。
在下一节中，我们会站在公司不同角色的角度来看看Solr究竟可以给自己带来什么优点。包含软件架构师，系统管理员。和公司的CEO。
-
1.2 为什么选用Solr？
在本节中。我们希望能够提供一些关键信息来帮助于你推断Solr是否是贵公司技术方案的正确选择。
我们先从Solr吸引软件架构师的方面说起。
-
2.1 软件架构师眼中的Solr
在评估一项新技术时，软件架构师必需要考虑一系列的因素，当中就包含系统的稳定性，可伸缩性，还有容错性。Solr在这三方面的得分都非常不错。
说到稳定性，Solr是一个由活跃的开源社区和经验丰富的代码提交者共同维护的一项成熟技术。Solr和Lucene的新用户们一般会吃惊于项目的公布方式，可能他们曾经都是等待某个项目的官方Release版，没听说过这样的从分支上直接pull下来的方式。无论你的公司是否接受这样的方式，我们并非建议你这么做，我们想表明的是，Lucene和Solr项目中自己主动測试模块的測试深度和宽度是值得信任的。简单来说。假设你从分支上拿到了一个nightly build，假设全部的自己主动測试都能通过，那你就能够放心的肯定全部的核心功能都是ok的了。
我们在1.2.6节中已经接触到了Solr实现可伸缩性扩展的方法，在1.2.7节中也讨论了容错性的问题。作为一个架构师，你可能最好奇的是Solr的可伸缩性功能和容错性功能的局限究竟在哪里。首先，你须要知道在Solr4中，分片功能和复制备份功能都被重写了。在鲁棒性和易于管理方面都有非常大提高。
新的扩展方式被称为SolrCloud。其底层实现上，SolrCloud使用了Apache ZooKeeper来管理Solr集群上的配置同步，并监控集群的执行状态。这里列出了一些Solr全新的SolrCloud功能的亮点：
·中心化的配置
·分布式的索引。避免单点失败（SPoF）
·自己主动容错。自己主动产生新的主分片
·随意节点均可触发覆盖整个集群全部分片的分布式全查询，且已经集成了自己主动容错和负载均衡
可是这并非说Solr的可伸缩性就没有提高的空间了。SolrCloud在双方面还有待提高。首先，不是全部功能都能工作在分布式模式下。
比方 joins连接功能。其次，一旦索引建立，索引的分片数目就不能再动态调整，要想改变分片数的话仅仅能又一次对全部文档建立索引。我们在第16章会具体讨论SolrCloud的方方面面，可是我们希望确保软件架构师们可以意识到Solr的可伸缩性过去几年中已经走过了非常长的路。并且今后还将继续不断地改进下去。
-
2.2 系统管理员眼中的Solr
作为一名系统管理员，在考虑開始使用像Solr这种一种新技术时，最优先考虑的是新技术能否够非常好地和已有系统进行配合。对于Solr来说对这个问题能够非常轻松的回答YES。Solr 全然是基于JAVA开发的，能够在随意一个装有J2SE 6.x/7.x JVM虚拟机的操作系统上执行。
并且Solr还自带了Oracle提供的开源Java Servlet引擎Jetty。拿来就能用。还有一方面。Solr是一个标准的Java Web应用，能够非常方便的在JBoss或是Oracle AS之类的Java web应用server上进行部署。
对Solr的全部操作都能够通过HTTP请求来完毕， 而且Solr在设计时就考虑到了同Squid或是Varnish这种HTTP反向代理协同工作。Solr同一时候也支持JMX，所以你能够把Solr挂载到你喜欢的监控程序（比方Nagios）之下进行监控。
最后，Solr提供了一个不错的管理控制台。 能够用于检查配置，查看统计信息。发起測试查询。以及监控SolrCloud的健康情况等等。
图1.4展示了Solr4 管理控制台的一个截屏，我们会在第二章中具体的学习管理控制台的使用。
-
2.2.1 公司CEO眼中的Solr
虽然CEO之类的人物是不太可能看这本书的，我们还是要写几点关键的，以便于万一CEO在大厅里叫住你聊聊的时候你能够拿这几点去忽悠他。首先，管理层的人喜欢听到他们今天对技术做出的一笔投资将会在今后非常长一段时间内都产生效益。详细到Solr，你能够强调一下很多公司至今还在靠着Solr 1.4执行公司的产品，这但是2009年公布的老版本号，这说明Solr是有着成功的商用案例的，而且一直持续在改进。
此外，CEO们喜欢可控可预測的技术。
正如你在接下来的章节里所要看到的那样，Solr非常好用。你能够在几分钟之内就搭起一个简单的Solr服务。
还有一个疑问是假设万一负责Solr的那个员工跳槽或是跑路了。我们公司的业务会受到影响吗？不会因此整个服务当掉把？Solr的技术确实比較复杂。可是其开源社区非常的活跃，这意味着你仅仅要上去求助基本上都能及时得到帮助。
并且。你是直接能够看到源代码的呀，有的时候你发现一个地方写的有问题那你能够直接自己fix掉即可了。另外也有很多商业化的服务商能够帮你规划，实现和维护你的Solr系统，当中非常多服务商还提供Solr相关的培训课程。
接下来这一点可能CFO更关心。就是使用Solr的投资花费问题。
投资使用Solr事实上花不了多少钱。我们不用知道你的运营环境的规模大小就能够非常自信的说，你能够在几分钟之内就搭起一个简单的Solr服务。而且非常快就能够建立文档的索引。如今搭在云端的一个server能够在亚秒级（译者注：即不到一秒的时间之内）就处理完上百万的文档请求。