Solr到底是什么？
在本节中，我们通过从头设计一个搜索应用来介绍Solr的关键组件。这个过程将有助于你理解Solr的功能，以及设计这些功能的初衷。不过在我们开始介绍Solr的功能特性之前，还是要先澄清一下Solr并不具有的一些性质：
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配置