Solr In Action 中文版 第一章（四、五）

1. 4              功能概览

最后， 让我们再按照下面的分类，快速的过一下Solr的主要功能：

·用户体验

·数据建模

·Solr 4的新功能

在本书中，为你的用户提供良好的搜索体验会一直贯穿全书的主题。所以我们就从用户体验开始，看看Solr是如何让你的用户感觉到爽的。

1. 4.1              用户体验类功能

Solr提供了一系列的重要功能来帮助你搭建一个易用的，符合用户直觉的，功能强大的搜索引擎。不过你需要注意的是Solr仅仅是提供了类REST风格的HTTP API接口，她并不提供搜索界面相关的UI组件和框架。你需要卷起袖子来写一个你自己的搜索界面UI，可以充分的利用以下列出的用户体验类功能：

·分页和排序功能

·分类检索功能

·自动补全功能

·拼写检查功能

·高亮命中结果功能

·地理位置查询功能

分页和排序功能

Solr 不会返回所有符合查询条件的结果。Solr在分页请求查询结果方面做了优化，每次只有最靠前的N个文档会被在请求第一页结果时返回。如果用户在第一页结果中没有找到想要的信息，那么可以通过很简单的API调用和请求参数获得后续页码的内容。分页功能对于两类关键的输出有帮助：1）结果返回的更快了，因为每次查询都只需要返回整个搜索结果中的一个很小的集合； 2）可以帮助你追踪到底有多少请求是针对更多页码内容的。这个指标可以反映出你的相关性得分的计算是否有问题。你会在第7章中详细的了解到分页和排序相关的内容。

 

分类检索功能：

分类检索功能将搜索结果按照特性分类放到一个个小组中，这就为为用户提供了一个不断优化搜索关键字和浏览搜索结果的工具。在我们的房地产搜索例子中（图1.1）， 我们看到了用户通过基本的查询关键字搜索到的结果被组织到了三个分类中：房屋特征， 房型， 和列表类型。分类检索功能是Solr很受欢迎的强大功能之一，我们在第8章中会详细讨论分类检索。

 转载请注明原文出处http://my.oschina.net/fengnote

自动补全功能

大多数用户都会期待你的搜索应用在输入的信息不完整的情况下仍然能够正确的返回结果。自动补全功能会根据系统索引文件中的文档内容在用户输入关键词的时候做出相应的自动填补建议。Solr的自动补全功能使得用户只需要输入少数几个字符就能得到一个根据这些输入字符推荐出来的查询词列表。这能大大降低用户输入错误查询词的几率，尤其是现在很多用户都会在移动设备上用小键盘输入搜索内容。

自动补全功能给用户提供了可选的查询词示例。回到我们的房地产搜索应用例子上，当用户输入”hig“时，Solr的自动补全功能会返回：highlands neighborhood 或者 highlands ranch 这样的可用查询词。我们会在第十章中详细的介绍自动补全功能。

 

拼写检查

在这个移动设备的时代和人人都很忙的时代，拼写检查功能显得尤为重要。用户在输入带有拼写错误的查询词时，仍然会期待搜索引擎能够优雅的自动处理掉这些小错误，返回给用户正确的查询结果。Solr的拼写检查支持两种基本的模式：

自动纠错模式：Solr可以在用户出现拼写错误的时候自动根据该词语在索引中是否存在而做出相应的纠错处理

”您要找的是不是…“功能： Solr也可以根据用户的输入，为用户建议一个更佳的输入方案，比如当用户输入”hilands“时，solr会建议用户”您要找的是不是 highlands?“

拼写检查功能在Solr 4中做了很大改进，我们会在第10章中做详细的讨论。

 

高亮命中结果功能

在搜索文本量比较大的文档时，你可以通过Solr的高亮命中结果功能对命中的内容进行高亮显示。这在文本内容很长的文档中很实用，用户可以借此功能很方便的在长长的文本内容中一眼找到命中的搜索内容部分。我们会在第9章中详细讨论高亮命中功能。

 

地理位置搜索功能

地理位置搜索是Solr 4 中的一个很棒的功能，Solr 4 自建了对经度值和纬度值的索引支持， 可以对文档按照地理位置的远近做出排序。Solr 可以根据到地理位置上某一点（某一具体的经度和纬度上的一点）的距离，查找出相应的文档记录并对结果排序。在我们的房地产应用例子中，匹配出来的房源结果可以在互动地图上根据用户的缩放和中心店的移动做地理位置查询，按照与中心点的距离远近对查询结果排序。

         Solr 4中另一个激动人心的功能是你甚至可以通过在地图上画出各种几何图形，比如多边形，根据不同形状之间的交集来做地理位置查询。这在你想要在查找房源的时候能够指定具体的街区地理范围时会很有用。我们会在第14章中讨论Solr的地理位置查询功能。

 

 

1. 4.1.2              数据建模类功能

正如我们在第1.1节中讨论的那样，Solr对特定类型的数据处理做了优化。在本节中，我们列出了你在为搜索建立数据模型时可能会用到的一系列关键功能，包括：

·          值域的合并和分组功能

·          灵活的查询支持功能

·          连接功能

·          归集功能

·          从PDF和word等格式的文档中导入富媒体数据的功能

·          从关系型数据库中导入数据的功能

·          多种语言的支持

 

·          值域的合并和分组功能

虽然Solr要求处理的文档尽量的扁平化、非规格化，但还是允许你将多个文档按照大家共有的某种属性进行归组管理。值域分组，也被称为值域的合并，允许你在返回结果时除了可以返回一个个的文档之外还可以返回一个特定的文档分组。

关于值域分组功能的一个经典的例子就是邮件列表，我们可以把所有符合查询条件的同一主题的邮件都附在以最早引发会话的那封邮件开头的一个邮件列表里返回给用户。你将会在第11章中学到更多的关于值域分组的内容。

 

·          强大而灵活的查询支持功能

Solr提供了一系列强大的查询功能，包括：

·     支持与（and）， 或（or），非（not）的条件逻辑

·     支持通配符匹配

·  支持日期和数字的范围查询

·          支持模糊的短语查询

·          支持模糊字串匹配

·          支持正则表达式匹配

·          支持功能查询

如果你对其中的一些名词不熟悉没有关系，我们会在第7章中深入讨论。

·          连接功能

在SQL中你可以使用JOIN来创建一个链接关系，将两张或多张表之间的数据通过一个称之为Foregn Key的共有属性连接起来。但是在Solr中，join操作更像是SQL中的子查询，只是你并不会通过链接文档之间的数据而创建新的文档。例如，通过Solr的join功能， 你可以返回父文档符合查询条件的子文档。Solr连接功能在你需要拿到某条推特或是微博的所有评论时很有用，所有评论都是原文的子文档。我们会在第14章中详细讨论该功能。

 

·          文档归集

文档归集功能允许可以根据每个文档的描述将相似的文档归为一组。

这有助于避免在返回查询结果时返回很多内容很近似的文档结果。例如，如果你的搜索引擎是一个新闻应用，通过多个RSS链接来推送文章，那么你很可能会同时收到很多关于同一条新闻的报道。把这些内容差不多的报道都返回给用户显然不是一个好主意，此时你可以使用文档归集功能把这些类似的报导分成一组，选取一篇有代表性的报道返回给用户就妥了。归集技术会在第17章做详细讨论。

 

·          从PDF和word等格式的文档中导入富媒体数据的功能

在某些场合下，你可能需要处理一些已有的通用格式文档，比如PDF和微软word文档之类的，你需要这些文档也能被检索。用Solr的话要实现这一点很简单，因为Solr直接集成了Apache Tika项目，该项目几乎支持所有的流行文档格式。导入富媒体文档的相关问题在第12章中会详细讨论。

·          从关系型数据库中导入数据的功能

如果你想要搜索的数据是存储在传统的关系型数据库当中的，那你可以配置Solr来通过SQL查询语句创建文档。我们在第12章中会具体讨论如何使用Solr的数据导入接口（DIH）

·          多种语言的支持

Solr和Lucene对多语言环境的支持已经发展了很长一段时间了。Solr内建了一个语言自动检测系统，对多种不同的语言环境都提供特定语言的文本分析方案支持。我们在第6章会了解到相关的详细内容。

1. 4.1.3              Solr 4的新功能

在我们结束本章之前，让我们来看看Solr 4为我们带来了哪些新的功能。总体来说第4版对于Apache Solr社区来说是一个重大的里程碑，一下子解决掉了Solr用户多年来在使用中发现的各种痛点和不方便的地方。我们选了几个功能亮点列在这里， 不过需要指出的是Solr4的各种新功能会贯穿本书的各个章节。

·          几乎实时的搜索查询

·          支持乐观并发机制的原子更新

·          实时获取功能

·          事务日志的持久层写入

·          使用Zookeeper轻松的进行分片操作和复制操作

 转载请注明原文出处http://my.oschina.net/fengnote

•       近乎实时的搜索查询

Solr的近乎实时（NRT）查询功能支持应用在索引建立之后几秒钟就可以查询到新加入的文本。所以利用NRT功能，Solr完全可以应付内容更新会很快的场景，比如头条新闻或是社交网络之类的应用。我们在第13章会详细讨论NRT。

·          支持乐观并发机制的原子更新

原子更新功能允许客户端应用可以对现有文档的值域做添加、更新、删除或是增加等操作而并不用重新发送整个文档给Solr。例如，如果1.2节中我们的房地产搜索示例里房屋的价格发生了变化，那么我们可以简单地发送一个原子更新到Solr更新该条房屋记录的价格即可，不用重新发送整条房屋记录的信息。

你可能疑惑如果两个不同的客户端用户试图同时更新同一条文档记录时会怎么样。在这种情况下，Solr会使用乐观并发机制来避免会产生冲突的更新。简言之，Solr会用一个特定的叫做_Version_的值域来加强文档更新过程中的安全性。当两个不同用户试图同时更新同一文档时，最后提交更新的用户会得到过期版本的数据，所以其更新请求会失败。原子更新和乐观并发机制的细节会在第12章中详细讨论。

·          实时获取功能

在本章的开头，我们说明了Solr也属于NoSQL技术的一种。Solr的实时获取功能绝对符合典型的NoSQL方式，它可以让你通过文档的唯一标识获得最新版本的文档内容，完全不需要考虑新版本的文档内容是否提交到了索引当中。这一点和实用Key-value存储方式的Cassandra很像，都是使用一个原始的key来获取key对应的最新数据。

而在Solr 4版本之前，文本内容必须先要提交到Lucene索引文件中之后才能够被访问到。而利用Solr4的实时获取功能，通过唯一标识获取文档内容的过程已经安全的同建立Lucene索引的过程分离开了。这在索引已经建立之后对文档内容进行更新的时候很有用，不用再重新提交文档内容建立新的索引了。我们在第5章会看到重新提交内容的开销很大，会影响到查询的性能。

·持久层写入

当一个文档被发送到Solr进行索引的建立时，其内容会被写入到一个事务日志中，以避免因为server故障而产生数据的丢失。Solr的事务日志处于从客户端应用发送文档过来，到把文档内容提交到Lucene索引文件之间的一个中间状态。它也参与实时获取功能的实现，因为不管文档是否已经提交到了Lucene索引文件中，其内容都可以通过唯一标识提取出来。

事务日志使得Solr可以将更新内容的持久化和更新内容的可见性分离开来。这意味着文档可能会存在于持久化存储中但是在搜索结果中并不可见。你自己的应用可以灵活控制何时将新的文档内容提交到索引中从而使得新文档内容在搜索时可以被检索到。而你并不用担心如果服务器在你提交索引之前挂掉的话新文档内容会丢失的问题。我们会在第5章讨论持久层的写入问题和提交策略问题。

·          使用Zookeeper轻松的进行分片操作和复制操作

如果你以前没用过Solr，那你可能不会理解用之前老版本的Solr进行横向扩展是多么麻烦的一件事情。而有了SolrCloud之后，横向扩展变得很简单而且自动化了。因为solr使用了Apache Zookeeper来同步配置和管理主分片及分片的复制备份。在Apache的官方网站上是这样描述Zookeeper的：”这是一个用于维护配置信息，命名，提供分布式同步和分组服务的中心服务“。

在Solr中，Zookeeper负责指定主分片和分片的复制备份，并且负责监控服务器是否可以正常的响应查询请求。SolrCloud已经绑定了Zookeeper服务，所以你不需要再做额外的配置就可以启动SolrCloud。我们会在第16章中详细讨论SolrCloud相关的内容。

1. 5                  总结        

我们希望现在你已经对Solr典型用例和支持的数据类型有了一个直观的认识。正如你在1.1节中所学到的，Solr对4类数据的处理做了优化，包括以文本内容为中心的数据，读取远胜于写入的数据，面向文档的数据，以及schema比较灵活的数据。我们也学习到了类似Solr这样的搜索引擎并不是通用的数据存储和处理方案， 而是用来处理关键词搜索，对结果进行排序，以及帮助用户在结果中浏览和发现更符合要求的信息用的。通过一个虚拟的房地产搜索应用，我们了解到了Solr是如何在Lucene的基础上建立索引的，是如何通过基于HTTP， XML和JSON等方式的网络服务来配置管理索引建立规则的。Solr4可以通过分片功能和复制扩展两种机制来满足海量数据的高并发查询需求。Solr4不会有单点失败的问题。

我们也分别站在公司不同角色的角度分别讨论了选择Solr可以带来的一些关键的好处。我们看到了Solr是如何解决软件架构师，系统管理员甚至是公司CEO所可能提出的疑问的。最后，我们粗略的过了一遍Solr的主要功能，并提供了一个阅读指南，让你可以迅速的找到感兴趣的内容所在的章节。

我们希望看到这里你会很兴奋的想要继续学习Solr的旅程，那么现在是时候去下载一个最新的Solr，在你自己的本地机器上运行一下了。在接下来的第二章，我们就一起来做这件事。