solr详解1.

Solr重要文件的简单说明
solrconfig.xml是solr的基础文件，里面配置了各种web请求处理器、请求响应处理器、日志、缓存等。
schema.xml配置映射了各种数据类型的索引方案。分词器的配置、索引文档中包含的字段也在此配置。

Solr以web形式的发布，对外提供了添加、修改、删除索引和检索的web服务。并且提供多种格式的信息传输，
如xml、json、cvs等，默认提供的是xml格式。

xml代码
<!—field 标签配置了字段的解析类型、是否需要索引、是否需要存储等，详细信息 to see  solr wiki-- >

Xml代码   

1. <field name="id" type="integer" indexed="true" stored="true"/>    
2. <field name="time" type="date" indexed="true" stored="true"/>    
3. <field name="enabled" type="boolean" indexed="true" stored="true"/>    
4. <field name="content" type="text" indexed="true" stored="true"/>    

 

 

 

Xml代码   

1. <!- 字段all是一个虚拟的字段，代表所有的字段，在此表示：id，time，enabled，content   
2. <field name="all" type="text" indexed="true" stored="true" multiValued="true"/>    
3.   
4.   
5. <!—uniqueKey告诉solr id字段是文档的唯一标识 -->   
6. <uniqueKey>id</uniqueKey>    
7.   
8.   
9. <!—solrQueryParser 标签表示多条件检索时采用的策略。如：检索条件content：xxx time：xxx solr就会采取content：xxx OR time：xxx 这种形式-->   
10. <solrQueryParser defaultOperator="OR"/>   
11.   
12.   
13. <!—defaultSearchField标签表示如果没有明确检索那个字段，solr就会检索这个标签配置的字段 -->    
14. <defaultSearchField>all</defaultSearchField>    
15.   
16.   
17. <!—copyField标签表示将其他字段复制到目标字段，方面检索。如：将id、time、enabled、content 复制到all上面，  
18. 当不指定明确的检索字段，solr就会检索all字段，其实就是检索id、time、enabled、content -->    
19. <copyField source="id" dest="all"/>    
20. <copyField source="time" dest="all"/>    
21. <copyField source="enabled" dest="all"/>    
22. <copyField source="content" dest="all"/>  

 

 

solr web端
编写客户端程序访问solr web服务创建、修改、删除索引和搜索

Solr的查询语法（详细的配置信息 tosee Solr wiki）
参数
q 
描述
Solr 中用来搜索的查询。有关该语法的完整描述，分号和已索引且未进行断词的字段（下面会进行解释）的名称来包含排序信息。默认的排序是 score desc，指按记分降序排序。
示例
q=myField:Java AND otherField:developerWorks; date asc 
 此查询搜索指定的两个字段并根据一个日期字段对结果进行排序。

 

q.op
表示q 中 查询语句的 各条件的逻辑操作 AND(与) OR(或) 
q.op=AND

start
将初始偏移量指定到结果集中。可用于对结果进行分页。默认值为 0。
start=15 
 返回从第 15 个结果开始的结果

rows
返回文档的最大数目。默认值为 10。
rows=25
 

fq
提供一个可选的筛选器查询。查询结果被限制为仅搜索筛选器查询返回的结果。筛选过的查询由 Solr 进行缓存。它们对提高复杂查询的速度非常有用。
任何可以用 q 参数传递的有效查询，排序信息除外。

hl
当 hl=true 时，在查询响应中醒目显示片段。默认为 false。
hl=true

hl.fl
高亮field 
hl.fl=id,content

hl.simple.pre
高亮前面的格式
hl.simple.pre=<a>

hl.simple.post
高亮后面的格式
hl.simple.post=</a>

sort 
排序
sort =id asc

 

 Solr 是一种可供企业使用的、基于 Lucene 的搜索服务器，它支持层面搜索、命中醒目显示和多种输出格式。

索引操作
在 Solr 中，通过向部署在 servlet 容器中的 Solr Web 应用程序发送 HTTP 请求来启动索引和搜索。Solr 接受请求，确定要使用的适当 SolrRequestHandler，然后处理请求。通过 HTTP 以同样的方式返回响应。默认配置返回 Solr 的标准 XML 响应。您也可以配置 Solr 的备用响应格式。

索引就是接受输入并将它们传递给 Solr，从而在 HTTP Post XML 消息中进行索引的过程。您可以向 Solr 索引 servlet 传递四个不同的索引请求：
add/update 允许您向 Solr 添加文档或更新文档。直到提交后才能搜索到这些添加和更新。
commit 告诉 Solr，应该使上次提交以来所做的所有更改都可以搜索到。
optimize 重构 Lucene 的文件以改进搜索性能。索引完成后执行一下优化通常比较好。如果更新比较频繁，则应该在使用率较低的时候安排优化。一个索引无需优化也可以正常地运行。优化是一个耗时较多的过程。
delete 可以通过 id 或查询来指定。按 id 删除将删除具有指定 id 的文档；按查询删除将删除查询返回的所有文档。

 

层面浏览
最近，似乎所有流行的购物站点都添加了便利的条件列表，帮助用户根据制造商、价格和作者缩小搜索结果的范围。这些列表是层面浏览的结果，层面浏览是一种分类方式，用于对已经返回到有意义的、已证实存在的种类的结果进行分类。层面用于帮助用户缩小搜索结果的范围。

 

配置和管理
本部分介绍了可用于监视和控制 Solr 功能性的诸多选项，首先来看看 Solr 的 Administration Start Page，该页可在 http://localhost:8080/solr/admin/ 找到。一旦找到了起始页，在继续之前，请务必花些时间熟悉一下上面的各种菜单选项。在起始页中，根据这些选项所提供的信息的不同对它们进行了分组：
Solr 给出了有关这种活动模式（请参见 第 1 部分）、配置以及当前部署的统计数据的详细信息。 
App server 给出了容器的当前状态，包括 threading 信息以及所有 Java 系统属性的列表。 
Make a Query 提供了调试查询所需的快捷界面以及到功能更加全面的查询界面的链接。 
Assistance 提供了到外部资源的有用链接以便理解和解决使用 Solv 可能遇到的一些问题。

要使用 Solr 的配置选项，可以单击初始页上的 CONFIG 链接，这会显示当前的 solrconfig.xml 文件。您可以在 示例应用程序 的 dw-solr/solr/conf 目录找到该文件。现在，让我们先来看看与索引和查询处理有关的一些常见的配置选项，而与 缓存、复制 和 扩展 Solr 有关的配置选项则留到后面的章节再介绍。

 

 索引配置
mainIndex 标记段定义了控制 Solr 索引处理的低水平的 Lucene 因素。Lucene 基准发布（位于 Lucene 源代码的 contrib/benchmark 之下）包含了很多可用来对这些因素的更改效果进行基准测试的工具。此外，请参阅 参考资料 一节中的 “Solr 性能因素” 来了解与各种更改相关的性能权衡。表 1 概括了可控制 Solr 索引处理的各种因素：

表 1. 对性能因素进行索引
useCompoundFile 
通过将很多 Lucene 内部文件整合到单一一个文件来减少使用中的文件的数量。这可有助于减少 Solr 使用的文件句柄数目，代价是降低了性能。除非是应用程序用完了文件句柄，否则 false 的默认值应该就已经足够。  
mergeFactor 
决定低水平的 Lucene 段被合并的频率。较小的值（最小为 2）使用的内存较少但导致的索引时间也更慢。较大的值可使索引时间变快但会牺牲较多的内存。  
maxBufferedDocs 
在合并内存中文档和创建新段之前，定义所需索引的最小文档数。段 是用来存储索引信息的 Lucene 文件。较大的值可使索引时间变快但会牺牲较多的内存。 
maxMergeDocs 
控制可由 Solr 合并的 Document 的最大数。较小的值 (< 10,000) 最适合于具有大量更新的应用程序。 
maxFieldLength 
对于给定的 Document，控制可添加到 Field 的最大条目数，进而截断该文档。如果文档可能会很大，就需要增加这个数值。然而，若将这个值设置得过高会导致内存不足错误。 
unlockOnStartup 
unlockOnStartup 告知 Solr 忽略在多线程环境中用来保护索引的锁定机制。在某些情况下，索引可能会由于不正确的关机或其他错误而一直处于锁定，这就妨碍了添加和更新。将其设置为 true 可以禁用启动锁定，进而允许进行添加和更新。

查询处理配置
在 <query> 部分，有一些与 缓存 无关的特性，这一点您需要知道。首先，<maxBooleanClauses> 标记定义了可组合在一起形成一个查询的子句数量的上限。对于大多数应用程序而言，默认的 1024 就应该已经足够；然而，如果应用程序大量使用了通配符或范围查询，增加这个限值将能避免当值超出时，抛出 TooManyClausesException。

接下来，若应用程序预期只会检索 Document 上少数几个 Field，那么可以将 <enableLazyFieldLoading> 属性设置为 true。懒散加载的一个常见场景大都发生在应用程序返回和显示一系列搜索结果的时候，用户常常会单击其中的一个来查看存储在此索引中的原始文档。初始的显示常常只需要显示很短的一段信息。若考虑到检索大型 Document 的代价，除非必需，否则就应该避免加载整个文档。

最后，<query> 部分负责定义与在 Solr 中发生的事件相关的几个选项。首先，作为一种介绍的方式，Solr（实际上是 Lucene）使用称为 Searcher 的 Java 类来处理 Query 实例。Searcher 将索引内容相关的数据加载到内存中。根据索引、CPU 以及可用内存的大小，这个过程可能需要较长的一段时间。要改进这一设计和显著提高性能，Solr 引入了一种 “温暖” 策略，即把这些新的 Searcher 联机以便为现场用户提供查询服务之前，先对它们进行 “热身”。<query> 部分中的 <listener> 选项定义 newSearcher 和 firstSearcher 事件，您可以使用这些事件来指定实例化新搜索程序或第一个搜索程序时应该执行哪些查询。如果应用程序期望请求某些特定的查询，那么在创建新搜索程序或第一个搜索程序时就应该反注释这些部分并执行适当的查询。

 

solrconfig.xml 文件的剩余部分，除 <admin> 之外，涵盖了与 缓存、复制 和 扩展或定制 Solr 有关的项目。admin 部分让您可以定制管理界面。有关配置 admin 节的更多信息，请参看 Solr Wiki 和 solrconfig.xml 文件中的注释。

 

监视、记录和统计数据

 

Statistics
Statistics 管理页提供了与 Solr 性能相关的很多有用的统计数据。这些数据包括： 
关于何时加载索引以及索引中有多少文档的信息。 
关于用来服务查询的 SolrRequestHandler 的有用信息。 
涵盖索引过程的数据，包括添加、删除、提交等的数量。 
缓存实现和 hit/miss/eviction 信息

Info
有关正在运行的 Solr 的版本以及在当前实现中进行查询、更新和缓存所使用的类的详细信息。此外，还包括文件存于 Solr subversion 存储库的何处的信息以及对该文件功能的一个简要描述。

Distribution
显示与索引发布和复制有关的信息。更多信息，请参见 “发布和复制” 一节。

Ping
向服务器发出 ping 请求，包括在 solrconfig.xml 文件的 admin 部分定义的请求。

Logging
让您可以动态更改当前应用程序的日志记录等级。更改日志记录等级对于调试在执行过程中可能出现的问题非常有用

Java properties
显示当前系统正在使用的所有 Java 系统属性。Solr 支持通过命令行的系统属性替换。有关实现此特性的更多信息，请参见 solrconfig.xml 文件。

Thread dump
thread dump 选项显示了在 JVM 中运行的所有线程的堆栈跟踪信息。

 

智能缓存
智能缓存是让 Solr 得以成为引人瞩目的搜索服务器的一个关键性能特征。例如，Solr 在提供缓存服务之前可通过使用旧缓存中的信息来自热缓存，以便在服务于现有用户的同时改进性能。Solr 提供了四种不同的缓存类型，所有四种类型都可在 solrconfig.xml 的 <query> 部分中配置。表 3 根据在 solrconfig.xml 文件中所用的标记名列出了这些缓存类型：

filterCache
通过存储一个匹配给定查询的文档 id 的无序集，过滤器让 Solr 能够有效提高查询的性能。缓存这些过滤器意味着对 Solr 的重复调用可以导致结果集的快速查找。更常见的场景是缓存一个过滤器，然后再发起后续的精炼查询，这种查询能使用过滤器来限制要搜索的文档数。
可以智能

queryResultCache
为查询、排序条件和所请求文档的数量缓存文档 id 的有序 集合。
可以智能

documentCache
缓存 Lucene Document，使用内部 Lucene 文档 id（以便不与 Solr 惟一 id 相混淆）。由于 Lucene 的内部 Document id 可以因索引操作而更改，这种缓存不能自热。
不可以智能

Named caches
命名缓存是用户定义的缓存，可被 Solr 定制插件 所使用。
可以智能

每个缓存声明都接受最多四个属性：
class 是缓存实现的 Java 名。 
size 是最大的条目数。 
initialSize 是缓存的初始大小。 
autoWarmCount 是取自旧缓存以预热新缓存的条目数。如果条目很多，就意味着缓存的 hit 会更多，只不过需要花更长的预热时间。

而对于所有缓存模式而言，在设置缓存参数时，都有必要在内存、CPU 和磁盘访问之间进行均衡。统计信息管理页 对于分析缓存的 hit-to-miss 比例以及微调缓存大小的统计数据都非常有用。而且，并非所有应用程序都会从缓存受益。实际上，一些应用程序反而会由于需要将某个永远也用不到的条目存储在缓存中这一额外步骤而受到影响。

 

排除发布故障
虽然，我们已经竭尽全力地对索引更新的发布进行了优化，但还是有几个常见的场景会为 Solr 带来问题：

优化大型索引可能会非常耗时，而且应该在索引更新不是很频繁的情况下才进行。优化会导致多个 Lucene 索引文件合并成一个单一文件。这就意味者从服务器必须要复制整个索引。然而，这种方式的优化还是比在每个从服务器上进行优化要好很多。这些服务器可能与主服务器不同步，导致新副本再次被检索。

如果从主服务器中获取新快照的频率过高，则从服务器的性能可能会降低，这种降低源于使用 snappuller 复制更改的开销以及在安装新索引时的缓存预热。有关频繁的索引更新方面的性能均衡的详细信息，请参见 参考资料 中的 “Solr Performance Factors”。
 
最终，向从服务器添加、提交和获取更改的频繁程度完全取决于您自己的业务需求和硬件能力。仔细测试不同的场景将会帮助您定义何时需要创建快照以及何时需要从主服务器中获取这些快照。有关设置和执行 Solr 发布和复制的更多信息，请参看 参考资料 中的 “Solr Collection and Distribution” 文档。

定制 Solr
Solr 提供了几个插件点，您可以在这里添加定制功能来扩展或修改 Solr 处理。此外，由于 Solr 是开源的，所以如果需要不同的功能，您尽可以更改源代码。有两种方式可以向 Solr 添加插件：

打开 Solr WAR，在 WEB-INF/lib 目录下添加新的库，重新打包这些文件，然后将 WAR 文件部署到 servlet 容器。
将 JAR 放入 Solr Home lib 目录，然后启动 servlet 容器。这种方法使用了定制 ClassLoader 且有可能不适用于某些 servlet 容器。

请求处理
若现有的功能不能满足业务需求，Solr 允许应用程序实现其自身的请求处理功能。比如，您可能想要支持您自己的查询语言或想要将 Solr 与您的用户配置文件相集成来提供个性化的效果。SolrRequestHandler 接口定义了实现定制请求处理所需的方法。实际上，除了 第 1 部分 所使用的那些默认的 “标准” 请求处理程序之外，Solr 还定义了其他几个请求处理程序：

默认的 StandardRequestHandler 使用 Lucene Query Parser 语法处理查询，添加了排序和层面浏览。
DisMaxRequestHandler 被设计用来通过更为简单的语法来跨多个 Field 进行搜索。它也支持排序（使用与标准处理程序稍有不同的语法）和层面浏览。 
IndexInfoRequestHandler 可以检索有关索引的信息，比如索引中的文档数或 Field 数。

 

请求处理程序是由请求中的 qt 参数指定的。Solr servlet 使用参数值来查找给定的请求处理程序并将输入用于请求处理程序的处理。请求处理程序的声明和命名通过 solrconfig.xml 中的 <requestHandler> 标记指定。要添加其他的内容，只需实现定制的 SolrRequestHandler 线程安全的实例即可，将其添加到 上述 定义好的 Solr，并将其包括到 如前所述 的类路径中，之后就可以通过 HTTP GET 或 POST 方法开始向其发送请求了。

 

响应处理
与请求处理类似，也可以定制响应输出。必须要支持老式的搜索输出或必须要使用二进制或加密输出格式的应用程序可以通过实现 QueryResponseWriter 来输出所需的格式。然而，在添加您自己的 QueryResponseWriter 之前，需要先深入研究一下 Solr 所自带的实现，如表所示：
XMLResponseWriter
这个最为常用的响应格式以 XML 格式输出

XSLTResponseWriter
XSLTResponseWriter 将 XMLResponseWriter 的输出转换成指定的 XSLT 格式。请求中的 tr 参数指定了要使用的 XSLT 转换的名称。指定的转换必须存在于 Solr Home 的 conf/xslt 目录。有关 XSLT Response Writer 的更多内容，请参见 参考资料。

JSONResponseWriter
用 JavaScript Object Notation (JSON) 格式输出结果。JSON 是一种简单、人类可读的数据转换格式，而且非常易于机器解析。

RubyResponseWriter
RubyResponseWriter 是对 JSON 格式的扩展以便在 Ruby 中安全地使用结果。若有兴趣将 Ruby 和 Solr 结合使用，可以参考 参考资料 中给出的到 acts_as_solr 和 Flare 的链接。

PythonResponseWriter
对 JSON 输出格式的扩展以便在 Python eval 方法中安全地使用。

QueryResponseWriter 通过 <queryResponseWriter> 标记及其附属属性被添加至 Solr 的 solrconfig.xml 文件。响应的类型通过 wt 参数在请求中指定。默认值是 “标准”，即在 solrconfig.xml 中设定为 XMLResponseWriter。最后要强调的是，QueryResponseWriter 的实例必须提供用来创建响应的 write() 和 getContentType() 方法的线程安全的实现。