1.1 Solr究竟是什么?ios
在本节中,咱们经过从头设计一个搜索应用来介绍Solr的关键组件。这个过程将有助于你理解Solr的功能,以及设计这些功能的初衷。不过在咱们开始介绍Solr的功能特性以前,仍是要先澄清一下Solr并不具备的一些性质:web
1) Solr并非一个像Google或是Bing那样的web搜索引擎数据库
2) Solr和网站优化中常常提到的搜索引擎SEO优化没有任何关系编程
好了,如今假设咱们准备为潜在的购房客户设计一个不动产搜索的网络应用。该应用的核心用例场景是经过网页浏览器来搜索全美国范围内的房子。图1.1描述了这个虚拟应用的界面截图。不用太在乎UI界面的简陋,这只是一个便于咱们讨论的可视化模型。重点是经过这个例子,咱们来看看Solr到底能够提供哪些类型的搜索体验。浏览器
让咱们先快速浏览一下图1.1描绘了哪些Solr的关键特性。咱们从左上角开始,沿顺时针方向看。首先,Solr提供了强大的功能来支持关键字搜索框。正如咱们在1.1.2中讨论的那样,一个表现出色的关键字搜索功能,须要背后强大的复杂架构的支持。好在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两个阶段,将大规模的数据处理操做分配到商用机服务器集群上去,实现分布式运行。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应用服务器上。图1.3展现了Solr服务器的主要软件模块。
图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 同一服务器上创建多份索引
现代软件应用架构的一个显著特色就是面对快速变化的需求的灵活性。Solr在这方面有个颇有用的特性,就是你没必要只经过一份单一的索引来完成Solr中全部的任务。Solr支持在单一的Solr 引擎上运行多个Solr 核心。在图1.3中, 咱们描述了多个solr核心在同一个Java web应用环境中做为不一样的层同时运行的场景。
每个核心都有一个独立的索引和配置,在一个Solr实例中能够存在多个Solr 核心。这样你只须要一个Solr服务器就能够管理多个核心, 能够方便的实现服务器资源共享,以及及监控维护服务的共享。Solr有专门的API用于建立和管理多个Core。
Solr多核心支持功能的一个应用是数据分区,好比用一个core来负责最近更新的文档,而用另外的core来处理以前生成的文档,这个功能被称为按时间顺序分片。
在咱们的房地产搜索应用中,咱们也可使用多个core来分别处理不一样的类型的房屋资源,每一类用一个单独的索引文件来管理。好比说针对农村用地的房地产信息来讲,买一块农业用地的流程和买一套商品房的流程是不一样的,咱们彻底能够用一个单独的索引来管理农业用地的相关信息,将其保存在一个单独的core里。
1.1.5 可扩展性(经过插件扩展功能)
图1.3展现了Solr种最主要的三个子系统:文档管理,查询处理,和文本分析。固然,这些子系统是对Solr中复杂的子系统所作的宏观抽象,咱们会在稍后的章节中一一研究这些子系统。这其中的每个都是由一系列功能模块的流水线串成的,你能够在流水线中串入新的功能模块。这意味着若是你想给solr加入新的功能的话,根本不须要重写整个查询处理引擎,只须要在合适的位置串入本身的新功能模块便可。这样一来Solr的核心功能模块扩展和定制起来都很方便,能够彻底按照你的特定应用需求进行定制。
1.1.6 可伸缩性
Lucene是一个查询速度很是快的搜索库,而Solr彻底发挥出了Lucene的强劲性能。
可是抛开Lucene的性能不谈,做为一个服务器来讲,因为CPU和I/O的限制,同一时刻可以响应的用户数和请求数都是有限制的。
Solr实现可伸缩性的第一张牌是灵活的cache管理功能。该功能能够避免服务器重复进行耗费资源的操做。具体来讲就是Solr预先设置了一些cache来节省开销很大的重复计算,好比Solr会缓存查询过滤器的计算结果。咱们会在第四章学习Solr的缓存管理功能。
缓存的做用是有限的,为了处理更多的文档和得到更高的查询吞吐能力,你须要可以经过扩展服务器来横向扩展系统的性能。如今咱们来研究一下Solr扩展时最多见的两个方面。第一个是查询的吞吐能力扩展,也就是你的引擎每秒钟能够处理的最大查询数是多少。虽然Lucene能够很是快的处理每个查询请求,单台服务可以同时并发处理的请求出仍是会限制总体的查询吞吐能力。若是须要获得更高的查询吞吐能力,你须要增长查询服务器和索引的拷贝数量,以便让更多的服务器来同时处理更多的请求。这意味着若是你的索引复制到了三台服务器上,那么你每秒钟大约能够处理原来三倍的请求数量,由于每台服务器如今的负荷是总的查询量的三分之一。在实际应用中不多可以得到如此完美的现行扩展能力,因此使用三台服务器可能大约能达到原来2.5倍左右的性能。
另外一个扩展维度是被索引的文档数。若是你正在处理海量的文档, 那么当单个Solr实例中索引的文件数量多到必定程度的时候,查询性能的瓶颈也会出现。解决的方案是能够把索引文件切分红一个个被称为“分片”的小块,而后把查询请求分布到这些分片上进行操做。
使用虚拟化的商用硬件进行扩展
现代计算机技术的一个趋势就是构建能够在虚拟化的商用硬件上进行横向扩展的软件架构。简单来讲,就是能够经过添加普通的商用机服务器就能够处理更多的流量。相似于Amazon EC2这样的云计算服务提供商经过使用虚拟化的商用硬件来知足这种趋势的需求。虽然Solr能够再虚拟化硬件上运行,可是须要注意的是Solr对于I/O和内存很敏感。所以,若是在你的企业中搜索性能被放到了最高优先级来考虑,那你应该考虑在配备有高性能磁盘(好比SSD固态硬盘)的高端硬件上去部署Solr。部署Solr时硬件方面须要考虑的问题将会在第13章中进行讨论。
可伸缩性很重要,可是出错后的自动恢复能力在现代系统中也很重要。在下一节中,咱们来讨论一下Solr是如何处理软件和硬件中的错误的。
转载请注明原文出处http://my.oschina.net/fengnote
1.1.7 容错性
除了可伸缩性,咱们还须要考虑若是当server中的一个或多个出了问题时应该怎么处理。尤为是你准备把Solr部署到虚拟化的商用硬件上时更要考虑这个问题。最低的要求是你至少要打算去处理这些错误。即使是使用高端的硬件配上最优秀的架构,错误仍是会发生的。
咱们假定你的系统中一共有4个分片的状况。若是2号分片所在的服务器断电了,那么此时Solr就不能继续正常的创建文档索引了,也不能响应查询服务了。因此这个时候能够说,你的搜索引擎就算“挂掉了”。要避免这种状况,你能够给每个分片作备份。回到咱们的这个例子中,当2号分片挂掉时,Solr会把全部指向2号分片的索引创建请求和查询请求重定向到它的备份哪儿,备份这个时候并无挂掉,还能正常工做, 因此整个搜索服务还在。出错所产生后索引服务和查询服务仍然能够工做,不过可能不会像以前那么快了,由于少了一台服务器来处理请求。咱们会在第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功能的亮点:
转载请注明原文出处http://my.oschina.net/fengnote
·中心化的配置
·分布式的索引,避免单点失败(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应用服务器上进行部署。
对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服务,而且很快就能够创建文档的索引。如今搭在云端的一个服务器能够在亚秒级(译者注:即不到一秒的时间以内)就处理完上百万的文档请求。