solr优化深刻学习

Scaling Solr（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/首页