Solr Replication

个人博客：http://demi-panda.com

Solr 的扩展 (Scaling)

当你的索引数量越来越大，你会发现你的搜索响应时间变得更慢，索引新内容的时间也会越来越长，那么，到了做出一些改变的时候了，幸运的是， solr 很好的考虑到了这些情况，你只需要改变你的配置就可以了。

以下将从三个方面讲述 solr 的 scaling ：

l  调优某个 Solr 服务器 (Scale High)

通过缓存和内存管理优化某个单实例的 Solr 。将 Solr 部署到一个拥有快速的 CPU 和硬件的专用服务器，通过调优，最大化的将单个服务器的性能达到最高。

l  使用多 Solr 服务器 (Scale Wide)

使用多 Solr 服务器。如果你的 avgTimePerRequest 参数在你可接受的范围内（数据量一般在数百万），那么可以通过配置将你的 master 上的索引完整地复制到 slave 机器上；如果你的查询已经很慢，那么使用分片来讲你的单个查询的负载分发到多个 Solr 服务器上。

l  使用复制 (replication) 和分片 (sharding)(Scale Deep)

当你的数据量足够大，你需要同时使用复制和分片，那么每个分片将对应一个 master 和若干 slave ，这将是一个最复杂的架构。

我们将会对三个性能参数进行优化：

l  TPS(Transaction Per Second) 每秒事务处理量，可以查看 http://localhost:8983/solr/mbtracks/admin/stats.jsp 或者查看 requesHandler 的 avgTimePerRequest 和 avgRequestsPerSecond 参数。

l  CPU Usage CPU 使用情况，在 Windows 下可以使用 PerfMon 获得 CPU 使用的相关信息，而在 Unix 类操作系统上使用 top 。

l  Memory Usage 内存使用情况，可以使用 PrefMon 、 top 和 jConsole 来查看。

接下来将会介绍对于 Solr 的 scaling 。

调优某个 Solr 服务器 (Scale High)

Solr 提供了一系列可选的配置来增强性能，具体怎么使用将取决于你的应用程序。下面将对其中最常用的进行介绍

JVM 配置

Solr 运行在 JVM 之上，因此对 JVM 的调优将直接影响 Solr 的性能，不过对于 JVM 参数的改变要慎重，因为，很可能一丁点改变会引发很大的问题。

可以在启动的时候指定 JVM 参数：

java -Xms512M -Xmx1024M -server -jar start.jar

你的 Xmx 参数应当为你的操作系统以及运行在服务器上的其他进程预留足够的内存，比如你有 4G 的索引文件，你可以指定 6G 的 RAM （并指定较大的缓存）那么你就能取得比较好的性能。

另外，在可能的情况下，尽量使用版本较高的 Java 版本，因为新版本的 Java 虚拟机性能越来越好。

HTTP 缓存

因为 Solr 的许多操作都是基于 HTTP 的，因此 Solr 对 HTTP 缓存有很大的支持。如果你想使用 HTTP 缓存，那么你需要在 solrconfig.xml 中做如下配置：

<httpCaching lastModifiedFrom="openTime" etagSeed="Solr" never304="false">

<cacheControl>max-age=43200, must-revalidate</cacheControl>

</httpCaching>

默认情况下， Solr 是不使用 304 not modified 状态给客户端的，而是始终返回 200 OK ，上面的配置指明 max-age 是 43200 秒。下面是例子：

      >> curl -v http://localhost:8983/solr/mbartists/select/?q=Smashing+Pumpkins

< HTTP/1.1 200 OK

< Cache-Control: max-age=43200

< Expires: Thu, 11 Jun 2009 15:02:00 GMT

< Last-Modified: Thu, 11 Jun 2009 02:55:39 GMT

< ETag: "YWFkZWIyNjVmODgwMDAwMFNvbHI="

< Content-Type: text/xml; charset=utf-8

< Content-Length: 1488

< Server: Jetty(6.1.3)

很显然， HTTP 缓存配置生效了，那么，我们也可以指定 If-modified-since 参数，这样服务器会比较，如果在最新更改时间之后，那么服务器会返回最新数据。

           >>curl -v -z "Thu, 11 Jun 2009 02:55:40 GMT"

  http://localhost:8983/solr/mbartists/select/?q=Smashing+Pumpkins

* About to connect() to localhost port 8983 (#0)

* Trying ::1... connected

* Connected to localhost (::1) port 8983 (#0)

> GET /solr/mbartists/select/?q=Smashing+Pumpkins HTTP/1.1

> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3

OpenSSL/0.9.7l zlib/1.2.3

> Host: localhost:8983

> Accept: */*

> If-Modified-Since: Thu, 11 Jun 2009 02:55:40 GMT

> 

< HTTP/1.1 304 Not Modified

< Cache-Control: max-age=43200

< Expires: Thu, 11 Jun 2009 15:13:43 GMT

< Last-Modified: Thu, 11 Jun 2009 02:55:39 GMT

< ETag: "YWFkZWIyNjVmODgwMDAwMFNvbHI="

< Server: Jetty(6.1.3)

Entity tag 也是一种新的方法来进行鉴别，它比使用 last modified date 更加的强健和灵活。 ETag 是一个字符串。在 Solr 的索引更新以后，当前的 ETag 会随之改变。

Solr 缓存

Solr 为缓存使用了 LRU 算法，缓存存放在内存中，缓存和 Index Searcher 关联在一起，维持了一个数据的快照 (a snapshot view of data). 在一个 commit 之后，新的 index searcher 打开，并会自动预热 (auto-warmed). 自动预热指的是之前搜索的缓存会被拷贝到新的 searcher 。接着，预先在 solrconfig.xml 中定义的 searcher 会运行。为那些需要排序的字段 (field) 加入一些典型的 query 到 newSearcher 和 firstSearcher ，这样，新的 searcher 就能为新的搜索提供服务了。

Solr1.4 使用了 FastLRUCache, 它比 LRUCache 要更快，因为它无需单独的线程来移除无用的 items 。

通过 Solr 的 statistics 页面，你可以看到你的缓存有多大，并且可以根据实际情况对缓存的大小进行调整以适应最新的情况。

设计更好的 Schema

你需要考虑是否 indexed ，是否 stored 等等，这些将决定于你应用程序的具体情况。如果你存储很大的文本到你的索引中，你最好使用 field 的 compressed 选项配置对其进行压缩。如果你不是总需要读取所有的 fields ，那么在 solrconfig.xml 中配置使用 field 延迟加载： <enableLazyFieldLoading>true</enableLazyFieldLoading>

这会起到很好的作用。

注意：如果你使用了 compressed ，那么你可能需要使用 field 延迟加载，同时还要降低解压缩的代价。另外降低文本分析的数量将有效提高性能，因为文本分析会消耗大量的 CPU 时间，并且使得你的索引大幅增大。

索引策略

一种加速索引的方式是分批索引，这样将会显著加速性能。但是，随着你的 document 增加，性能还是会开始下降。根据经验，对于大的 document ，每批索引 10 个，而对于小的 document ，每批索引 100 个，并分批提交。

另外，使用多线程进行索引将会再次提高性能。

取消 document 唯一性检查 (Disable unique document check)

默认情况下，索引的时候 Solr 会检查主键是否有重复的，以避免不同的 document 使用相同的主键。如果你确认你的 document 不会有重复的主键，将参数 allowDups=true 加到 url 上可以取消检查，对于 scv 文档，使用 overwrite=false 。

Commit/optimize 因子 ( factors)

对于大的索引以及频繁的更新，使用较大的 mergeFactor ，它决定了 Lucene 会在 segments 数量达到多少时将它们合并 (merge) 。

优化 Faceting( 分组查询 ) 的性能

使用 Term Vectors

Term Vectors 是某 field 经文本分析之后的一系列 terms 。它一般包括了 term 的频率， document 的频率和在文本中的数值偏移量，启用它有可能会增强 MoreLikeThis 查询和 Hignlight 查询的性能。

但是启用 tern vectors 会增加索引的大小，并且可能根本不会在 MoreLikeThis 和 Highlight 查询结果中。

提升 phrase 查询的性能

在大索引的查询中， phrase 查询的性能会很慢，因为，某个 phrase 可能会出现在很多的 document 中，一种解决办法是使用 filter 过滤掉诸如“ the ”这样没有意义的词语。但是这样会使得搜索出现歧义，解决方案是使用 Shingling ，它使用类似 n-gram 的方法将搜索句子切分，如“ The quick brown fox jumped over the lazy dog ”将会变为 "the quick", "quick brown",

"brown fox", "fox jumped", "jumped over", "over the", "the lazy", "lazy dog". 粗糙的测试表明，这样至少可以提高 2-3 倍的性能。

使用多 Solr 服务器 (Scale wide)

当你对单台 Solr 服务器的调优仍然无法满足性能需求的时候，接下来你应该考虑拆分查询请求到不同的机器上，具备横向扩展 (Scale wide) 是可扩展系统的最基本的特点，因此， solr 也具备了该特点。

Script VS Java replication

在 Solr1.4 之前， replication 是通过使用 Unix 脚本进行的。一般来说，这种方案还算不错，但是可能有一些复杂了，需要编写 shell 脚本， cron jobs 和 resync daemon 。

从 1.4 开始， Solr 实现了基于 Java 的复制策略，不用再编写复杂的 shell 脚本，并且运行得更快。

Replication 的配置在 solrconfig.xml 之中，并且配置文件本身可以在 master 和 slave 服务器之间被复制。 Replication 目前已经支持 Unix 和 Windows 系统并且已经集成到了 Admin interface 之中。 Admin interface 目前可以控制复制 --- 例如，强制开始 replication 或者终止失效（ stalled ）的复制。复制是通过 ReplicationHandler 提供的 REST API 进行的。

开始体验多 Solr 服务器

如果你在多个 Solr 服务器之间使用了同一个 solrconfig.xml 文件，那么你需要在启动的时候指定以下几个参数：

l  -Dslave=disabled ：指定当前 solr 服务器是 Master 。 Master 将负责推送索引文件到所有 slave 服务器。你将会存储 document 到 master 上，而在 slave 服务器上进行查询。

l  -Dmaster=disabled ：指定当前 solr 服务器是 Slave 。 Slave 要么定期轮询 Master 服务器来更新索引，要么手动的通过 Admin interface 触发更新操作。一组 slave 将会被负载均衡（可能是 HAProxy 之类）器管理着来对外提供搜索。

如果你想在同一机器上运行多个 Solr 服务器，那么你需要通过 -Djetty.port=8984 指定不同的端口，并且通过 -Dsolr.data.dir=./solr/data8984 指定不同的 data 目录。

配置 Replication

配置 replication 很简单，在 ./conf/solrconfig.xml 中就有示例配置 :

     <requestHandler name="/replication" class="solr.ReplicationHandler" >
       <lst name="master">
         <str name="enable">${master.enable:false}</str>
         <str name="replicateAfter">commit</str>
         <str name="replicateAfter">startup</str>
         <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
       </lst>
       <lst name="slave">
         <str name="enable">${slave.enable:false}</str>
         <str name="masterUrl">http://192.168.3.227:6091/solr-web-geo/dealgeo/replication</str>
         <str name="pollInterval">00:00:60</str>
         <str name="compression">internal</str>
         <str name="httpConnTimeout">5000</str>
         <str name="httpReadTimeout">10000</str>
       </lst>
     </requestHandler>

注意 ${} 将能够运行期进行配置，它将通过 -Dmaster=disabled 或 -Dslave=disabled 决定这里的参数是 master 还是 slave 。 Master 机器已经配置了在每次 commit 之后进行 replication 。并且可通过 confFiles 属性以指定复制配置文件。复制配置文件非常有用，因为你可以在运行期修改配置而无需重新部署。在 master 上修改配置文件， replication 到 slave 后， Slave 将会知道配置文件被修改了，并 reload core 。

可以参考 http://wiki.apache.org/solr/SolrReplication

Replication 的实现

Master 是感知不到 Slave 的存在的， Slave 会周期性的轮询 Master 来查看当前的索引版本。如果 Slave 发现有新的版本，那么 Slave 启动复制进程。步骤如下：

1.         Slave 发出一个 filelist 命令来收集文件列表。这个命令将返回一系列元数据（ size ， lastmodified ， alias 等等）

2.         Slave 查看它本地是否有这些文件，然后它会开始下载缺失的文件 ( 使用命令 filecontent) 。如果连接失败，则下载终止。它将重试 5 次，如果仍然失败则放弃。

3.         文件被下载到了一个临时目录。因此，下载中途出错不会影响到 slave 。

4.         一个 commit 命令被 ReplicationHandler 执行，然后新的索引被加载进来

跨多个 Slave 的分布式搜索

 

索引一些文件到 Master 上

你可以用 SSH 运行两个 session ，一个开启 Solr 服务，另一个索引一些文件：

>> curl http://localhost:8983/solr/mbreleases/update/csv -F f.r_

attributes.split=true -F f.r_event_country.split=true -F f.r_event_

date.split=true -F f.r_attributes.separator=' ' -F f.r_event_country.

separator=' ' -F f.r_event_date.separator=' ' -F commit=true -F stream.

file=/root/examples/9/mb_releases.csv

上面的命令索引了一个 csv 文件。你可以通过 Admin interface 监控这个操作。

配置 Slave

 

之前已经索引了文件，并且通过复制已经到了 slave 上，接下来，需要使用 SSH 到 slave 机器上，配置 masterUrl 如下：

<lst name="${slave:slave}">

<str name="masterUrl">

http://ec2-67-202-19-216.compute-1.amazonaws.com:8983/solr/mbreleases/replication

</str>

<str name="pollInterval">00:00:60</str>

</lst>

你可以到 Admin interface 上查看当前的 replication 状况。