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 脚本，并且运行得更快。
Solr 的详细介绍：请点这里
Solr 的下载地址：请点这里
相关阅读：