作者：范炜等
出版社：电子工业出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Solr 实战试读：
前言
2008年，我受命接管凯业必达（CareerBuilder）招聘网的搜索技术团队。最初使用微软的FAST搜索平台，但随后我们意识到，搜索对凯业必达招聘网而言非常重要，与其继续依赖搜索服务提供商，不如在团队内培养搜索专家。我随即开始调研同类型的开源搜索软件，发现Solr似乎满足我们搜索开发所需的大部分核心功能。2009年夏，经过充分的搜索技术准备之后，我们决定将已有的搜索系统转换到Solr。
Solr的发展很顺利。Solr构建在开源搜索库Lucene之上。2005年2月，Lucene正式成为Apache顶级项目。2006年Solr被捐赠给Apache软件基金会，并于2007年1月成为Apache顶级项目。这两项技术的发展都达到了一定规模之后，在2010年3月合并为一个项目。
2010年夏，我们的搜索平台完全转换到了Solr。在转换过程中，我们提升了搜索速度，大幅度减少了搜索架构所需的服务器数量，避免了昂贵的软件许可费用，增强了平台的稳定性，从先前依赖搜索服务提供商的外部主导转向内部的搜索自主创新。
当时我们并没有意识到搜索自主创新所带来的附加价值。我们已经能够开发出一整套全新的搜索应用产品，包含关键词搜索、语义搜索、大数据分析及实时推荐引擎。我们将Solr作为可扩展的搜索架构，一小时内通过数百台服务器处理数十亿级的文档与数百万级的查询请求。我们进入了灵活扩展的云服务时代，在数据爆炸中寻求数据的社会意义与价值。Solr让我们有能力解决迎头而来的挑战。
当Manning出版社找到我谈《Solr实战》一书的写作事宜时，我犹豫了，因为我清楚这是一项艰巨的任务。我提出一个要求：需要一位得力的合作者，而Timothy Potter正是合适的人选。Tim拥有多年Lucene和Solr搜索方案的开发经验。他利用Solr和其他大数据前沿技术，在社交数据的文本分析系统构建与实时分析解决方案方面有着丰富经验。多年来，我俩都得到过Solr社区的诸多帮助。当得知开源社区确实需要一本案例驱动的Solr指南时，Tim和我很高兴能撰写《Solr实战》这本书，为下一代搜索工程师提供帮助。这本书是五年前我们开始接触Solr时希望看到的，不论你是刚开始学习Solr，还是需要补充搜索知识，希望这本书能够对你有帮助。致谢
与Solr一样，这本书的问世离不开广大开源社区成员的支持，在此对他们表示感谢。
● Lucene/Solr提交者不但能编写令人惊叹的代码，还能提供宝贵的专业知识和建议，同时又能对社区新成员保持足够的耐心。
● 感谢Lucene/Solr社区的活跃成员积极贡献代码、更新Wiki和其他文档，并回答Lucene和Solr邮件列表问题。
● 感谢Solr的创造者Yonik Seeley为本书作推荐序。
● 感谢那些通过Manning图书早期访问计划MEAP阅读本书草稿，在作者在线论坛上发表评论的读者。
● 感谢在本书写作过程中提供宝贵反馈的评阅人：Alexandre Madurell、Ammar Alrashed、Brandon Harper、Chris Nauroth、Craig Smith、Edward Welker、Gregor Zurowski、John Viviano、Leo Cassarani、Robert Petersen、Scott Anthony、Sopan Shewale及Uma Maheshwar Rao Gunuganti。
● 感谢Ivan Todorović与 John Guthrie在本书付印之前的短短时间里对本书进行了详细的技术校对。
● 感谢Manning出版社的相关责任编辑们：Elizabeth Lexleigh、Susan Conant、Melinda Rankin、Elizabeth Martin和Janet Vail。
● 感谢Manning出版社的Bert Bates帮助我们提高写作中的讲解说明水平。
● 感谢家人与朋友在我们漫长的研究与写作过程中给予支持。
Trey Grainger
首先要感谢我了不起的妻子Lindsay，在这本书漫长的写作过程中离不开她的支持与耐心。如果没有她的理解和帮助，这本书不可能完成，特别是在这期间我们的女儿出生了。
我还要感谢Paula和Steven Woolf，他们花了不少时间照看Melodie，才让我得以顺利完成书稿。最后，我要感谢凯业必达公司团队，包括公司领导层和我的搜索团队，感谢你们让我有机会与优秀的人一起工作，一起构建一个领先的搜索平台，以此惠及社会。
Timothy Potter
我要感谢我的母亲Sharon Russom，她从小就培养我对学习和书籍的热爱。还要感谢我的父亲David Potter对我的学业与工作的支持。没有Lori Joy的帮助，这本书不可能完成。感谢你对我在深夜和周末加班的理解与支持，并在写作早期宣传此书。
还要感谢我之前效力的Dachis集团。如果没有他们对Solr提出那些富有见地的问题，并给我机会去使用Solr构建一个大规模搜索解决方案的话，我不可能完成这本书。第1部分初识Solr前6章的重点是探索Solr的两个最重要的功能：索引数据和执行查询。阅读完第1部分之后，你应该对Solr的查询与索引功能有充分的了解，包括如何对文本和其他类型的数据进行分析，以及在这些数据上进行搜索。面对每个新主题，我们首先都要从基础开始——学习如何安装Solr，并在本地运行它。如果你是初次接触全文搜索，可能会对一些术语感到陌生，那么把第3章当成词典吧。搜索引擎与数据库之间的主要区别是什么？什么是倒排索引？什么是相关度排序以及Solr是如何实现的？掌握了基础知识之后，在第4章中我们将揭开Solr的引擎罩，了解如何执行查询请求，熟悉那些对请求进行控制处理的配置设定。Solr的主要配置文件是solrcon昀g.xml，它包含许多设置，其中有一些（如缓存管理设置）在刚上手时非常有用，还有一些则适合高级用户。只有真正地索引了一些文档，才会发现搜索引擎的有趣之处。第5章和第6章介绍如何索引文档，涵盖文档模式设计、字段类型与文本分析。理解索引的核心方面有助于学习本书中的其他内容。1 Solr入门
本章要点
■ 搜索引擎处理的数据所具备的特征
■ 常见搜索引擎用例
■ Solr核心组件
■ 选择Solr的理由
■ 功能概述
快速发展的技术，如社交媒体、云计算、移动应用与大数据，令人兴奋且充满挑战，一切皆计算的时代到来了。软件架构所面临的一个主要挑战是处理由广泛的全球用户群体消费和产生的大规模数据。此外，用户希望在线应用始终是可用且可响应的。为解决现代Web应用的可扩展性和可用性需求，统称为NoSQL（Not only SQL，不仅仅是SQL）的非关系型数据存储与处理技术在业内受到了越来越多的关注。这些系统拥有共通的设计模式，是面向特定数据类型的存储与处理引擎，而非强制所有数据遵循曾经的标准化关系模型。换句话说，优化了的NoSQL技术用以解决特定数据类型的特定问题。规模需求导致了由各种NoSQL和关系型数据库构成的复合架构，一套通吃的数据处理解决方案已成历史。
本书介绍Apache的Solr，它是一种具体的NoSQL技术。与其非关系型弟兄一样，Solr被用来解决特定问题。具体而言，Solr是可扩展的、开箱即用的企业级搜索引擎，用来搜索大规模文本数据并根据相关度排序结果。这听起来有点绕口，让我们分解开来看：
● 可扩展——Solr通过集群中多台服务器的分布式运行实现扩展。
● 开箱即用——Solr是开源的，易于安装和配置，并提供预先配置好的示例服务器，方便上手。
● 为搜索优化——Solr速度很快，以亚秒级速度执行复杂查询，往往只需花费几十毫秒。
● 大规模文档——Solr可以用于处理包含百万级文档的索引。
● 以文本为中心——Solr针对自然语言文本搜索进行优化，如电子邮件、网页、简历、PDF文档、社交消息（推文和博客）。
● 根据相关度对结果排序——Solr根据文档与用户查询的相关程度对文档进行排序，并以此顺序返回结果文档。
在本书中，你将学到如何使用Solr设计与实现可扩展的搜索解决方案。首先你将了解到Solr支持的数据类型和用例，这有助于你掌握Solr在现代应用架构蓝图中所处于的位置及其所能解决的问题。1.1 为什么需要搜索引擎
作为本书的读者，相信你对于为什么需要搜索引擎已经有自己的想法了。与其猜测你为什么考虑Solr，不如来解决你的数据和用例是否需要搜索引擎这个困难的选择问题。这个问题最后可以归结为理解你的数据和用户，并为其选择一种可用的技术。让我们先来看看搜索引擎擅长处理的数据属性。1.1.1 管理以文本为中心的数据
现代应用架构的一个突出特点是与数据搭配相应的存储与处理引擎。如果你是程序员，你应该知道根据数据处理的算法来选择最佳的数据结构，举例来说，当快速随机查找时不使用链表结构。此原则也适用于搜索引擎。类似Solr这样的搜索引擎擅长处理的数据表现为4个主要特征：
1.以文本为中心
2.读主导
3.面向文档
4.灵活的模式
第5个可能的特征是大量数据需要处理，也就是“大数据”。我们现在讨论的焦点是搜索引擎与其他NoSQL技术的不同之处，所以这里没有强调Solr可以处理大量数据。
具备上述4个主要特征的数据是Solr这样的搜索引擎能够有效处理的，但也只能把它们当作粗略的指南，而非严格的规则。接下来让我们进一步了解上述每一个特征对搜索的重要性。这里，我们将重点放在抽象概念上，具体怎样做会在后续章节深入讲解。
以文本为中心
在描述由搜索引擎处理的数据类型时，你必然会遇到非结构化这一术语。我们认为非结构化有些模糊，因为基于人类语言的文本文档都有隐含的结构。你可以将非结构化视为计算机视角的产物，从计算机眼中看到的文本是字符流。字符流必须使用特定语言规则来抽取结构，并使其可搜索。这正是搜索引擎要做的。
我们认为以文本为中心更适合描述Solr处理的数据类型，因为搜索引擎是专门用于将文本的隐含结构抽取到索引中，从而改善搜索的。以文本为中心的数据意味着，文档中的文本包含用户在找寻时感兴趣的信息。当然，搜索引擎也支持非文本数据，如日期和数字，但它的主要优势还是处理基于自然语言的文本数据。
如果用户对文本中的信息不感兴趣，搜索引擎可能就不是解决问题的最佳方案了，所以以文本为中心的这个中心很重要。我们来看一个由雇员创建的差旅费用报告的应用。每个报告包含一些结构化数据字段，如日期、费用类型、币种及金额。此外，每项花销可能包含一个备注字段，可以简要描述花销事宜。这是一个包含文本但不是以文本为中心的数据示例，它与会计部门每月生成费用报表时需要搜索备注字段的情况不同。数据包含文本字段并不意味着就与搜索引擎自然适配。
考虑一下你的数据是否以文本为中心吧，主要考虑数据中的文本字段是否包含用户想要查询的信息。如果是，搜索引擎可能是个不错的选择。第5章和第6章将会使用Solr的文本分析能力解锁文本中的结构。
读主导
搜索引擎擅长处理的数据的另一个关键特征是读主导，即能实现有效读取，且无须经常更新的数据。对了，你还需要知道，Solr是可以对索引中的已有文档进行更新的。“读主导”可以理解为，文档被读取的次数远多于被创建和更新的次数。然而，这也不代表不能写入大量数据，或限制写入新数据的频次。事实上，Solr 4的一个关键特性是近实时（Near Real-Time,NRT）搜索，允许每秒索引数千文档，并且几乎立时就能搜索到它们。
读主导数据背后的关键点是，当向Solr写入数据时，要做好读取和重复读无数次的准备。搜索引擎擅长执行查询数据（读操作），而非存储数据（写操作）。另外，如果必须对搜索引擎里的已有数据经常更新，那么搜索引擎可能不是最佳解决方案。如果需要对已有数据进行快速随机写操作的情况，那么其他的NoSQL技术（如Cassandra）会是一个不错的选择。
面向文档
截至目前，我们一直在讨论数据，但现实中搜索引擎处理的是文档。在搜索引擎中，文档是字段的自包含集合，每个字段仅包含数据而不包含嵌套字段。换句话说，Solr这样的搜索引擎中的文档是平面结构，而且不依赖于其他文档。在Solr中，“平面”的概念稍有放宽，一个字段可以有多个取值，但字段不包含子字段。在单一字段中可以存储多个值，但不能在其他字段里嵌套字段。
Solr面向文档的平面结构方法能很好地处理各种文档格式的数据，如网页、博客、PDF文件，那么如何对关系型数据库中的规范化数据进行建模呢？在这种情况下，需要对分布在多个表中的数据去规范化，将其组织成一个平面、自包含文档结构。我们将在第3章学习转换处理方法。
还要考虑到，文档的哪些字段必须存储在Solr中，哪些应该存储在其他系统（如数据库）中。除非数据对搜索或显示结果有用，否则不适合存储在搜索引擎里。例如，对在线视频创建索引时，二进制视频文件不应在Solr中存储，大型二进制字段应该存储在其他系统，如内容分发网络（Content-Distribution Network,CDN）。通常，为了满足搜索需求，应该存储的是索引的每个文档信息的最小集合。视频例子清楚地说明了不要将Solr作为通用数据存储技术，Solr的任务是找到兴趣相关的视频，而不是管理大型二进制文件。
灵活的模式
Solr这样的搜索引擎擅长处理的数据的最后一个主要特征是具有灵活的模式。也就是说，索引的文档不必拥有统一的结构。在关系数据库中，表中的每一行都具有相同的结构。在Solr中，文档可以有不同的字段。当然，同一索引的文档字段之间可能存在一些重叠，但它们不必是相同的。
假设有一个房屋出租或销售的搜索应用，搜索列表有一些共用的字段，如位置、卧室个数和浴室个数，除此之外，根据房屋类型还可以拥有各自不同的字段。例如，销售的房屋拥有价格和年财产税等字段，出租的房屋拥有月租和宠物管理政策等字段。
总之，通用搜索引擎和Solr擅长处理具备这4种特征的数据：以文本为中心、读主导、面向文档和灵活的模式。这也说明Solr不是一种通用的数据存储和处理技术。
对复杂数据存储与处理的正确认识是无须寻找全能技术。搜索引擎擅长特定数据处理，但不擅长其他技术。这就意味着，在多数情况下，Solr更多地是对关系型数据库与NoSQL数据库进行补充，而非取代它们。
以上介绍了Solr擅长处理的数据类型，接下来介绍以Solr为代表的搜索引擎适合处理的主要用例。这些用例有助于理解搜索引擎与其他数据处理技术的差异。1.1.2 常见的搜索引擎用例
在本节中，我们来看看用以Solr为代表的搜索引擎能做些什么。上一小节讨论了搜索引擎擅长处理的数据类型，这只是指南，而不是严格的规则。在深入细节之前应该清楚一点，要把搜索做到极致是很困难的。现在的用户习惯于Google和Bing这样的搜索，它们能够快速且有效地满足当前网络信息获取的需求。此外，知名的网站都拥有强大的搜索解决方案，以帮助访客更快地找到信息。对类似Solr的搜索引擎进行评估并设计自己的搜索解决方案时，请优先考虑用户体验。
基础关键词搜索
显而易见，搜索引擎支持关键词搜索，这是它的主要功能。其中的原因值得一提：关键词搜索是用户使用你的搜索解决方案时最典型的一种方式，没有用户想要一开始就填写复杂的搜索表单。由于基础关键词搜索是搜索引擎用户最常用的搜索方式，所以理所应当为之提供出色的用户体验。
一般情况下，用户想要输入几个简单的关键词之后得到不错的搜索结果。这听起来像是一项将查询词项与文档进行匹配的简单任务，但为了达到出色的用户体验，必须考虑以下几点：
● 必须快速返回相关结果，大多数情况下应该在一秒之内或更短。
● 在用户拼错一些查询语词时，需要进行拼写纠错。
● 自动建议会减少击键次数，特别对移动应用而言。
● 识别查询词项的同义词。
● 匹配包含查询词项语言形式变化的文档。
● 短语处理是必要的，即用户想要匹配整个短语或部分文字。
● 必须处理查询中包含的“a”、“an”、“the”等常用词。
● 如果用户对排名靠前的搜索结果不满意，必须能继续查看更多结果。
如你所见，如果没有专门的处理方式，这些要求会使得看似基础的功能难以实现。但是对于以Solr为代表的搜索引擎，以上几点要求是开箱即用的，使用起来非常方便。为用户提供强大的工具来执行关键词搜索之后，需要考虑的是如何显示搜索结果。这就引出了下一个用例：基于用户查询相关度的搜索结果排名。
排名检索
搜索引擎代表了基于查询返回“优先”文档的一种方法。在关系型数据库的SQL查询中，表的一行要么匹配一个查询，要么不匹配，查询结果基于一列或多列进行排序。搜索引擎根据文档与查询匹配的程度为文档赋分，并按降序返回结果。匹配程度的计算取决于多个因素，一般而言，文档得分越高意味着该文档与查询的相关性越强。
根据相关度对文档进行排名是非常重要的，原因如下：
● 现代搜索引擎通常存储大量文档，往往以百万计或数十亿计。若不根据查询相关度对文档进行排名，就会缺乏清晰的导航方式，用户将无法应对搜索结果。
● 用户更习惯于使用那些只需要输入几个关键词就能得到结果的搜索引擎。用户没有耐心，希望搜索引擎能够达到“不用我说，你懂得”的境界。在移动应用背后的搜索中，用户输入存在拼写错误的短查询，并期望其有效，这是现实情况的写照。
通过为特定文档、字段或指定词项赋予更高的权重或加权，可以影响文档排名。例如，通过提升时间字段权重，可以将较新的文档提升到搜索结果的前列。第3章会深入介绍文档排名。
超越关键词搜索
使用以Solr为代表的搜索引擎，用户可以输入几个关键词并得到结果。但对许多用户来说，这仅仅是交互进程的第一步，他们还将对搜索结果进行不断探索。搜索引擎的一个主要用例是驱动信息发现进程。通常情况下，用户并不准确知道他们要寻找什么，也不清楚搜索系统里有什么信息。一个好的搜索引擎会帮助用户明确他们的信息需求。
此处的核心思想是从初始查询返回文档，以及提供工具帮助用户限定搜索。换句话说，除了返回匹配的文档之外，还应告诉用户下一步该怎么做。例如，根据文档特征对搜索结果进行分类，方便用户缩小搜索范围。这就是所谓的分面搜索，是Solr的强项之一。1.2小节将介绍一个房地产的分面搜索例子，第8章将深入介绍分面。
不要将搜索引擎用于……
让我们看一些不适合搜索引擎的用例。首先，搜索引擎会为每个查询返回一小部分文档集合，通常为10～100个。同一查询的更多文档可以通过Solr内置的分页功能获取。假设一个查询匹配了100万个文档，如果一次性全部返回这些文档，等待时间会很长。查询本身的执行速度可能很快，但从底层索引结构上重构100万个文档极其缓慢。Solr使用特定格式将字段存储在磁盘上，这种格式适合于创建少量文档，但生成结果时需要重构大量文档的话，速度会很慢。
另一个用例是，除非内存足够大，否则不要用搜索引擎去完成深度分析任务，这需要访问大部分索引。即使通过分页解决上述问题，底层索引的数据结构也并不适合一次检索大部分索引。
之前已经谈到过这个问题，但这里要重申一下，搜索引擎无法检索文档之间的关系。Solr确实支持“父子”关系的查询，但不支持SQL复杂关系型数据结构中的关系发现。第3章会介绍关系型数据如何适应Solr的平面文档结构。
此外，大多数搜索引擎都不直接支持文档级别的安全策略，至少Solr没有。如果你需要细粒度的文档权限，这就不属于搜索引擎范畴了。
至此，我们了解了搜索引擎适用和不适用的数据类型和用例，是时候从抽象层面了解Solr的工作原理了。下一小节介绍Solr能提供哪些功能，以及与外部系统集成、可扩展性与高可用性等重要的软件设计理念。1.2 Solr是什么
本节通过搜索应用设计介绍Solr的关键组件。这有助于我们理解Solr提供的具体功能及其背后的设计动机。在了解Solr到底是什么之前，我们先明确Solr不是什么。
● Solr不是Google或Bing这样的网络搜索引擎。
● Solr不具备网站搜索引擎优化（SEO）方面的功能。
假设我们现在需要为潜在的购房者设计一个房地产搜索引擎。这个搜索应用的核心用例是通过网页浏览器搜索出售的房屋。图1.1是假想的应用截图。不要太关注UI布局设计，这只是为了营造视觉场景而设计的原型，目的是展示Solr支持的体验类型。图1.1 为展示Solr功能的虚构搜索应用原型截图
让我们来看看图1.1中所示的Solr的一些主要功能。我们从左上角开始沿顺时针方向看，Solr提供了功能强大的关键词搜索框。正如1.1.2小节讨论的，基础关键词搜索要做到出色的用户体验，就需要复杂的架构，而Solr提供了开箱即用的解决方案。具体而言，Solr提供了拼写检查（用户输入时提供建议）、同义词处理、短语查询、文本分析等工具，用来处理查询词项的语言变体，如buying a house或purchase a home。
Solr还提供了强大的地理空间查询解决方案。如图1.1所示，以虚构的邻居为中心，根据经纬度距离，Solr将匹配的房屋列表显示在地图上。借助Solr的地理空间支持，可以根据地理距离对文档排序，在特定范围内过滤文档，甚至根据任意位置返回每个文档的地理距离。地理空间搜索要快速有效，UI界面要支持缩放和在地图上移动，这些功能很重要。
用户执行查询后，Solr的分面功能可以对搜索结果进一步细分，显示结果集的文档特征。分面是对结果进行归类的一种方法，用于引导进一步的发现和查询细分。例如，图1.1中搜索结果根据功能配套、家居风格和房屋类型三个分面进行归类。
至此，我们对房地产搜索应用的功能类型有了基本认识。下面我们来看看如何在Solr中实现这些功能。首先，我们需要知道，Solr如何对用户输入的查询与索引进行匹配，继而得出房屋列表。这是所有信息检索应用的根基。1.2.1 信息检索引擎
Solr构建在Apache的Lucene之上，Lucene是一个广受欢迎的基于Java的开源信息检索库。第3章会详细讨论信息检索是什么，这里只介绍信息检索的核心概念。权威的信息检索教科书对现代搜索概念的一个正式定义如下：
信息检索（Information Retrieval,IR）是从大规模集合（通常存储在计算机）中查找满足特定信息需求的具有非结构化性质（通常是文[1]本）的资料（通常是文档）的过程。
在房地产搜索应用的示例中，用户的原始需求是根据地理位置、家居风格、功能配套和价格找房子。索引包含全国各地的房屋清单，这绝对算得上一个“大集合”。简而言之，Solr使用Lucene来实现索引文档的核心数据结构，并执行文档搜索。
在后台，Lucene是一个Java类库，用于倒排索引的构建与管理，倒排索引是专门用于匹配查询词项与文本文档的数据结构。图1.2是房地产搜索应用的Lucene倒排索引的简化描述。图1.2 倒排索引是信息检索的关键数据结构
第3章会介绍倒排索引的原理，这里仅通过图示初步认识倒排索引。在图1.2中，当一个新文档（44号）加入索引后会发生什么，以及如何使用倒排索引对文档与查询词项进行匹配。
你可能会想，关系型数据库的SQL查询也能很快得到同样的查询结果，对这个简单的例子而言确实是这样的。但是，Lucene查询与数据库查询的不同在于，Lucene的结果是根据查询的相关度进行排名，数据库的结果只是根据表的一列或多列进行排序。换言之，文档相关度排名是信息检索有别于其他搜索类型的重要方面。
构建Web规模的倒排索引
Google的网页搜索也使用倒排索引，你可能会对此感到吃惊。事实上，正是为了构建Web规模的倒排索引才导致了MapReduce的诞生。
MapReduce是将大规模数据处理操作部署在商业服务器集群上的一个编程模型，部署过程包括特定算法实现映射（Map）和规约（Reduce）两个阶段。凭借其函数式编程根基，Google使用MapReduce构建大规模倒排索引，用来驱动网页搜索。在映射阶段会产生唯一词项与文档编号（词项出现的位置）。在规约阶段，词项进行排序，所有的term/docID对被发送到同一个规约处理器，规约处理器汇总每个词项的所有词项频次，从而生成倒排索引。
Apache的Hadoop提供了MapReduce的开源实现，原属于Apache的Nutch开源项目，其使用Solr为Web大规模搜索构建Lucene倒排索引。Hadoop和Nutch的深入讨论超出了本书的范围，如果你打算构建大规模索引，建议花时间了解这些项目。
Lucene提供搜索的核心基础架构，那么Solr在Lucene基础上做了哪些增强？让我们从如何使用Solr的schema.xml配置文件来定义索引结构开始了解吧。1.2.2 灵活的模式管理
虽然Lucene提供文档索引和查询执行的类库，但缺少生成索引结构的简单配置方法。Lucene中定义字段和分析字段都需要编写[2]Java代码。通过名为schema.xml的XML配置文件，Solr提供了一种简单明了的索引结构定义和字段表示及分析方法。Solr后台使用schema.xml表示所有可能的字段和数据类型，将文档映射为Lucene索引。这样可以节省编程时间，并让索引结果更易于理解和交流。Solr构建的索引与Lucene编程方式构建的索引是完全兼容的。
Solr还对Lucene核心索引功能进行了扩展。具体来说，Solr增加了复制字段（copy 昀eld）和动态字段（dynamic 昀eld）。复制字段取得一个字段或多个字段的原始文本内容，并将其赋予不同的字段。动态字段允许将同一字段类型赋予多个不同字段，而不需要在schema.xml中显式声明。这对那些具有多个字段的文档建模非常有用。第5章和第6章将深入介绍schema.xml。
在房地产应用的例子中，不用对schema.xml做任何修改就可以运行Solr示例服务器，你可能会感到惊讶，不过这正显示了Solr模式的灵活性。虽然Solr示例服务器被设计用于支持产品搜索，但对房地产搜索例子依然有效。
Lucene提供了文档索引、查询执行和结果排名的强大类库。通过schema.xml，你可以使用XML配置文档灵活地定义索引结构，无须再用Lucene的API进行编程。接下来需要一种方法通过网络访问这些服务。下一小节介绍Solr如何作为一个JavaWeb应用执行，以及如何使用成熟的标准（如XML、JSON和HTTP）与其他技术进行集成。1.2.3 Java Web应用
Solr是一个Java Web应用，可以运行在任何主流Java Servlet引擎中，例如，Jetty和Tomcat，或JBoss、Oracle AS这样的J2EE应用服务器。图1.3展示了Solr服务器的主要软件构成。图1.3 Solr 4的主要构成图解
显然，图1.3初看之下有点复杂。花点时间浏览一下这张图，熟悉一下这些术语。不必担心对其中的术语和概念不了解，读完这本书后，你将对图1.3中的概念有深刻理解。
正如本章前面所提及的，Solr设计者认为，在现有架构下Solr是最佳的补充技术。事实上，你很难找到一个Solr不适用的环境。在第2章你将会看到，下载完几分钟之后你就可以将Solr示例服务器运行起来。
为实现轻松集成的目标，Solr的核心服务需要访问许多不同的应用和编程语言。Solr基于已有的XML、JSON和HTTP标准，提供简单的类似REST的服务。由于Solr并没有严格遵守所有的REST（Representational State Transfer，代表性状态传输）原则，因此要避免为Solr基于HTTP的API打上REST风格标记。例如，在Solr中，删除文档使用HTTP的POST方法，而不是用HTTP的DELETE方法。
将类REST接口作为基本原理固然不错，但开发者往往会使用他们喜欢的编程语言的客户端库（Client Library）进行访问，以应对Web Service调用与响应处理的单一机制（boilerplate machinery）。所幸的是，大多数编程语言，包括Python、PHP、Java、.NET和Ruby，都有Solr的客户端库。1.2.4 一台服务器上的多个索引
现代应用架构的一个标志是应对快速变化要求的灵活性需求。在这样的情况下，Solr所提供的帮助之一是允许你不必把所有内容放在Solr的一个索引里。Solr支持在单个引擎上运行多个内核。图1.3中将多个内核处理成单独的层，全部运行在同一个Java Web应用环境下。
每个内核可视为一个单独的索引和配置，并且一个Solr实例可以包含多个内核。这样就可以在一台服务器上管理多个内核，共享服务器资源和管理任务，例如，监控和维护。第12章将介绍Solr进行多内核创建与管理的API。
Solr支持多核的一个用途是数据分区，例如，一个内核处理最近的文档，另一个处理较久远的文档，这就是所谓的时间顺序分片（chronological sharding）。多核的另一个用途是支持多租户应用。
在房地产应用的例子中，多个内核被用于管理不同类型的列表，每个列表都有自己的索引。如果要抛开家用住宅单独来看购买乡下土地的房地产列表，由于在一座城市购买乡下土地与购买房屋的过程不同，因此把土地列表放在单独的核心来管理可能比较合理。1.2.5 可扩展性（插件）
图1.3描述了Solr的三个主要子系统：文档管理、查询处理和文本分析。当然，这都是Solr复杂子系统的高度抽象，我们随后会深入介绍每一个子系统。每个子系统都是由模块化的“管道”构成的，通过插件方式实现新功能。这意味着，没有必要推翻Solr的整个查询处理引擎，只需要在已有管道中接入新的搜索构件即可。这使得Solr的核心功能易于扩展，并能根据特定应用需求实现定制。1.2.6 可伸缩性
Lucene是一个执行速度相当快的搜索类库，Solr汲取了Lucene速度方面的所有优点。但无论Lucene多快，由于CPU的I/O限制，单台服务器终会达到来自不同用户的并发请求的处理上限。
实现伸缩性的第一步是，Solr提供灵活的缓存管理功能，帮助服务器重用运算量大的数据扩容。具体来说，Solr预先设置一些缓存来节省繁重的重新运算量，例如，为查询过滤器缓存搜索结果。第4章将介绍Solr的缓存管理功能。
缓存能做的事情只有这些，如果需要处理更多的文档和复杂的查询，可以通过增加服务器实现增容。这里，我们关注Solr伸缩性的两个最常见维度：查询吞吐量和文档索引量。查询吞吐量是指搜索引擎每秒支持的查询数量。虽然Lucene可以快速执行每个查询，但单台服务器上的并发请求存在瓶颈。为实现更高的查询吞吐量，可以通过增加索引副本让更多的服务器处理更多的查询请求。这意味着，如果在三台服务器上复制索引，每秒的查询数量会变为原来的3倍，因为每台服务器只用处理三分之一的查询请求。在现实中，完美的线性伸缩性很难实现。因此，增加到三台服务器可能会比一台服务器时增速2.5倍。
伸缩性的另一个维度是文档索引量。如果数量规模较大，那么单个实例会因容纳太多文档而达到极限，查询性能也会受影响。为了处理更多文档，可以将索引拆分为很小的索引块，称之为索引分片，然后在索引分片中进行分布式搜索。
使用虚拟化扩展规模
现代计算的一个发展趋势是软件架构的建设能够使用虚拟化商用硬件进行横向扩展。通过添加更多的商用服务器来处理更多的流量。云计算提供商，如Amazon的EC2，助力了这一趋势的发展。Solr的确可以运行在虚拟化硬件上，不过你应该清楚搜索是I/O和内存密集型应用。因此，如果搜索性能对你的组织而言是重中之重，那么就应该考虑在高性能磁盘（如固态硬盘SSD非常理想）的高端硬件上部署Solr。第12章将讨论Solr部署的硬件知识。
可伸缩性非常重要，故障处理能力对现代系统也很重要。下一小节讨论Solr如何处理软件和硬件故障。1.2.7 容错性
除了可伸缩性，还需要考虑一台或多台服务器的故障处理能力，特别是打算在虚拟机或商用硬件上部署Solr时。最起码必须有一套故障应对办法。即使是最好的架构和最高端的硬件也会出故障。
假设索引有4个分片，托管分片2的服务器断电了。这时，Solr无法继续索引文档和提供查询服务，搜索引擎基本就宕机了。为避免这种情况，需要为每个分片添加副本。当分片2发生故障时，Solr可以启用副本来索引和处理查询，Solr集群能够保持联机状态。这种情况下故障虽然不会影响索引和查询，但由于少了一个处理请求的服务器，可能会降低速度。第12章和第13章将讨论故障转移场景。
Solr拥有先进的、精心设计的架构来满足可伸缩性和容错性。如果想要采用Solr，这些都需要重点考虑，但仍然不能由此确定Solr就是最合适的选择。1.3节将从不同人员的角度，如软件架构师、系统管理员和CEO，谈谈采用Solr的好处。1.3 选择Solr的理由
本小节会提供一些关键信息，为你的组织决定是否采用Solr技术提供决策帮助。首先从软件架构师开始，Solr对他们很有吸引力。1.3.1 面向软件架构师的Solr
软件架构师评估一项新技术时，必须考虑许多因素，包括稳定性、可伸缩性与容错性。Solr在这三方面是遥遥领先的。
在稳定性方面，Solr是一项成熟的技术，得到活跃的社区和经验丰富的开发者的支持。从开源代码的主工作目录直接部署，无须等待正式版本发布，这一点可能会让Solr和Lucene的新用户感到吃惊。我们不给具体建议，这里只是为了说明Lucene和Solr自动化测试的深度与广度。如果是自动化测试全部通过的最新测试版（而非主版本），那么你就完全不用担心其核心功能的稳固性。
1.2.6和1.2.7小节已经介绍了Solr的可伸缩性与容错性方式。作为软件架构师，你可能最想了解Solr在这两方面的局限性。首先，你应该认识到，Solr 4中的分片与复制功能被改进了，更加强健和易于管理。新的扩展方式称为SolrCloud。SolrCloud后台使用Apache的ZooKeeper处理Solr服务器集群的分布式配置，并跟踪集群的状态。SolrCloud的一些新功能点如下：
● 集中配置。
● 无单点故障（Single Point of Failure,SPoF）的分布式索引。
● 故障会自动转移到新的分片代表（shard leader）。
● 查询可以发送至集群中的任何一个节点，触发跨所有分片的完整的分布式搜索，内置了故障转移和负载均衡支持功能。
这也不意味着Solr的伸缩性没有改进空间。当修改索引大小（合并或分割索引）时，SolrCloud依然需要人工介入。并不是所有的Solr功能都适用于分布式模式。第12章将具体介绍Solr的伸缩性，第13章将专门介绍SolrCloud的新功能。希望软件架构师都能了解一点，即在过去几年中Solr的伸缩性得到快速发展，且支持无单点故障的稳健伸缩性。1.3.2 面向系统管理员的Solr
作为系统管理员，采用像Solr这样的新技术时，需要优先考虑新技术是否适合现有的基础架构。简单的答案是：Solr当然适合。因为Solr是基于Java的，可以运行在任何具有J2SE 6.x/7.x JVM的操作系统平台上。Solr内置了一个由Oracle提供的开源Java Servlet引擎Jetty。另外，Solr是标准的Java Web应用，很容易部署在Java Web应用服务器中，如JBoss和Apache的Tomcat。
Solr的所有访问都要通过HTTP，支持HTTP缓存反向代理Squid和Varnish。Solr还支持JMX，能够挂载监控应用，如Nagios。
另外，Solr还提供一个很不错的管理控制台，检查配置设定、查看统计数据、提交测试查询和监控SolrCloud的健康状况。图1.4是Solr的管理控制台界面，第2章会具体介绍。图1.4 Solr 4的管理控制台截图，在其中可以发送测试查询、检查服务器网络、查看配置设定，以及掌握集群中分片与副本的分布情况1.3.3 面向CEO的Solr
尽管很多CEO不会阅读这本书，但我们还是在这里提供一些与CEO当面讨论搜索的谈资。
● 高管想要知道当今投资一项技术的长期回报。你可以强调许多公司仍然还在运行2009年发布的Solr 1.4，这意味着Solr是成功的，并在不断完善。
● CEO们喜欢可预见的技术。下一章你就会看到，Solr如此有效，在几分钟内就能启动与运行起来。
● Solr拥有庞大的社区支持。如果一个Solr技术人员外出会发生什么，业务会中止吗？Solr确实是一项复杂的技术，但它背后有活跃的社区支持。也就是说，需要时会有援手。你也可以访问Solr的源代码，一旦出了什么问题需要修复，自己也可以动手处理。许多商业服务商也提供Solr的规划、实施和维护，还提供Solr的培训课程。
● Solr入门不需要太多初始投资（可能CFO对这一点更感兴趣）。无论环境的大小和规模如何，我们都有信心保证你在几分钟之内就启动一个Solr服务器，并快速索引文档。运行在云中的一台普通服务器能够处理百万级数量的文档，以亚秒级速度响应众多查询请求。1.4 功能概述
最后，让我们从以下三个方面快速了解一下Solr的主要功能：
● 用户体验功能
● 数据建模功能
● Solr 4的新功能
搜索解决方案提供出色的用户体验是贯穿本书的重要理念，因此让我们先了解一下Solr是如何让用户感到愉悦的。1.4.1 用户体验功能
Solr提供一些重要功能，使得搜索解决方案简单易用、直观且功能强大。应该注意一点，Solr只提供类REST的HTTPAPI，不为其他编程语言或框架提供搜索相关的UI组件。你可以借鉴下面的用户体验功能，自己动手开发一些搜索UI组件：
●分页与排序
● 分面
● 自动建议
● 拼写检查
● 搜索结果高亮
● 地理空间搜索
分页与排序
Solr支持分页请求，不用一次性返回所有匹配的文档，第一页只返回前N个文档，如果用户在第一页没有找到想要的，可以使用简单的API请求参数请求后续页面。分页有两个重要作用：（1）更迅速地返回结果，因为每个请求只返回了整个搜索结果的一小部分；（2）有助于跟踪哪些查询产生了多个页面请求，这可能会为相关度评分问题提供参考。第7章会详细介绍分页与排序。
分面
分面对搜索结果进行归类分组，帮助用户限定查询条件和发现更多信息。在房地产例子中（参见图1.1），基础关键词搜索的搜索结果被归类到功能配套、家居风格、房屋类型等三个分面中。分面是Solr最受欢迎的强大功能之一。第8章会深入介绍分面。
自动建议
大多数用户会期望搜索应用“做正确的事”，即便自己只提供了不完整的信息。自动建议能够为用户提供一个建议列表，包含基于索引文档的词项和短语。Solr的自动建议功能是在用户开始输入几个字符时，根据输入情况显示一个建议查询列表。自动建议能够减少错误查询的数量，特别是在许多用户使用移动设备的小键盘进行搜索的情况下。
自动建议向用户展示索引中可用的词项与短语。在房地产例子中，当用户输入hig时，Solr的自动建议功能会给出类似highlands neighborhood或highlands ranch的建议。第10章会详细介绍自动建议。
拼写检查
在移动设备满天下且人们都忙忙碌碌的年代，拼写纠错的支持必不可少。再次强调，用户期望搜索引擎能妥善处理拼写错误。Solr的拼写检查支持以下两种基本模式：
● 自动更正 ——如果索引中存在拼写错误的词项，Solr会自动进行更正。
● 你要找的是不是 —— Solr给出的建议查询可能会得到更好的结果，因此当用户输入hilands时可以给出一条提示，例如“你要找的是不是highlands ”。
Solr 4的拼写纠正经过改进后更易管理和维护，第10章将介绍其工作原理。
搜索结果高亮
当搜索大量文本文档时，可以使用Solr的搜索结果高亮功能显示出结果文档的特定部分。搜索结果高亮对越长的文档效果越好。对与用户查询匹配的搜索结果的特定部分进行高亮显示，有助于用户找到相关文档。特定的文本部分基于查询相似度动态生成。第9章将介绍搜索结果高亮。
地理空间搜索
地理位置是Solr 4的高级功能，内置了经度值和纬度值的索引支持，并根据位置距离对文档排序。Solr可以根据地理位置（经度和纬度）对文档进行查找和排序。在房地产例子中，搜索匹配的结果显示在一张交互地图上。用户使用地理空间搜索，通过将地图放大和缩小、移动地图中心点来找到附近的房屋。
Solr 4另一个令人兴奋的附加功能是支持地理形状的索引，如多边形，用以寻找位置相交的地理区域。居民区用精确的地理位置来表征，有助于寻找特定居民区的房源。第15章介绍地理空间搜索1.4.2 数据建模功能
1.1小节讨论了Solr支持的数据类型。本节简要介绍搜索的数据建模功能，具体内容如下：
● 结果分组/字段折叠
● 灵活的查询支持
● 连接
● 文档聚类
● 导入各种文档格式，如PDF和Word
● 从关系型数据库中导入数据
● 多语种支持
结果分组/字段折叠
虽然Solr要求平面、非规范化文档，但我们可以根据文档的共同属性将多个文档归为一组。结果分组，也称字段折叠，返回的结果是成组的，而不是单个文档。
字段折叠的典型例子是线程化的电子邮件讨论。根据特定的查询，邮件会在发起对话的第一个邮件消息下面被分组。第11章介绍结果分组/字段折叠。
灵活的查询支持
Solr提供许多强大的查询功能，包括：
● “与”（AND）、“或”（OR）、“非”（NOT）条件逻辑
● 通配符匹配
● 支持日期和数字的区间查询
● 支持词项间隔距离的短语查询
● 模糊字符串匹配
● 正则表达式匹配
● 函数查询
第7章将详细介绍这些查询功能。
连接
SQL的连接（Join）使用两个及以上的表之间的共同属性（如外键）来抽取数据，从而创建关系，Solr的连接更像是SQL的子查询，不用连接其他文档的数据来创建文档。Solr的连接返回符合搜索条件的子文档。使用单一响应返回一条推文的所有转发，这是Solr的一种连接应用。第15章将讨论连接。
文档聚类
文档聚类根据代表每个文档的词项，将相似的文档分在一组。聚类有助于避免搜索结果中返回很多包含相同信息的文档。例如，要从多个RSS供稿中获取新闻文章的搜索引擎，很有可能得到同一条新闻的多个文档。我们可以通过聚类挑选一条具有代表性的文章，而不是返回同一条新闻的多个文档。第16章会简要讨论聚类技术。
导入各种文档格式，如PDF和Word
某些情况下需要对PDF或Word等常见格式的大量文档进行搜索。对Solr来说这很容易做到，因为它集成了Apache的Tika项目，而
试读结束[说明：试读内容隐藏了图片]