使用 Apache Solr 实现更加灵巧的搜索，第 2 部分: 用于企业的 Solr

youdial

简介： 在本部分中，Lucene Java™ 的提交人 Grant Ingersoll 通过对用于企业的特性（包括管理界面、高级配置选项）以及与性能相关的特性（比如缓存、复制和日志记录）的探究，完成了对 Solr 的介绍。
　　在本系列的 第 1 部分，我为您介绍了 Apache Solr，一种基于 HTTP 的开源搜索服务器，它可以很容易地与多种 Web 应用程序集成。我展示了 Solr 最基本的功能，包括索引、搜索和浏览，介绍了 Solr 模式并解释了它在配置 Solr 功能方面的作用。在本部分中，我将通过列举 Solr 作为大型生产环境中理想的解决方案时所具备的特性来完成对 Solr 的介绍。涵盖的主题包括管理、缓存、复制和可扩展性。
　　请参阅 第 1 部分 来获得安装和设置 Solr 的指导。
　　配置和管理
　　本部分介绍了可用于监视和控制 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 的最大条目数，进而截断该文档。如果文档可能会很大，就需要增加这个数值。然而，若将这个值设置得过高会导致内存不足错误。unlockOnStartupunlockOnStartup 告知 Solr 忽略在多线程环境中用来保护索引的锁定机制。在某些情况下，索引可能会由于不正确的关机或其他错误而一直处于锁定，这就妨碍了添加和更新。将其设置为true 可以禁用启动锁定，进而允许进行添加和更新。　　查询处理配置
　　在  部分，有一些与 缓存 无关的特性，这一点您需要知道。首先， 标记定义了可组合在一起形成一个查询的子句数量的上限。对于大多数应用程序而言，默认的 1024 就应该已经足够；然而，如果应用程序大量使用了通配符或范围查询，增加这个限值将能避免当值超出时，抛出 TooManyClausesException。

通配符和范围查询

通配符和范围查询是可自动扩展以包括所有可能匹配查询条件的条目的 Lucene 查询。通配符查询允许使用 * 和 ?通配符运算符，而范围查询则要求匹配文档必须要在指定的范围之内。例如，若查找 b*，可能导致潜在的数千个不同项都组合进这个查询，进而会导致TooManyClausesException。　　接下来，若应用程序预期只会检索 Document 上少数几个 Field，那么可以将  属性设置为 true。懒散加载的一个常见场景大都发生在应用程序返回和显示一系列搜索结果的时候，用户常常会单击其中的一个来查看存储在此索引中的原始文档。初始的显示常常只需要显示很短的一段信息。若考虑到检索大型 Document 的代价，除非必需，否则就应该避免加载整个文档。
　　最后， 部分负责定义与在 Solr 中发生的事件相关的几个选项。首先，作为一种介绍的方式，Solr（实际上是 Lucene）使用称为Searcher 的 Java 类来处理 Query 实例。Searcher 将索引内容相关的数据加载到内存中。根据索引、CPU 以及可用内存的大小，这个过程可能需要较长的一段时间。要改进这一设计和显著提高性能，Solr 引入了一种 &#8220;温暖&#8221; 策略，即把这些新的 Searcher 联机以便为现场用户提供查询服务之前，先对它们进行 &#8220;热身&#8221;。 部分中的 选项定义 newSearcher 和 firstSearcher 事件，您可以使用这些事件来指定实例化新搜索程序或第一个搜索程序时应该执行哪些查询。如果应用程序期望请求某些特定的查询，那么在创建新搜索程序或第一个搜索程序时就应该反注释这些部分并执行适当的查询。
　　solrconfig.xml 文件的剩余部分，除  之外，涵盖了与 缓存、复制 和 扩展或定制 Solr 有关的项目。admin 部分让您可以定制管理界面。有关配置 admin 节的更多信息，请参看 Solr Wiki 和 solrconfig.xml 文件中的注释。

回页首
　　调试此分析过程
　　经常地，当创建搜索实现时，您都会输入一个应该匹配特定文档的搜索，但它不会出现在结果中。在大多数情况下，故障都是由如下两个因素之一引起的：

• 查询分析和文档分析不匹配（虽然不推荐，但对文档的分析可能会与对查询的分析不同）。
  
• Analyzer 正在修改不同于预期的一个或多个条目。
  

　　可以使用位于 http://localhost:8080/solr/admin/analysis.jsp 的 Solr 分析管理功能来深入调查这两个问题。Analysis 页可接受用于查询和文档的文本片段以及能确定文本该如何分析并返回正被修改的文本的逐步结果的 Field 名称。图 1 显示了分析句子 &#8220;The Carolina Hurricanes are the reigning Stanley Cup champions, at least for a few more weeks&#8221; 以及相关的查询 &#8220;Stanley Cup champions&#8221; 的部分结果，正如为示例应用程序 schema.xml 中指定的 content Field 分析的那样：

图 1. 对分析进行调试

　　分析屏幕显示了每个条件在被上述表结果 Tokenizer 或 TokenFilter 处理后的结果。比如，StopFilterFactory 会删除字 The、are和 the。EnglishPorterFilterFactory 会将字 champions 提取为 champion，将 Hurricanes 提取为 hurrican。紫色的醒目显示表明在特定文档中查询条件在何处有匹配。

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

表 3. Solr 缓存类型
缓存标记名描述能否自热？filterCache通过存储一个匹配给定查询的文档 id 的无序集，过滤器让 Solr 能够有效提高查询的性能。缓存这些过滤器意味着对 Solr 的重复调用可以导致结果集的快速查找。更常见的场景是缓存一个过滤器，然后再发起后续的精炼查询，这种查询能使用过滤器来限制要搜索的文档数。可以queryResultCache为查询、排序条件和所请求文档的数量缓存文档 id 的有序 集合。可以documentCache缓存 Lucene Document，使用内部 Lucene 文档 id（以便不与 Solr 惟一 id 相混淆）。由于 Lucene 的内部Document id 可以因索引操作而更改，这种缓存不能自热。不可以Named caches命名缓存是用户定义的缓存，可被 Solr 定制插件 所使用。可以，如果实现了org.apache.solr.search.CacheRegenerator的话。　　每个缓存声明都接受最多四个属性：

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

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

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

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

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

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

　　请求处理程序是由请求中的 qt 参数指定的。Solr servlet 使用参数值来查找给定的请求处理程序并将输入用于请求处理程序的处理。请求处理程序的声明和命名通过 solrconfig.xml 中的  标记指定。要添加其他的内容，只需实现定制的SolrRequestHandler 线程安全的实例即可，将其添加到 上述 定义好的 Solr，并将其包括到 如前所述 的类路径中，之后就可以通过HTTP GET 或 POST 方法开始向其发送请求了。
　　响应处理
　　与请求处理类似，也可以定制响应输出。必须要支持老式的搜索输出或必须要使用二进制或加密输出格式的应用程序可以通过实现QueryResponseWriter 来输出所需的格式。 然而，在添加您自己的 QueryResponseWriter 之前，需要先深入研究一下 Solr 所自带的实现，如表 4 所示：

表 4. Solr 的查询响应书写器
查询响应书写器描述XMLResponseWriter这个最为常用的响应格式以 XML 格式输出结果，如 第 1 部分 的博客应用程序所示。XSLTResponseWriterXSLTResponseWriter 将 XMLResponseWriter 的输出转换成指定的 XSLT 格式。请求中的 tr参数指定了要使用的 XSLT 转换的名称。指定的转换必须存在于 Solr Home 的 conf/xslt 目录。有关 XSLT Response Writer 的更多内容，请参见 参考资料。JSONResponseWriter用 JavaScript Object Notation (JSON) 格式输出结果。JSON 是一种简单、人类可读的数据转换格式，而且非常易于机器解析。RubyResponseWriterRubyResponseWriter 是对 JSON 格式的扩展以便在 Ruby 中安全地使用结果。若有兴趣将 Ruby 和 Solr 结合使用，可以参考 参考资料 中给出的到 acts_as_solr 和 Flare 的链接。PythonResponseWriter对 JSON 输出格式的扩展以便在 Python eval 方法中安全地使用。　　QueryResponseWriter 通过  标记及其附属属性被添加至 Solr 的 solrconfig.xml 文件。响应的类型通过 wt 参数在请求中指定。默认值是 &#8220;标准&#8221;，即在 solrconfig.xml 中设定为 XMLResponseWriter。最后要强调的是，QueryResponseWriter 的实例必须提供用来创建响应的 write() 和 getContentType() 方法的线程安全的实现。
　　Analyzer、Tokenizer、TokenFilter 和 FieldType
　　借助新的 Analyzer、Tokenizer、TokenFilter 可以定制 Solr 的索引输出以提供新的分析功能。自身需要 Tokenizer 或 TokenFilter的应用程序必须实现其自身的 TokenizerFactory 和 TokenFilterFactory，这两者使用  或  标记（作为 标记的一部分）在 schema.xml 中声明。如果您从之前的应用程序中已经获得了一个 Analyzer，那么就可以在 标记的 class 属性中声明它并进行使用。您无需创建新的 Analyzer，除非是想要在其他 Lucene 应用程序中使用这些分析器 &#8212;&#8212; 在 schema.xml 中使用  标记声明 Analyzer 真是容易呀！
　　如果应用程序有特定的数据需求，您可能需要添加一个 FieldType 来处理数据。比如，可以添加一个 FieldType 来处理来自旧的应用程序的二进制字段，在 Solr 中应该可以搜索到这个应用程序。只需使用  声明将 FieldType 添加到 schema.xml 并确保它在类路径中可用。

回页首
　　Solr 前景光明
　　构建于 Lucene 的速度和强大功能之上，Solr 本身就证明了它完全可以成为企业级的搜索解决方案。它吸引了大量活跃的社区使用者，这些使用者已经将它用到了各种大型的企业环境。Solr 也获得了开发人员的衷心支持，他们还一直在寻找提高它的途径。
　　在这个包含两部分的文章，您了解了 Solr，包括它开箱即用的索引和搜索功能以及用来配置其功能的 XML 模式。另外，您还浏览了让 Solr 得以成为企业架构的理想选择的配置和管理特性。最后，您还获悉了采用 Solr 时的性能考虑以及可用来扩展它的架构。有关 Solr 的更多信息，请参阅 参考资料 中的文档。