Solr In Action 中文版 第一章（四、五）
最后，让我们再依照以下的分类。高速的过一下Solr的主要功能：
·用户体验
·数据建模
·Solr 4的新功能
在本书中。为你的用户提供良好的搜索体验会一直贯穿全书的主题。所以我们就从用户体验開始。看看Solr是怎样让你的用户感觉到爽的。
1.4.1 用户体验类功能
Solr提供了一系列的重要功能来帮助你搭建一个易用的。符合用户直觉的，功能强大的搜索引擎。
不过你须要注意的是Solr不过提供了类REST风格的HTTP API接口，她并不提供搜索界面相关的UI组件和框架。
你须要卷起袖子来写一个你自己的搜索界面UI，能够充分的利用下面列出的用户体验类功能：
·分页和排序功能
·分类检索功能
·自己主动补全功能
·拼写检查功能
·高亮命中结果功能
·地理位置查询功能
分页和排序功能
Solr 不会返回全部符合查询条件的结果。Solr在分页请求查询结果方面做了优化，每次仅仅有最靠前的N个文档会被在请求第一页结果时返回。假设用户在第一页结果中没有找到想要的信息。那么能够通过非常easy的API调用和请求參数获得兴许页码的内容。分页功能对于两类关键的输出有帮助：1）结果返回的更快了。由于每次查询都仅仅须要返回整个搜索结果中的一个非常小的集合； 2）能够帮助你追踪究竟有多少请求是针对很多其它页码内容的。
这个指标能够反映出你的相关性得分的计算是否有问题。
你会在第7章中具体的了解到分页和排序相关的内容。
分类检索功能：
分类检索功能将搜索结果依照特性分类放到一个个小组中，这就为为用户提供了一个不断优化搜索keyword和浏览搜索结果的工具。在我们的房地产搜索样例中（图1.1）。 我们看到了用户通过主要的查询keyword搜索到的结果被组织到了三个分类中：房屋特征。房型， 和列表类型。分类检索功能是Solr非常受欢迎的强大功能之中的一个，我们在第8章中会具体讨论分类检索。
自己主动补全功能
大多数用户都会期待你的搜索应用在输入的信息不完整的情况下仍然可以正确的返回结果。
自己主动补全功能会依据系统索引文件里的文档内容在用户输入关键词的时候做出对应的自己主动填补建议。Solr的自己主动补全功能使得用户仅仅须要输入少数几个字符就能得到一个依据这些输入字符推荐出来的查询词列表。这能大大减少用户输入错误查询词的几率，尤其是如今非常多用户都会在移动设备上用小键盘输入搜索内容。
自己主动补全功能给用户提供了可选的查询词演示样例。
回到我们的房地产搜索应用样例上。当用户输入”hig“时。Solr的自己主动补全功能会返回：highlands neighborhood 或者 highlandsranch 这种可用查询词。我们会在第十章中具体的介绍自己主动补全功能。
拼写检查
在这个移动设备的时代和人人都非常忙的时代。拼写检查功能显得尤为重要。
用户在输入带有拼写错误的查询词时，仍然会期待搜索引擎可以优雅的自己主动处理掉这些小错误，返回给用户正确的查询结果。Solr的拼写检查支持两种主要的模式：
自己主动纠错模式：Solr能够在用户出现拼写错误的时候自己主动依据该词语在索引中是否存在而做出对应的纠错处理
”您要找的是不是…“功能： Solr也能够依据用户的输入，为用户建议一个更佳的输入方案，比方当用户输入”hilands“时。solr会建议用户”您要找的是不是 highlands?“
拼写检查功能在Solr 4中做了非常大改进。我们会在第10章中做具体的讨论。
高亮命中结果功能
在搜索文本量比較大的文档时。你能够通过Solr的高亮命中结果功能对命中的内容进行高亮显示。这在文本内容非常长的文档中非常有用，用户能够借此功能非常方便的在长长的文本内容中一眼找到命中的搜索内容部分。
我们会在第9章中具体讨论高亮命中功能。
地理位置搜索功能
地理位置搜索是Solr 4 中的一个非常棒的功能，Solr4 自建了对经度值和纬度值的索引支持， 能够对文档依照地理位置的远近做出排序。Solr 能够依据到地理位置上某一点（某一详细的经度和纬度上的一点）的距离，查找出对应的文档记录并对结果排序。
在我们的房地产应用样例中。匹配出来的房源结果能够在互动地图上依据用户的缩放和中心店的移动做地理位置查询。依照与中心点的距离远近对查询结果排序。
Solr 4中还有一个激动人心的功能是你甚至可以通过在地图上画出各种几何图形。比方多边形。依据不同形状之间的交集来做地理位置查询。这在你想要在查找房源的时候可以指定详细的街区地理范围时会非常实用。我们会在第14章中讨论Solr的地理位置查询功能。
1.4.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的话要实现这一点非常easy，由于Solr直接集成了ApacheTika项目，该项目差点儿支持全部的流行文档格式。导入富媒体文档的相关问题在第12章中会具体讨论。
· 从关系型数据库中导入数据的功能
假设你想要搜索的数据是存储在传统的关系型数据库其中的，那你能够配置Solr来通过SQL查询语句创建文档。我们在第12章中会详细讨论怎样使用Solr的数据导入接口（DIH）
· 多种语言的支持
Solr和Lucene对多语言环境的支持已经发展了非常长一段时间了。Solr内建了一个语言自己主动检測系统，对多种不同的语言环境都提供特定语言的文本分析方案支持。我们在第6章会了解到相关的具体内容。
1.4.3 Solr 4的新功能
在我们结束本章之前。让我们来看看Solr 4为我们带来了哪些新的功能。
整体来说第4版对于ApacheSolr社区来说是一个重大的里程碑，一下子解决掉了Solr用户多年来在使用中发现的各种痛点和不方便的地方。我们选了几个功能亮点列在这里，只是须要指出的是Solr4的各种新功能会贯穿本书的各个章节。
· 差点儿实时的搜索查询
· 支持乐观并发机制的原子更新
· 实时获取功能
· 事务日志的持久层写入
· 使用Zookeeper轻松的进行分片操作和复制操作
• 近乎实时的搜索查询
Solr的近乎实时（NRT）查询功能支持应用在索引建立之后几秒钟就能够查询到新增加的文本。
所以利用NRT功能，Solr全然能够应付内容更新会非常快的场景。比方头条新闻或是社交网络之类的应用。我们在第13章会具体讨论NRT。
· 支持乐观并发机制的原子更新
原子更新功能同意client应用能够对现有文档的值域做加入、更新、删除或是添加等操作而并不用又一次发送整个文档给Solr。
比如，假设1.2节中我们的房地产搜索演示样例里房屋的价格发生了变化，那么我们能够简单地发送一个原子更新到Solr更新该条房屋记录的价格就可以，不用又一次发送整条房屋记录的信息。
你可能疑惑假设两个不同的client用户试图同一时候更新同一条文档记录时会怎么样。在这样的情况下，Solr会使用乐观并发机制来避免会产生冲突的更新。
简言之，Solr会用一个特定的叫做_Version_的值域来加强文档更新过程中的安全性。当两个不同用户试图同一时候更新同一文档时，最后提交更新的用户会得到过期版本号的数据，所以其更新请求会失败。
原子更新和乐观并发机制的细节会在第12章中具体讨论。
· 实时获取功能
在本章的开头。我们说明了Solr也属于NoSQL技术的一种。Solr的实时获取功能绝对符合典型的NoSQL方式，它能够让你通过文档的唯一标识获得最新版本号的文档内容，全然不须要考虑新版本号的文档内容是否提交到了索引其中。这一点和有用Key-value存储方式的Cassandra非常像，都是使用一个原始的key来获取key相应的最新数据。
而在Solr 4版本号之前，文本内容必须先要提交到Lucene索引文件里之后才可以被訪问到。而利用Solr4的实时获取功能，通过唯一标识获取文档内容的过程已经安全的同建立Lucene索引的过程分离开了。这在索引已经建立之后对文档内容进行更新的时候非常实用。不用再又一次提交文档内容建立新的索引了。
我们在第5章会看到又一次提交内容的开销非常大，会影响到查询的性能。
·持久层写入
当一个文档被发送到Solr进行索引的建立时。其内容会被写入到一个事务日志中。以避免由于server故障而产生数据的丢失。
Solr的事务日志处于从client应用发送文档过来，到把文档内容提交到Lucene索引文件之间的一个中间状态。它也參与实时获取功能的实现，由于无论文档是否已经提交到了Lucene索引文件里，其内容都能够通过唯一标识提取出来。
事务日志使得Solr能够将更新内容的持久化和更新内容的可见性分离开来。这意味着文档可能会存在于持久化存储中可是在搜索结果中并不可见。你自己的应用能够灵活控制何时将新的文档内容提交到索引中从而使得新文档内容在搜索时能够被检索到。而你并不用操心假设server在你提交索引之前挂掉的话新文档内容会丢失的问题。我们会在第5章讨论持久层的写入问题和提交策略问题。
· 使用Zookeeper轻松的进行分片操作和复制操作
假设你曾经没用过Solr，那你可能不会理解用之前老版本号的Solr进行横向扩展是多么麻烦的一件事情。
而有了SolrCloud之后。横向扩展变得非常easy并且自己主动化了。
由于solr使用了ApacheZookeeper来同步配置和管理主分片及分片的复制备份。在Apache的官方站点上是这样描写叙述Zookeeper的：”这是一个用于维护配置信息，命名，提供分布式同步和分组服务的中心服务“。
在Solr中，Zookeeper负责指定主分片和分片的复制备份。而且负责监控server能否够正常的响应查询请求。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，在你自己的本地机器上执行一下了。
在接下来的第二章。我们就一起来做这件事。
