Solr调优参考-续

solr调优步骤参考这篇blog主要以实践出发，从顶到底，从大到细的思路来进一步描述，solr优化，并且是基于横向发展来说的（管理更多core），对于纵向的（core内部、搜索核心技术）。 例如分词、queryparse、分词、实时、分布式的优化、排序等偏轻！ 文章有不合理，或者错误的请及时反馈
solr调优步骤参考
这篇blog主要以实践出发，从顶到底，从大到细的思路来进一步描述，solr优化，并且是基于横向发展来说的（管理更多core），对于纵向的（core内部、搜索核心技术）。

例如分词、queryparse、分词、实时、分布式的优化、排序等偏轻！
文章有不合理，或者错误的请及时反馈给鹰缘。

1. 最重要、最影响系统整体稳定和吞吐量(针对业务总索引布局优化)
毫无疑问数据的分区管理、扩容是入口。另外，对于长尾应用，就是大量的小搜索接入，此时管理平台是瓶颈。


参考建议1：
将数据分片，对于solr就是分多core，能细尽量细，单个solr instance上部署core。
保守数据，单coredocument数量控制在2000w以内。
真实场景：4g
memory上日常环境，单core的数据量不大，部署了34个core，没有出啥问题。真实物理机上部署过24core，单core超过6G的索引。

参考建议2：
如果可以，建索引和查询服务器独立开来，最好的方式是前后排，不行的话就弄个集中build。
前后排是最完美了，集中build在索引同步和core切换依然对线上查询有一定影响。

参考建议3：
全量索引构建和索引查询甚至可以分开优化，构建索引的引擎可以特殊调节参数，加速索引的构建。例如，并行document，单线程write
document，而多份数据同时运行，之后merger等。极端的可以采取C++ 版构建索引，前提是索引结构要一致。

参考建议4：
流式传输。索引本身就是基于segment的分片，便于增量，增量到一定程度支持merger为更大片增量。完全可以实习流式的segment级别的索引同步，要求一个可靠的传输协议。solr
目前基于commitpoint点的增量传输还可以进一步优化。

2.针对core的优化（针对单索引优化）
core的优化首先看schema的设置。

参考建议1：
schema的字段，要每个字段每个字段去细扣。
能不stored的，将stored=false。多个需要stored的，可以考虑组成新的doc，存储到数据库，索引存共同id

能合并的，合并。合并的字段，例如属性类似的，可以考虑空格分开，然后term查询。
long short int的类型，统一使用trie类型。
如果文本排序很弱，全部text类型去掉频率位置信息，索引体积、性能有一定提升
对应时间、url等类型，执行转化、压缩，减少文本和索引相

参考建议2：
单core里面分多子目录，solr里面能针对多子目录做快速定位查询的。

参考建议3：
core可以共享index目录的，可以尝试多个core，共享相同索引目录。不同core处理一类特征请求，并针对性缓存相关信息。

3.针对query优化（针对单索引读优化）
query中能简单，尽量简单。fq使用的话，一定要配置相关cache，cache命中率反应参数大小。

参考建议1：
fq尽管可以缓存，建议fq的粒度尽量大的同时能与其他query共享。fq的FastLRUcache
值在追求命中率的同时，需要平衡gc，cache大了 gc会很频繁。
对应实时索引更新的，cache建议不要开了，频繁的reopen会导致cache的频繁迁移，实际效果不好。
facet的，这个值是lucene里面用到，能开大尽量开大，对gc尤其影响明显。慎重参数值。
在准确性上，queryparse建议使用dismax，除非对排序不是特别要求，要看具体业务，可以采取boolean 查询。
优先使用dismax，次之phrasequery，再次之booleanquery。

参考建议2：
大区间、多OR、多AND等查询，需要针对性优化。优化上次尽量与solr统一，尤其是cache的统一，底层尽量往luceneAPI靠近，尽量减少IO、充分发挥cache、减少不必要的中间解析。需要兼顾相关度有时候。

参考建议3：
如果有些数据的读写非常特别，不妨领出来，单独对象处理。例如放到本地cache中。

4.针对系统配置
主要是基础环境的选择。
参考建议1：
JVM heap不是越大越好，要兼顾gc。新生代从小值开始，逐步增大到合适。让old去空间大些，perm去两值相同
在8g及以上，务必使用CMS，cms的各参数也需要微调
极端情况，可以尝试关闭swapoff
在GC配置同时，关注cache的配置，cache往往在开启后，占住大量内存。

参考建议2：
tomcat、jetty尽量使用轻量级容器。

Elasticsearch 学习笔记（一）-----Lucene的简介以及索引原理 今天，正式开始学习Elasticsearch，因为Elasticsearch是用Lucene来实现索引的查询功能的，所以，理解Lucene的原理显的尤为重要。
Elasticsearch 性能调优指南——推荐实战 DSL 本文是在以下 6 篇基础上的继续扩展版本，不求大而全，只求对实战有帮助。 1、干货 | Elasticsearch 运维实战常用命令清单 2、干货 | Elasticsearch Top10 监控指标 3、你不得不关注的 Elasticsearch Top X 关键指标 4、干货 | Elasticsearch 开发实战常用命令清单 5、干货 | Elasticsearch开发人员最佳实战指南 6、Elasitcsearch 开发运维常用命令集锦
Elasticsearch：从写入原理谈写入优化 1、线上实战问题 问题 1：想要请问一下，我这边需求是每分钟利用 sparksteaming 插入按天的索引150万条数据。一般情况下还好，索引7个分片，1副本，但是偶尔会出现延迟很高的情况。比如：一般情况下1分钟插入150万能正常插入，可能突然就出现了需要5分钟才能插入成功，然后又正常了。很头疼。
Elasticsearch 检索性能优化实战指南 1、当我们在说 Elasticsearch 检索性能优化的时候，实际在说什么？！ 检索响应慢！ 并发检索用户多时，响应时间不达标 怎么还没有出结果？ 怎么这么慢？ 为啥竞品产品的很快就返回结果了？
Elasticsearch之SearchScroll原理剖析和优化 Elasticsearch是一款优秀的开源企业级搜索引擎，其查询接口主要为Search接口，提供了丰富的各类查询、排序、统计聚合等功能。本文将要介绍的是另一个查询接口SearchScroll，同时介绍一下我们在这方面做的一些性能和稳定性等方面的优化工作。 Elasticsearch的SearchScroll接口可用于从索引中检索大量数据，或者是所有的数据，值得注意的是Elasti
Elasticsearch搜索调优权威指南 （2/3） Elasticsearch搜索调优权威指南，是QBOX在其博客上发布的系列文章之一，本文是该系列的第二篇，主要介绍了索引预处理、mapping建立、避免脚本的使用、索引段合并等搜索性能相关的调优方法。