Scaling Solr（Solr的扩展）

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 很简单，在 ./examples/cores/mbreleases/solrconfig.xml 中就有示例配置 :

<requestHandler name="/replication" class="solr.ReplicationHandler" >

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

<str name="replicateAfter">startup</str>

<str name="replicateAfter">commit</str>

<str name="confFiles">stopwords.txt</str>

</lst>

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

<str name="masterUrl">http://localhost:8983/solr/replication</str>

<str name="pollInterval">00:00:60</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 状况。

 分发搜索请求到不同的 Slave 上

由于使用了多个 Slave ，所以我们没有一个固定的请求 URl 给客户的，因此，我们需要使用负载均衡，这里使用了 HAProxy 。

在 master 机器上，配置 /etc/haproxy/haproxy.cfg ，将你的 salve 机器的 url 放入：

listen solr-balancer 0.0.0.0:80

balance roundrobin

option forwardfor

server slave1 ec2-174-129-87-5.compute-1.amazonaws.com:8983

weight 1 maxconn 512 check

server slave2 ec2-67-202-15-128.compute-1.amazonaws.com:8983

weight 1 maxconn 512 check

solr-balancer 处理器将会监听 80 端口，并将根据权重将请求重定向到每个 Slave 机器，运行

>> service haproxy start

来启动 HAProxy 。

当然， SolrJ 也提供了 API 来进行负载均衡， LBHttpSolrServer 需要客户端知道所有 slave 机器的地址，并且它没有 HAProxy 这样的强健，因为它在架构上实现得很简略。可以参考：

http://wiki.apache.org/solr/LBHttpSolrServer

索引分片 (Sharding indexes)

Sharding 是一种当你的数据太多时很普遍的对单台数据库进行扩展的策略。在 Solr 中， sharding 有两种策略，一是将一个单一的 Solr core 分成多个 Solr 服务器，二是将单核的 Solr 变成多核的。 Solr 具备将单一的查询请求分发到多个 Solr shards 上，并聚集结果到一个单一的 result 里返回调用者。

当你的查询在单台服务器上执行太慢时你就需要组合多台 solr 服务器的能力来共同完成一个查询。如果你的查询已经足够快了，而你只是想扩展以为更多用户服务，那么建议你使用全索引而使采用 replication 的方法。

使用 Sharding 并不是一个完全透明的操作。关键的约束就是当索引一个 document ，你需要决定它应当在哪个 Shards 上。 Solr 对于分布式索引并没有相关的逻辑支持。那么当你搜索的时候你需要加上 shards 参数到 url ，以确定需要到哪些 shards 上收集结果。这意味着客户端需要知道 Solr 的架构。另外，每个 document 需要一个唯一的 id ，因为你是基于行将其拆分的，需要一个 id 来区分彼此。

 

分发 documents 到 shards

 

一种比较好的办法是对 id 进行 hash ，在模分片的大小来决定应当分发到哪个 shards 上：

SHARDS = ['http://ec2-174-129-178-110

.compute-1.amazonaws.com:8983/solr/mbreleases',

'http://ec2-75-101-213-59

.compute-1.amazonaws.com:8983/solr/mbreleases']

unique_id = document[:id]

if unique_id.hash % SHARDS.size == local_thread_id

# index to shard

end

这样，在你的 shards 不变化的情况下，你的 document 将会很好的找到它的 shards 。

 

跨多个 shards 搜索 (Searching across shards)

 

这个功能是已经配置在 query request handler 里面的。因此你无需做额外的配置，如果你想在两个 shards 上面进行查询，那么你只需要在 url 跟相关的参数即可：

>> http://[SHARD_1]:8983/solr/select?shards=ec2-174-129-178-110.

compute-1.amazonaws.com:8983/solr/mbreleases,ec2-75-101-213-59.compute-

1.amazonaws.com:8983/solr/mbreleases&indent=true&q=r_a_name:Joplin

注意 shards 后的参数不能跟 http 这样的传输协议，并且你可以跟尽量多的 shards ，只要你不超过 GET URL 的最大字符数 4000.

 

在使用 Shards 的时候，请务必注意以下内容：

l  Shards 仅仅支持以下组件 (Component):Query,faceting,Hignlighting,Stats 和 Debug

l  每个 document 必须有一个唯一的 id 。 Solr 是根据这个来合并搜索结果 document 的。

l  如果多个 shards 返回了相同 id 的 document ，那么第一个会被选中，而余下的被忽略。

联合使用 Replication 和 Shards(Scale Deep)

 

如果你使用了前面的方法，仍然发现性能无法满足要求，那么是到了将两个联合起来组成更高层次的架构来达到你的需要的时候了。

 

你需要使用同样的方法配置一组 Master ，这样最终你将有一棵树一样的 Masters 和 Slaves 。你甚至可以有一个专用的 Solr 服务器，它没有索引，只负责将查询分发的 shards 上，并在最后合并结果返回用户。

数据的更新将通过在 Master 机器上更新并 replication 到 slave 机器上实现。前端需要相关的负载均衡支持，但是这样一来， Solr 将能够处理极大的数据。

关于 Solr 的下一步 scaling ，在 Solr 的邮件列表里面已经讨论了很多次，一些调查研究显示， Hadoop 能够提供强健可靠的文件系统。另一个有趣的项目是 ZooKeeper ，它将能对分布式系统进行集中式的管理，对于将 ZooKeeper 集成进来已经有不少努力。

 

 

 

参考文件 ：

• Solr 1.4 Enterprise Search Server.pdf
• http://wiki.apache.org/solr/首页