学习《Solr实战》笔记-----Solr入门

1.Solr特点

• 可扩展-----Solr通过集群中多态服务器的分布式运行实现扩展。
• 开箱即用----Solr是开源的，易于安装和配置，并提供预先配置好的实例服务器，方便上手。
• 为搜索优化----Solr速度很快，以亚秒级速度执行复杂查询，往往只需花费几十毫秒。
• 大规模文档----Solr可以用于处理包含百万级文档的索引。
• 根据相关度对结果排序-----Solr根据文档与用户查询的相关程度对文档进项排序，并以此顺序返回结果文档。
• 以文本为中心----Solr针对自然语言文本所搜进行优化，如电子邮件、网页、简历、PDF文档、社交信息（推文和博客）。

2.为什么需要搜索引擎

        当我们访问购物网站的时候，我们可以根据我们随意所想的内容输入关键字就可以查询出相关的内容，这是怎么做到呢？这些随意的数据不可能是根据数据库的字段查询的，那是怎么查询出来的呢，为什么千奇百怪的关键字都可以查询出来呢？
        答案就是全文检索工具的实现，luncence采用了词元匹配和切分词。举个例子：北京天安门----luncence切分词：北京  京天  天安  安门  等等这些分词。所以我们搜索的时候都可以检索到。
有一种分词器就是IKanalyzer中文分词器，它有细粒度切分和智能切分，即根据某种智能算法。
这就使用solr的最大的好处：检索功能的实现。

3.管理以文本为中心的数据

        Solr搜索引擎擅长处理的数据表现为4个主要特征：以为本位中心、读主导、面向文档、灵活的模式。

以为本位中心：（擅长处理以文本为中心的数据）

        在描述有搜索引擎处理的数据类型时，必然会遇到非结构化这一术语。因为基于人类语言的文本文档都有隐含的结构。从计算机角度来看文本就是字符流，字符流必须使用特定语言规则来抽取结构，并使其可以搜索。这正是搜索引擎要做的。

        我们认为以文本为中心格式和描述solr处理的数据类型，因为搜索引擎是专门用于将文本的隐含结构抽取到索引中，从而改善搜索的。

        搜索引擎也支持非文本数据，如日期和数字，但是搜索引擎主要优势是处理基于自然语言的文本数据。如果用户对文本中的信息不感兴趣，搜索引擎可能就不是解决问题的最佳方案了。

读主导：（数据不常更新）

        搜索引擎擅长处理的数据的另一个关键特征是读主导，即实现有效读取，且无需经常更新的数据。solr是可以对索引中的已有文档进行更新的。读主导可以理解为文档被读取的次数远多于被创建和更新的次数。然而这并不代表不能写入大量数据，或限制写入新数据的频次。事实上，solr4的一个关键特性就是近实时（Near Real-Time，NRT）搜索，允许每秒索引数千文档，并且几乎立时就能搜索到它们。

        读主导数据背后关键点是，当向solr写入数据时，要做好读取和虫谷读无数次的准备。搜索引擎擅长查询数据（读操作），而非存储数据（写操作），如果对搜索引擎中的已有数据经常更新、快速随机写操作的情况，那么其他的NoSQL技术会是一个不错的选择。

面向文档

        在搜索引擎中，文档是字段的自包含集合，每个字段近包含数据而不包含嵌套字段，换句话说，solr这样的搜索引擎中文档是平面结构，而且不是依赖与其他文档。在solr中，“平面”的概念稍有放宽，一个字段可以有多个取值，但字段不包含子字段。在单一字段中可以存储多个值，但不能在其他字段里嵌套字段。

        solr面向文档的平面结构方法能很好地处理各种文档格式的数据，如网页、博客、PDF文件，那么如何对关系型数据库中的规范化数据进行建模呢？在这种情况下，需要对分布在多个表中的数据去规范化，将其组织成一个平面、自包含文档结构。

        还要考虑到，文档的哪些字段必须存储在solr中，哪些应该存储在其他系统中，除非数据对搜索或显示结果有用，否则不舍和存储在搜索引擎里。例如对视屏创建索引时，二进制视频文件不应再solr中存储，大型二进制字段应该存储在其他系统中，如内容分发网络（Content-Distribution Network，CDN）。通常，为了满足搜索需求，应该存储是索引的每个文档信息的最小集合。视屏例子清除的说明了不要讲Solr作为通用数据存储技术，solr任务是找到兴趣相关的视频，而不是管理大型二进制文件。

灵活的模式

        solr这样的搜索引擎擅长处理的数据的最后一个主要特征是具有灵活的模式。也就是说，索引的文档不必拥有统一的结构。在关系型数据库中，表中的每一行都具有相同的结构。在solr中，文档可以有不同的字段，。当然，同一索引的文档字段之间可能存在一些重叠，但它们不必是相同的。

4.常见的搜索引擎用例

基础关键词搜索

        搜索引擎支持关键词搜索，这是它的主要功能。关键词搜索是用户使用你的搜索解决方案时最典型的一种方式，没有用户想要一开始就填写复杂的搜索表单。为了达到出色的用户体验，必须考虑一下几点：

• 必须快速返回相关结果，大多数情况下应该在一秒之内或更短。
• 在用户拼错一些查询词语时，需要进行拼写纠错。
• 自动建议会减少击键次数，特别是对移动用于而言。
• 匹配包含查询词项语言形式变化的文档。
• 短语处理是必要的，即用户想要匹配整个短语或部分文字。
• 必须处理查询中包含“a”、“an”、“the”等常用词。
• 如果用户对排名号前的搜索结果不满意，必须能继续查看更多结果。

        solr为代表的搜索引擎，以上几点要求是开箱即用的，使用起来非常方便，为用户提供强大的工具来执行关键词搜索之后，需要考虑的是如何显示搜索结果。这就引出了下一个用例：基于用户查询相关度的搜索结果排名。

排名检索

        搜索引擎根据文档与查询匹配的程度为文档赋分，并按照降序返回结果，匹配程度的计算取决于多个因素，一般而言，文档得分越高意味着该文档与查询的相关性越强。根据相关度对文档进行排名是非常重要的，原因如下：

• 现代搜索引擎通常存储大量文档，往往以百万计或数十亿计。若不根据查询结果相关度对文档进行排名，就会缺乏清晰的导航方式，用户将无法应对搜索结果。
• 用户更习惯于使用那些只需要输入几个关键词技能找到结果的搜索引擎。用户没有耐心，希望搜索引擎能够达到“不用我说，你懂得”的境界。在移动应用背后的搜索中，用户输入存在拼写错误的短查询，并期望其有效，这是显示情况的写照。

        通过为特定文档、字段或者指定词项赋予更高的权重或者加权，可以影响文档排名。例如，通过对提升时间字段权重，可以将较新的文档提升到搜索结果得前列。

超越关键词搜索

        此处核心思想是从初始查询返回文档，以及提供工具帮助用户限定搜索。换句话说，除了返回匹配的文档之外，还应该告诉用户下一步该怎么做。例如，根据文档特征对搜索结果进行分类，方便用户缩小搜索范围，这就是所谓的分面搜索，是solr的强项之一。

        不要将搜索引擎用于查询匹配的文档一次性全部返回这些文档，等待时间会很长，可以使用solr内置的分页功能获取。查询本身的执行速度可能很快，但是从底层索引结构上重构大量的文档极其缓慢，solr使用特定格式将字段存储在磁盘上，这种格式适用于创建少量文档，但生成结果时需要重构大量文档的话，速度很慢。另一个用例是，除非你内存足够大，否则不要使用搜索引擎去完成深度分析任务，这需要访问大部分索引，机时通过分页解决上述问题，底层索引的数据结构也并不适合一次检索大部分索引。搜索引擎无法检索文档之间的关系。solr确实支持“父子”关系的查询，但不支持SQL复杂关系型数据结构中的关系发现。

        大多数搜索引擎都不直接支持文档级别的安全策略，至少solr没有，如果需要细粒度的文档权限，这就不属于搜索引擎范畴了。

5.Solr是什么？

在了解solr到底是什么之前，我们先明确solr不是什么？

• Solr不是Google或Bing这样的网络搜索引擎。
• Solr不具备网站搜索引擎优化（SEO）方面的功能。

Solr构建在Apache的Lucene之上，Lucene是一个广受欢迎的基于Java的开源信息检索库。

信息检索（Information Retrieval，IR）是从大规模集合（通常存储在计算机）中查找满足特定信息需求的具有非结构化性质（通常是文本）的资料（通常是文档）的过程。

        Solr使用Lucene来实现索引文档的核心数据结构，并执行文档搜索。Lucene是一个Java类库，用于倒排索引（倒排表）的构建与管理，倒排索引是专门用于匹配查询词项与文本文档的数据结构。

灵活的模式管理

        虽然Lucene提供文档索引和查询执行的类库，但是缺少生成索引结构的简单配置方法，定义字段和分析字段都需要编写Java代码。Solr后台使用schema.xml表示所有可能的字段和数据类型，将文档映射为Lucene索引。Solr构建的索引与Lucene编程方式构建的索引是完全兼容的。

        Solr增加了复制字段（copy field）和动态字段（dynamic field）。复制字段取得一个字段或多个字段的原始文本内容，并将其赋予不同的字段。动态字段允许将同一个字段类型赋予多个不同字段，而不需要在schema.xml中显示声明。

        自solr 5之后，solr默认使用managed-schema，通过Schema API动态修改模式。schema.xml是通过直接编辑文件来修改模式。两者作用是相同的。

        Lucene提供了文档索引、查询执行和结果排名的强大类库，通过schema.xml就可以使用XML配置文档灵活的定义索引结构，无需再使用Lucene的API进行编程。

Java Web应用

Solr是一个Java Web 应用，可以运行在任何主流Java Servlet引擎中，例如Jetty和Tomcat，或JBoss、Oracle AS这样的J2EE应用服务器。

solr 的主要构成图。

        Solr为实现轻松集成的目标，solr的核心服务器需要访问许多不同的应用和编程语言。solr基于已有的XML、JSON和HTTP标准，提供简单的类似REST服务，由于solr并没有严格遵守所有的REST原则，因此要避免为solr基于HTTP的API打上REST风格标记，例如，在solr中删除文档使用HTTP的POST方法，而不是用HTTP的DELETE方法。

开发者往往喜欢使用编程语言的客户端进行访问，大多数编程语言都有solr的客户端。

一台服务器上的多个索引

        Solr所提供的帮助之一是允许你不必把所有内容放在Solr的一个索引里。Solr支持在单个引擎上运行多个内核。Solr支持多个内核的一个用途就是数据分区，例如一个内核处理最近的文档，另一个处理较久的文档，这就是所谓的时间顺序分片（chronological sharding）。多核的另一个用途是支持多租户引用。

可扩展性（插件）

        Solr三个主要子系统：文档管理、查询处理和文本分析。这都是solr复杂子系统的高度抽象，每个子系统都是有模块化的“管道”构成的，通过插件方式实现新功能，这就意味着没必要推翻solr的整个查询处理引擎，只需要在已有管道中接入新的搜索构件即可。这使得solr核心功能易于扩展，并能根据特定应用需求实现定制。

可伸缩性

        Solr汲取了Lucene速度方面的所有优点，但是无论Lucene有多快，由于CPU的I/O限制，单台服务器终会达到来自不同用户的并发请求的处理上限。

        实现伸缩性第一步是，Solr提供灵活的缓存管理功能，帮助服务器重用运算量大的数据扩容。具体来说，solr预先设置一些缓存来节省繁重的重新运算量，例如为查询过滤器缓存搜索结果。

        缓存能做的只有这些，如果需要处理更多的文档和复杂的查询，可以通过增加服务器来实现增容。solr伸缩性的两个最常见的纬度：查询吞吐量和文档索引量。查询吞吐量是指搜索引擎每秒支持的查询数量，为实现更高的查询吞吐量，可以通过增加索引副本让更多的服务器处理更多的查询请求。文档索引量，如果数量规模较大，那么单个实例会因为容纳太多文档而达到极限，查询性能也会受影响。为了处理更多文档，可以将索引拆分为很小的索引块，称之为索引分片，然后在索引分片中进行分布式搜索。

容错性

除了可伸缩性，还需要考虑一台或者多台服务器的故障处理能力。

        假设索引有4个分片，托管分片2的服务器断电了，这是，solr无法继续索引文档和提供查询服务，搜索引擎基本就宕机了，为避免这种情况，需要为每个分片添加副本。当分片2发生故障时，solr可以启用副本来索引和查询，但由于少了一个处理请求服务器，可能会降低速度。

功能概述

用户体验功能

solr主要由一下用户体验功能

• 分页与排序
• 分面
• 自动建议
• 拼写检查
• 搜索结果高亮
• 地理空间搜索

数据建模功能

• 结果分组/字段折叠
• 灵活的查询支持
• 连接
• 文档聚类
• 导入各种文档格式，如PDF和Word
• 从关系型数据库中导入数据
• 多语种支持

结果分组/字段折叠

        虽然Solr要求平面、非规范化的文档，但是我们可以根据文档的共同属性将多个文档归为一组，结果分组，也称为字段折叠，返回的结果时成组的，而不是单个文档。

灵活的查询支持

Solr提供了许多强大的查询功能，包括：

• 与（AND）、或（OR）、非（NOT）条件逻辑。
• 通配符匹配
• 支持日期和数字的区间查询
• 支持词项间隔的短语查询
• 模糊字符串匹配
• 正则表达式匹配
• 函数查询

连接

        SQL的连接使用两个及以上的表之间的共同属性（如外键）来抽取数据，从而创建关系，Solr的连接更像是SQL的子查询，不用连接其他文档的数据来创建文档。Solr的连接返回符合搜索条件的子文档，使用单一相应返回一条推文的所有转发，这是solr的一种连接应用。

文档聚类

        文档类聚根据代表每个文档的词项，将相似的文档分在一组。类聚有助于避免搜索结果中返回很多包含相同信息的文档。

导入各种文档格式，如PDF和Word

        某些情况下需要对PDF和Word等常见格式的大量文档进行搜索。对Solr来说这很容易做到，因为它集成了Apache的Tika项目，而Tika支持大多数流行的文档格式。

从关系型数据库中导入数据

        要用Solr搜索关系型数据库中的数据，通过配置Solr使用SQL查询生成文档。

多语种支持

        Solr与Lucene有很长的多语种处理历史。Solr内置语种检测，并提供多语种的特定文本分析解决方案。

Solr4的新功能

近实时搜索

        Solr的近实时搜索（Near Real-Time，NRT）功能实现了文档添加到索引后的几秒钟内，就能很快的被搜索到，借助近实时搜索，Solr可以搜索快速变化的内容源，如最新报道和社交网络。

原子更新与乐观并发

        原则更新功能允许客户端应用在已有文档上添加、更新、删除、和对字段增值，而且无需重新发送整个文档。

        solr使用乐观并发机制提防不兼容的更新。简单来说，solr使用特殊的_version_版本字段来确保文档的安全更新语义，对于两个用户同事更改同一个文档的情况，后提交更改的用户将会获得一个过时的版本字段，所以会更新失败。

实时GET动能

        Solr是一种NoSQL技术，Solr的实时GET功能是典型的NoSQL方式。无论文档是否提交到索引，你都可以使用唯一标识符检索最新版本。这与使用行键（row key）检索数据的Cassandra的键-值存储方式类似。

        在Solr 4 出现之前，除非文档提交到Lucene的索引，否则是检索不出来的。借助Solr 4 的实时GET动能，就不必非要提交后通过唯一ID检索文档了。在发送个Solr之后且提交之前，实时GET功能对更新已有文档非常有用。

使用事务日志实现写持续性

        当文档发送到Solr进行索引时，会被写入事务日志中，以防止服务器发生故障造成数据丢失。Solr的事务日志处在客户端应用与Lucene索引之间，也对实时GET请求起作用，无论是否已经提交给Lucene，都可以通过唯一标识符检索到文档。

        Solr的事务日志解除了更新可见性与更新持久性的绑定。这就是说，文档可以持久存储，但不出现在搜索结果中。事务日志可以控制提交的文档在搜索结果中出现的时机，避免在提交之前服务器出现故障时丢失数据。

使用ZooKeeper实现建议分片和复制

        在Solr4.x之前，需手动进行扩容。在Solr4.x之后，SolrCloud让扩容变得简单和自动化。在Solr中，Zookeeper负责指定分片代表与分片副本，并对服务请求可用的服务器机芯跟踪。SolrCloud与Zookeeper是绑定的，因此SolrCloud的启动无需做任何额外的配置和安装。