影响solr性能的一些因素（附使用经验）
原文：SolrPerformanceFactors
Solr本身的性能不错，但是在使用过程中，还是会遇到一些使用错误，或是没考虑到的地方；在出现瓶颈时，可以首先考虑哪些点呢？下面就来看一下Solr官方的总结，个人觉得总结的很好。SOLR+LUCENE的官网还是挺给力的 
对Schema设计的考虑
索引域的数量增长会很大程度的影响以下的内容：
批注：如果设置Norms，则会影响评分的标准，但会大大的增大索引文件的大小，如果对该字段没有需求，建议关掉
存储域
通过查询结果获取存储域的值是一个相当大的开销。如果文档的数据特别大，或者一些数据存储到了分布式的磁盘中（需要更多的IO来查询域）时，那么花费将会很大。这在存储大数据时很容易被考虑到，尤其是整个文档内容的存储。
考虑将大数据的存储放到solr之外。如果非要这么做，那么可以考虑使用压缩域，这将会用CPU的开销来换取IO的开销。
如果你并不需要使用所有的存储域，允许延迟加载(enableLazyFieldLoading)将会是很好的方式，由于是对那些压缩的字段。
批注：延迟加载在查询期间很有用，尤其是需要对某些字段作额外的处理时，它既能减少内存使用，又加速了程序的处理。另外，尽量减小索引的大小绝对不是坏事。
SOLR配置考虑
mergeFactor
mergeFactor大致决定了段的数量。mergeFactor的值告诉lucene有多少个段需要进行合并。它可以被认为是一个基本的数量系统。
举个例子，如果你设置mergeFactor为10，每1000个文档时会创建一个新的段到硬盘中。当第10个段被添加时，所有的10个段将被合并为1个段 (包含10000个文档)；当这样的10个文档被创建时，它们又会被合并为个包含100,000个文档的段，依次类推（当然也有上限）。这样，在任何时候，都不会有多余9个的段(相同索引大小情况下)存在。
该值在solrconfig.xml中的mainIndex设置(它会忽略indexDefaults)。
批注：关于合并的策略，请看我之前的博客：lucene内部的合并策略
mergeFactor Tradeoffs
高值的merge factor(比如25)：
cache中autoWarm数量的考虑
当一个新的searcher被打开时，它的cache可以从旧的searcher中重新加载或者自动预热(autowarmd)缓存的对象。autowarmCount是将被拷贝到新searcher中的对象的数量，你需要根据autowarm的时间来设置autowarmCount。如何使用autowarmCount，需要你根据时间和数量来设定。
批注：autoWarm即新的searcher会有多少数据被缓存，如果没有缓存，一些热点数据无疑会变得很慢。所以，合理的这是这个值，能大大加快查询的效率。
缓存命中率
在Solr的admin中监控缓存的统计。增加缓存的大小通常是提高性能的最好方法，尤其是你对一个指定的缓存类型作逐出操作时。请关注filterCache，它也被用来作solr的facetting。
批注：一个典型的场景是范围查询，类似fl=price:[100 TO 200]这样的情况，将数据该范围存储起来时，对其他的一些查询都可以复用这个缓存的数据，很高效。
对排序的域作明确的预热
如果你的工作大多基于排序的方式，那么你最好在“newSearcher”和“firstSearcher”时间监听器中添加明确的预热查询规则，这样FiledCache可以在用户的查询被执行前就将数据加载。
优化的考虑
你可能想在任何时候都可以优化你的索引。比如你创建索引后，就没有修改过它。
如果你的索引收到了一串需要更新的流，那么请考虑以下的因素：
JVM内存的分配
针对这个错误的最简单方法，在JVM并没有完全使用你的物理内存时，考虑加大JVM的内存容量：
