编者按：在TechTarget数据库之前的报道中曾经介绍过（参考链接：2013年2月数据库流行度排行榜），Apache Solr是一个基于Lucene的高性能全文搜索服务器。伴随大数据概念的火热，Solr也越来越多地受到了关注。在本文中，Dzone作者Nicolas Frankel站在初学者的角度，对Solr进行了详细的介绍，希望能够对您有所帮助。

　　近期对搜索引擎的相关技术进行了研究，并特别关注了Solr的一些技术信息。下面，笔者将谈谈到目前为止对Apache Solr的一些理解。

　　为什么选择Solr？

　　由于以下两方面原因，在大型SQL数据库中执行超快速的检索比较困难。第一个原因在于SQL数据库更注重减少辐射率而不是性能。基本上，你需要在SELECT语句中使用JOIN。第二个原因则涉及到文件中数据的本质：文件中的数据基本上是非结构化的明文，这样就使得在SELECT中需要加入LIKE。而JOIN和LIKE的使用是以降低性能为代价的。因此，在现实生活中的搜索引擎采用这一方法并不可行。

　　许多搜索引擎开发者提出一种非常不同于SQL的数据处理方法，也就是倒排索引或反向索引（inverted index）。这类数据结构的特点包括：

• 键作为独立的表项
• 表中的值是与表项所匹配的文件列表

　　没有什么其他的特别之处，但是正是这种处理数据的方式使得在大容量的数据库中进行极速搜索成为可能。要注意，在此处“文件”具有广义上的含义，而最初的文件应该被视为一种结构化字段。

　　索引结构

　　虽然Solr属于非关系型数据库，但它并不是无模式（schemaless）的。模式配置被放在一个专门的schema.xml文件中：必须定义独立的字段以及它的类型。不同的文件类型可能在结构上存在差异并且几乎没有相同的字段。因此，应该给每种文件类型都利用其专属的模式设置其专属属性。

　　预定义的类型，比如字符串、整型和日期都可以使用。类型可以被声明为“可搜索”的（也就是“被索引”）或“可存储”（在查询中返回）。比如说，图书可以不仅包括书的内容，还要包括作者、出版商以及出版日期等等。

　　索引

　　在Solr中有两种可用于索引文件的可用接口：REST API和一种叫SolrJ的纯Java接口。

　　解析文件

　　为了建立倒排索引，文件需要被解析以便生成独立的词组条目。为了确保用户友好，你需要能够在不考虑以下内容的情况下进行搜索，如实例、连字符或者不相关的文字，也被称为停用词（可能包括英文中的“a”或者“the”）。采用一种可以匹配共享同一词根的方法或者是提供一种同义词词典也是同样重要的，这被称为填充，比如“fish”、“fishing”和“fisherman”。

　　Solr会给接收的文件提供一种令牌生成器的处理环节：环节中的每个独立的步骤都分别对基于增删改一个表项条目的行为负责。它们一般被称为过滤器。比如说，一类过滤器被用来删除停止停用词，一类过滤器用来将词组变为小写形式，一类过滤用来增添同义词组。

　　查询

　　查询也可以由许多条目组成。这些条目由二进制操作符组成并且独立的条目可以被提升。

　　通过类似于解析文件的方式，可以将查询解析成令牌。当然，有些过滤器会在这个过程中发挥作用，比如小写过滤器，而另外的一些过滤器则不能起到显著效果，比如同义词过滤器。

　　解析过的查询内容将采用集合理论与索引条目进行比对来产生匹配的结果。

　　查询结果

　　搜索的结果将在排序后分页呈现给用户，因此，那些与用户输入的查询条件越相符的文件将会出现在页面的最顶端。为了提供最优的用户体验，将采用一种在准确性和全面性之间的折中方案。

• 准确性——只返回最相关的结果
• 全面性——返回所有相关的结果

　　搜索结果可以根据一个或多个字段进行分类。根据字段类型进行结果的分类，也可以自定义分类方式：比如，对于图书的查询结果，可以根据在整个索引中图书的数量，按照作者姓名或者姓名的首字母分类。

    参考链接

    Solr主页：http://lucene.apache.org/solr/

    Solr维基百科：https://wiki.apache.org/solr/

    Solr 4.0.1指南：http://java.dzone.com/articles/solr-overview-beginner%E2%80%99s-point

    Solr中文资料：http://www.solr.cc/blog/