@tsihedeyo
2014-07-31T15:33:19.000000Z
字数 5227
阅读 4369
翻译 solr_in_action
作业部落编写，zybuluo地址
本章内容涉及：
- 搜索引擎处理的数据特性
- 一般搜索引擎用例
- Solr关键组件
- 选择Solr的原因
- 特性概略
随着社交媒体、云计算、移动应用的发展，软件构架面临处理大基数用户量产生的大数据的挑战。为了提高现代web 应用的可用性以及可扩展性，人们对非关系型数据库（NoSQL）的处理技术越来越感兴趣。不同于把所有的数据都填入标准的关系模型中的处理方式，这些系统展示了对不同的数据类型进行匹配、存储以及处理的引擎设计。换言之，NoSQL技术致力于解决特殊类型的数据的一系列问题。这类需求促生了许多NoSQL和关系型数据库融合的架构，也淘汰了大一统的数据处理模式。
此书内容是关于一种特殊NoSQL技术Apache Solr.Solr是个可扩展、易部署的企业级搜索引擎，旨在优化大量的文本搜索，按相关强度返回搜索结果。具体特性如下：
- 可扩展 —— 分布式作业（索引、查询），可分布式部署在服务器集群中
- 易部署 —— 开源、易安装、可配置（有配置示例）
- 优化搜索 —— 亚秒级处理复杂查询，通常为几十毫秒
- 海量文档 —— 处理百万级文档索引
- 以文本为中心 —— 优化自然语言文本搜索，如邮件、网页、回执、PDF文档、社交信息（如tweets、blogs）
- 相关性排序 —— 查询结果按相关度排序返回
此书中你可学习到如何使用Solr来设计并完成可扩展的查询方案。首先了解Solr支持的数据类型以及使用案例，以此认清Solr在现代应用架构中的位置以及Solr针对解决的问题。
直接思考你的数据和需求来判断你是否需要使用搜索引擎。之后，理解你的数据以及用户来选择适合的技术。首先来了解搜索引擎可优化处理的数据特性。
可用来匹配和处理你的数据的引擎有一大堆。如果你是程序员，你一定知道要根据算法来选择最佳的数据结构，比如你不会用来链表结构来实现数据的随机访问。选择搜索引擎的原则也是一样。像Solr这样的搜索引擎可用来优化处理有以下四种特性的数据
- 以内容为中心 ( text-centric )
- 阅读为主( read-dominant)
- 文档类( document-oriented)
- 灵活分类（Flexible schema）
第5个特性应该是涉及到大数据的处理，然而我们更注重于分析搜索引擎与其他NoSQL技术的区别，而且Solr对大数据量的支持是毫无疑问的。
虽然给出了这四个特性，但是这是个是个粗略的标准，不能把当成严格的规则看待。下面逐条分析为何他们对搜索有很大的影响，此章节中我们停留于抽象概念，之后的章节中再探讨"how"。
通常我们都会使用unstructed来形容搜索引擎处理的数据类型，由于基于人类语言的文档其实是有一定的结构，我们认为unstructed并不是十分妥当。但对于电脑来说这些文本只是字符流，所以可认为是unstructed。搜索引擎做的就是按照一定的语言规则解析这个字符流，提取规则，使得这些字符流可以被搜索到。
由于Solr引擎被设计来提取掉文本暗含的结构，将文本转为索引来提高搜索效率，所以我们认为text-centric(文本为中心)更适合来描述Solr处理的数据类型。文本为中心的数据也表示此文档的文本也是用户希望搜索的内容。当然，搜索引擎也支持非文本的搜索（如日期、数字），但是基于自然语言的文本搜索才是搜索引擎的优势。
中心这个字段很重要，因为如果你的用户对文本的内容并不感兴趣，那么搜索引擎可能并不适合你。比如在一个用于产生雇员旅游费用报表的应用中，每个报表包含了结构化的数据（日期、费用类型、货币类型、数额），当然每次费用记录也可能包含一个文本字段用来给雇员简略描述该次费用记录。虽然这是一个文本字段，但是对于财政部门来说核实每月旅游费用报表时，此部门不大可能会去查询这些描述字段。这样我们就说这个数据类型就不是文本为中心，所以数据含有文本字段也不能说此类数据的查询就适合用搜索引擎来处理。
考虑你的数据是否是文本为中心，即数据中的文本字段是否包含有用户会用来搜索的内容。在第5章以及第6章中，可以了解Solr的文本分析是如何分离文本暗含的结构的。
另一个重要的特性是阅读为主的，即更倾向于高效得获取而不是经常性得更改。首先明确Solr确实允许用户更新已有索引的文件，阅读为主只是说文件被阅读的次数应该远高于文件被创建或者修改的次数，但不要把此理解为Solr不允许你写入大量的数据或者Solr限制了你写入新数据的次数。事实上，Solr4的一个重要特性就是接近实时（NRT）的查找，即每秒索引上千的文档，实现对他们的立即搜索。
阅读为主的关键在于当你向Solr写入数据后，该数据应该是在他的生命周期内被无数遍的读取与再读取。明确你的搜索引擎是优化了查询的执行（读操作），而不是优化了数据的存储（写数据）。同时，如果你需要经常更新搜索引擎的现有数据，那么使用搜索引擎也很可能不是你的最优解决方案。对于需要实现对已有数据的快速更改，其他的NoSQL技术，比如Cassandra可能更适合。
目前为止，我们讨论的都是数据，实际上搜索引擎操作的对象是文档。在搜索引擎内部，一个文档就是一个包含自身的域集合，其中每个域只包含数据并不存在嵌套域。换言之，在像Solr这样的搜索引擎中，一个文档就是扁平结构（flat structure），不依赖于其他文档。扁平这个概念在Solr中比较松，即在这个域中可以有多个值，但是域不能包含子域，你可以在一个域中存多个值，但是不能再域中嵌套（引用，类比关系型数据库的外键猜测）域。
在Solr中，扁平化文档类的处理方式对于已经是文档结构的数据十分合适，包括网页、博客以及pdf文档。但是对于关系库中存储的标准化模型呢？这种情况下，你需要将联系多个表将这种标准化数据解构成扁平的、只包含自己的文档结构。在第三章中将了解如何处理这种情况。
你还必须去考虑哪些文档应该存在Solr中，哪些应该存在其他系统（如数据库）中。除非这些数据对于搜索或者结果展示有帮助，否则这些数据不应该存在Solr中。例如，如果你有网上视频的索引，你不应该将这些二进制视频文件存在Solr中，这些巨大的二进制应该存在另一个系统（如内容分布式网络CDN）中。总而言之，Solr中只存储能满足搜索需要的最少数据。这个例子说明不要把Solr当成数据存储技术，Solr的工作是找到用户感兴趣的视频，而不是去管理这些巨大的二进制文件。
搜索引擎数据的最后一个特性是数据能灵活分类，即在索引中的文档不需要有统一的结构。在关系型数据库中，表的每一行都是相同的结构。在Solr中，文档可以有不同的域。当然同一索引下的文档之间域应该会有点重叠，但是不需要唯一。（不懂）
试想一个搜索出租或出售房的应用，显然这两个列表都有位置、卧室数、洗漱间数这些域（字段？），但是根据列表类型的不同他们也会有不同的域。出售房有价格字段以及年房产税字段，而出租房则有每月房租字段以及宠物协议字段。
总的来说，大部分的搜索引擎,尤其Solr旨在优化处理拥有这四个特性的数据，同时这也表明Solr不是个通用的数据存储以及处理技术。
存储和处理数据有如此多的选项的意思在于你并不需要去寻找一个一对多的技术，搜索引擎擅长处理某些情况，也可能在另外一些情况在工作效益很差。以上用例都是为了帮助你理解搜索引擎域其他数据处理技术的不同。
本节中介绍可以用Solr处理的情况，与1.1节类似，此节中讨论的数据类型仅供参考，不要当成严格的规则。深入之前，首先申明，搜索界的达到优秀门槛很高。现代用户习惯与Google和Bing提供的快速网页查询，而且大多数优秀的网页都有很有效的搜索方法给用户快速提供信息。当你在评估像Solr这样的搜索引擎以及设计你的搜索方法时，确保你将用户的体验放在高优先级上。
显而易见，搜索引擎支持关键字查询。既然这是搜索引擎的主要目的，拿他就值得一提，而关键词查询也经常是用户使用你的提供的查询方法的方式。很少有用户会想填写复杂查询的表单，关键字查询时用户与你的搜索引擎交互的最普遍的方式，所以关键字查询必须提供良好的用户体验。
通常，用户希望输入少量的关键字而得到非常好的查询结果。听起来可能是一个很简单的文档匹配，但是为了提供良好的用户体验，有以下几点需要
注意：
- 相关结果必须快速返回，多数情况应该不多于1秒
- 提供拼写修正以防用户输入的查询项中有拼写错误
- 自动补全减少按键数，特别是移动应用
- 同义词查询的识别
- 查询项目的语言变异必须要识别
- 词组的处理，即用户是希望匹配这个词组还是匹配词组中任意一个词
- 常见词查询的处理，如'a,'，'an,','of,','the'
- 当用户对返回的头几条结果不满意时，用户可以看到更多的结果
可见，这些状况的存在使得一个看似基本的查询也需要去斟酌实现方法。利用搜索引擎，我们可以简单实现。你给用户提供了有效的工具完成关键字查询后，你需要考虑如何进行结果的展示，这就涉及到下一个用例，查询结果的相关性排序。
搜索引擎只是单单提供了返回查询的前几条文档的方法。在SQL查询中，某行记录要么匹配要么不匹配查询，返回的结果也是按照一行或者多行来排序返回的。搜索引擎返回的文档则是某个分数来排序的，该分数指示了文档与当前查询的相关强度。相关强度的计算域很多因素有关，一般来说分数越高该文档与查询越相关。
对文档的相关度排序十分重要，理由如下：
- 现代搜索引擎通常都存储了百万甚至上亿的海量数据，查询若不按相关度排序，则用户很可能在返回的结果中迷失。
- 用户更希望只用很少的关键字就从搜索引擎中查到结果。用户没有耐心，也希望搜索引擎能搜索用户所想而不是用户所说。在移动应用中，这个更为明显，因为移动用户很可能打错字，且输入很少。
你可以通过设定一些权重给制定的文档、字段或者特定的项目来调整排序，你可以通过文档的时长（age）来提升结果，使得更新的文档排在搜索结果的前头。在第三章中会进一步了解文档的排序。
利用像Solr这样的搜索引擎，用户可以通过输入少量的关键字来获取查询结果。对于大多数用户来说，这只是搜索的第一步，这一步返回的结果可以进行下一步的探索。搜索引擎还有一个主要用例就是执行信息检索，通常，你的用户并不知道他们真正在找什么，也不知道你的系统中包含了什么样的信息。好的搜索引擎可以帮助用户缩小他们的需求范围。
此段的大意就是从初始的查询中返回一堆文档，同时也提供工具给用户进行重新搜索。换言之，除了返回给用户匹配的文档，你还需要返回可以告诉你的用户下一步该做什么的工具。例如，你可以通过文档的特征给查询结果分类，使得用户可以过滤他们得到的结果。这就是分面搜索（faceted search），也是Solr的一个主要优势。在1.2节中你会看到示例。第八章中将对此详细讨论。
下面来讨论哪些情况下不适合使用搜索引擎。第一种，搜索引擎被设计为每次返回少量的文档（10-100）.通过Solr的内置分页支持，我们可以获取更多的查询结果。设想一个查询匹配了百万条结果，如果你需要一次就请求所有的这些文档，那你需要等待很长一段时间。查询本身执行得很快，但是从索引还原百万级的文档确很耗时。像Solr这样的搜索引擎将文件存储以某种形式存储在硬盘中，从这种形式很容易构建一些文档，但是从这种形式中构建大量的文档确会很耗时。
另一个不适合使用搜索引擎的情况是需要获取大量索引的深度分析任务（除非你内存够大）。就算你通过使用搜索结果的分页避免了第一种情况，搜索引擎索引的底层数据结构并不适合一次获取大量的索引。
我们之前已经说过，在这再说一遍，搜索引擎不适合查询文档之间的关系。Solr确实支持父子关系的查询，但不支持其他像SQL中那样的复杂查询。在第3章中，你会知道如何将关系型数据改造成Solr的扁平文档结构。
同时，至少在Solr中，搜索引擎不直接支持文档层的安全。如果你需要细粒度的文档权限管理，你需要在搜索引擎外部处理。
至此我们已经了解了适合以及不适合使用搜索引擎的数据类型，是时候深入Solr并更进一步了解Solr的运作。下一章，你将了解Solr的特性以及Solr在软件架构上的应用，比如如何与外部系统结合，其扩展性以及高可靠性。