结合自己的项目谈谈solr优化

index优化

先理解下索引段的概念

mergeFactor（索引段合并频数，当大小相当的段数达到这个数的时候开始合并）

比如mergeFactor=3，开始来的段大小为10M（第一层），当凑够3个10M的时候，0.cfs, 1.cfs, 2.cfs则合并成一个新的段3.cfs，大小为30M（第二层），然后再来4.cfs, 5.cfs, 6.cfs，合并成7.cfs，大小为30M，然后再来8.cfs,9.cfs,a.cfs合并成b.cfs, 大小为30M，这时候又凑够了3个30M的，合并成90M的c.cfs（第三层），然后又来d.cfs, e.cfs, f.cfs合并成10.cfs，大小为30M，然后11.cfs大小为10M，这时候硬盘上的段为：c.cfs(90M)10.cfs(30M),11.cfs(10M)，可以想象，越到后合并时间会越来越多。

官方wiki：

MergeFactor （default： 10）

Determines how often segment indices aremerged by addDocument(). With smallervalues, less RAM is used while indexing, and searches are faster, but indexingspeed is slower. With larger values, more RAM is used during indexing, andwhile searches is slower, indexing is faster. Thus larger values (> 10) arebest for batch index creation, and smaller values (< 10) for indices thatare interactively maintained.

MaxMergeDocs（default： 10000）

Determines thelargest segment (measured by document count) that may be merged with othersegments. Small values (e.g., less than 10,000) are best for interactiveindexing, as this limits the length of pauses while indexing to a few seconds.Larger values are best for batched indexing and speedier searches.

简单理解是较高的合并因子，会提高索引速度，会降低索引的搜索效率；较低的合并因子，会降低索引的速度，能提高搜索速度；所以这有一个权衡需要尝试。

一般这两个要合起来使用：

   LogMergePolicy mp = new LogByteSizeMergePolicy();

   mp.setMergeFactor(10 ); //满10个segment合并一次

   mp.setMaxMergeDocs(10000);//segment段最大保存document数

3.5版本以后增加的新特性

TieredMergePolicy根据每一层允许的段数合并大小相似的段。这个策略和之前版本的LogByteSizeMergepolicy策略区别在于它可以合并不相邻的段（即不在同一层），并且区分最多允许一次合并的段数setMaxMergeAtOnce和一层最多容许的段数setSegmentsPerTier。

对于一次普通的合并，首先计算一个“budget”。如果index超过了这个budget，排列所有段按照字节大小从大到小的顺序。找出最小cost的段。段的cost结合skew，总段大小以及pct删除回收计算。越小的Skew，越小的段总大小和更多的删除空间回收的段是cost最低的，也是最适合合并的。

TieredMergePolicymp2 = new TieredMergePolicy();

mp2.setMaxMergeAtOnce(10);// 允许一次合并的段数

mp2.setMaxMergeAtOnceExplicit(30);

mp2.setSegmentsPerTier(10);// 一层最多容许的段数

mp2.setMaxMergedSegmentMB(5*1024);// default: 5G

多core的时候

多core 如果同一时间进行core 切换，会导致内存、cpu压力过大，可以扩展Solr代码，限制最多同时core切换的执行个数。保证不会出现高load或者高cpu 风险。

应用较高安全

最后不低于2个结点工作，并且最好2个结点是跨机器的。
offline与online切换的时候，如果数据量不是很多，可以考虑index与search合一，如果数据量较大，超过5000w的时候，建议index
offline或者search结点之外的其他结点上执行index

cache参数配置

如果更新很频繁，导致commit和reopen频繁，如果可以的话，关闭cache.
如果访问中依赖cache提示性能，那么最好关闭cache warm，no facet 需求
或者开开启cache warm  有facet需要，对fieldvalue cache很依赖的话。
实时更新的话，通常document cache命中率比较低，完全可以不开启这个配置

reopen 和commit

如果可以的话，主磁盘索引，不参入segment合并，新的索引段走不同的目录。并且reopen的时候，主索引的不变动。

commit与reopen异步化

有一部分数据如果不变动，可以考虑使用memory cache 或者locale cache 平衡性能和空间开销，同时避免FGC

中间变量压缩、单例化

所有查询或者建索引过程中，尽量少创建对象，而通过set改变对象值，以及单例化，提升性能。一些较大中间变量，如果可以的话，采取一些整数压缩

对象表示重定义
例如日期、地区、url、byte等一些对象，可以考虑差值、区位码、可别部分、压缩等结构，使得内存开销降低间接使得内存使用率提高，获得更好性能。

index与store 隔离
就是index发挥它的查询性能，store发挥它的存储、响应性能。
也就是不要将所有的内容都放在index中，尽量使得field的属性stored=false

单一实例

自定义的分词，务必使用单例。在索引期间复用单一的IndexWriter实例 ，只定义一个document对象和field对象，然后通过set方式赋值。

search优化

对按指定域排序
展示的时候，对于数字的建议，展示最近1或者3个月数据。例如价格，防止作弊
dump或者建索引的时候，对数字加以上下界检测，及早发现数字本身正确，而实际意义不合理的数据

排序可变性
默认的排序务必有自己的相关参数，并且平衡各方面需求。
排序要变，但是不至于大的波动。排序的细节不公开，但是排序的结果可以解释的清楚。

线上线下
有些分值可以线下完成，有些分值线上完成。看需求。

多域查询
如果默认查询多个域，不妨将多个域合成一个域，只差一个域

高亮
高亮可以在solr里面或者外面执行的，不一定在solr里面执行，可以在solr之外执行
同理，分词可以在线下执行好，dump只执行简单的空格分词即可

统计
facet统计可以先上与线下相结合，不一定完全依赖线上即时计数。

主动搜索
主动搜索查询串务必严格处理，既要去无效查询串，也要适当扩展查询串。
明确查询路径和hit=0的对应处理。