ElasticSearch优化
一：集群节点规划
elasticSearch的配置文件中有2个参数：node.master和node.data。这两个参数搭配使用时，能够帮助提供服务器性能。
1、数据节点node.master: false node.data: true
该node服务器只作为一个数据节点，只用于存储索引数据。使该node服务器功能单一，只用于数据存储和数据查询，降低其资源消耗率。
2、master节点node.master:
true node.data: false
该node服务器只作为一个主节点，但不存储任何索引数据。该node服务器将使用自身空闲的资源，来协调各种创建索引请求或者查询请求，讲这些请求合理分发到相关的node服务器上。
3、负载均衡节点node.master: false node.data: false
该node服务器即不会被选作主节点，也不会存储任何索引数据。该服务器主要用于查询负载均衡。在查询的时候，通常会涉及到从多个node服务器上查询数据，并请求分发到多个指定的node服务器，并对各个node服务器返回的结果进行一个汇总处理，最终返回给客户端。
一台服务器上最好只部署一个Node
一台物理服务器上可以启动多个Node服务器节点（通过设置不同的启动port），但一台服务器上的CPU,内存，硬盘等资源毕竟有限，从服务器性能考虑，不建议一台服务器上启动多个node节点。
在大规模局点,比如100个点，可以专门配备3个Master，可使用3台具有内存的刀片即可，即参数配置为node.master:
true，node.data:
false；可以按比例配备数据汇聚节点，比如10个，即参数配置为node.master:
false，node.data:
false；小规模节点，可以不用如此设置，当然如果依然有性能问题，也是一个优化的措施。
关闭data节点服务器中的http功能：
针对ElasticSearch集群中的所有数据节点，不用开启http服务。将其中的配置参数这样设置：http.enabled:
false，同时也不要安装head, bigdesk, marvel等监控插件，这样保证data节点服务器只需处理创建/更新/删除/查询索引数据等操作。
http功能可以在非数据节点服务器上开启，上述相关的监控插件也安装到这些服务器上，用于监控ElasticSearch集群状态等数据信息。
这样做一来出于数据安全考虑，二来出于服务性能考虑。
二：机器设置（内存）
1、预留一半内存给Lucene使用
一个常见的问题是配置堆太大。你有一个64 GB的机器，觉得JVM内存越大越好，想给Elasticsearch所有64 GB的内存。
当然，内存对于Elasticsearch来说绝对是重要的，用于更多的内存数据提供更快的操作。而且还有一个内存消耗大户-Lucene
Lucene的设计目的是把底层OS里的数据缓存到内存中。Lucene的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。
Lucene的性能取决于和OS的交互，如果你把所有的内存都分配给Elasticsearch，不留一点给Lucene，那你的全文检索性能会很差的。
最后标准的建议是把50%的内存给elasticsearch，剩下的50%也不会没有用处的，Lucene会很快吞噬剩下的这部分内存。
2、32GB限制
给ES的内存配置不是越大越好，建议不能超过32GB，不同jdk版本最大边界值是不同的，对于32位小于32G JVM才采用内存对象指针压缩技术，不然对象指针需要占用很大的内存
使用如下命令测试最大边界值：
java-Xmx32767m -XX:+PrintFlagsFinal2>/dev/null |grep UseCompressedOops
boolUseCompressedOops= false{lp64_product}
java -Xmx32766m -XX:+PrintFlagsFinal2>/dev/null |grep UseCompressedOops
bool UseCompressedOops= true{lp64_product}
$ JAVA_HOME=`/usr/libexec/java_home
-v 1.8` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grepUseCompressedOops
boolUseCompressedOops:= true
$ JAVA_HOME=`/usr/libexec/java_home
-v 1.8` java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grepUseCompressedOops
bool UseCompressedOops= false
在ES启动日志中最好能够看到压缩对象指针为真。
heap size [15.8gb], compressed ordinary object pointers [true]
在java中，所有的对象都分配在堆上，然后有一个指针引用它。指向这些对象的指针大小通常是CPU的字长的大小，不是32bit就是64bit，这取决于你的处理器，指针指向了你的值的精确位置。
对于32位系统，你的内存最大可使用4G。对于64系统可以使用更大的内存。但是64位的指针意味着更大的浪费，因为你的指针本身大了。浪费内存不算，更糟糕的是，更大的指针在主内存和缓存器（例如LLC, L1等）之间移动数据的时候，会占用更多的带宽。
java使用一个叫内存指针压缩的技术来解决这个问题。它的指针不再表示对象在内存中的精确位置，而是表示偏移量。这意味着32位的指针可以引用40亿个对象，而不是40亿个字节。最终，也就是说堆内存长到32G的物理内存，也可以用32bit的指针表示。
一旦你越过那个神奇的30-32G的边界，指针就会切回普通对象的指针，每个对象的指针都变长了，就会使用更多的CPU内存带宽，也就是说你实际上失去了更多的内存。事实上当内存到达40-50GB的时候，有效内存才相当于使用内存对象指针压缩技术时候的32G内存。
这段描述的意思就是说：即便你有足够的内存，也尽量不要超过32G，因为它浪费了内存，降低了CPU的性能，还要让GC应对大内存。
3、机器内存大于64GB
你可以考虑一台机器上创建两个或者更多ES节点，而不要部署一个使用32+GB内存的节点。仍然要坚持50%原则，假设你有个机器有128G内存，你可以创建两个node，使用32G内存。也就是说64G内存给ES的堆内存，剩下的64G给Lucene。
如果你选择第二种，你需要配置cluster.routing.allocation.same_shard.host:true。这会防止同一个shard的主副本存在同一个物理机上（因为如果存在一个机器上，副本的高可用性就没有了）
4、swapping是性能的坟墓
这是显而易见的，但是还是有必要说的更清楚一点，内存交换到磁盘对服务器性能来说是致命的。想想看一个内存的操作必须是快速的。
如果内存交换到磁盘上，一个100微秒的操作可能变成10毫秒，再想想那么多10微秒的操作时延累加起来。不难看出swapping对于性能是多么可怕。
最好的办法就是在你的操作系统中完全禁用swapping。这样可以暂时禁用：
sudo swapoff -a
为了永久禁用它，你可能需要修改/etc/fstab文件，这要参考你的操作系统相关文档。
如果完全禁用swap，对你来说是不可行的。你可以降低swappiness的值，这个值决定操作系统交换内存的频率。这可以预防正常情况下发生交换。但仍允许os在紧急情况下发生交换。对于大部分Linux操作系统，可以在sysctl中这样配置：
vm.swappiness = 1
备注：swappiness设置为1比设置为0要好，因为在一些内核版本，swappness=0会引发OOM（内存溢出）
最后，如果上面的方法都不能做到，你需要打开配置文件中的mlockall开关，它的作用就是运行JVM锁住内存，禁止OS交换出去。在elasticsearch.yml配置如下：bootstrap.mlockall: true
5、heap参数设置优化
命令行修改
./bin/elasticsearch-Xmx10g -Xms10g
xmx-JVM最大允许分配的堆内存，按需分配
xms-JVM初始分配的堆内存
此值设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
对Unix系统，可修改./bin/elasticsearch.in.sh文件：
一般分配主机1/4-1/2的内存
if["x$ES_MIN_MEM"=
"x"];then
ES_MIN_MEM=12g
fi
if["x$ES_MAX_MEM"=
"x"];then
ES_MAX_MEM=12g
fi
JAVA_OPTS="$JAVA_OPTS
-Xms${ES_MIN_MEM}"
JAVA_OPTS="$JAVA_OPTS-Xmx${ES_MAX_MEM}"
线程大小, ES单线程承载的数据量比较大
JAVA_OPTS="$JAVA_OPTS
-Xss128m"
三：机器设置（硬盘、CPU）
硬盘对集群非常重要，特别是建索引多的情况。磁盘是一个服务器最慢的系统，对于写比较重的集群，磁盘很容易成为集群的瓶颈。
如果可以承担的器SSD盘，最好使用SSD盘。如果使用SSD，最好调整I/O调度算法。RAID0是加快速度的不错方法。
ES建议机器配置：64G内存SSD硬盘RAID0，不要使用NAS。
1、自动调整存储带宽
在2.0.0之前，elasticsearch会限制合并速度（merges），默认为20MB/sec。但是这个速率经常是显得太小，导致合并速度落后于索引速度，进而限制了索引速度。
现在Elasticsearch2.0.0，使用了自动调整合并IO速度方式：如果合并落于索引速度，合并IO速度会逐渐增大，并且随着合并的持续进行会减小。在索引吞吐量小的时候，即使突然来了一个大的合并任务，这种情况也不会吞噬整个节点可用的IO，极小化的降低对正在进行的查询和索引的影响。
但是对索引请求大的情况下，允许的合并速度会自动调整到跟上索引的速度。
有了2.0.0这个特性，意味着我们不需要管任何的限制值了，只要用默认的就好了。
2.0.0之前store throttle设置值有如下几个，在2.0.0版本已经删除了。
indices.store.throttle.type,
indices.store.throttle.max_bytes_per_sec,
index.store.throttle.type,
index.store.throttle.max_bytes_per_sec
另外，Recovery/snapshot/restore仍然是有速度限制的，默认都是20MB/sec。
2、多个path.data路径
如果磁盘空间和IO性能是Elasticsearch的瓶颈的话，使用多个IO设备（通过设置多个path.data路径）存储shards，能够增加总的存储空间和提升IO性能。
在Elasticsearch2.0之前的版本，也是配置多个path.data路径，但是其相当于RAID
0，每个shards的数据会分布在所有的磁盘上。当一个节点上有一块盘坏了的情况下，该节点上所有的shards都会损坏了。需要恢复该节点上的所有shards。
在2.0.0版本，把这个实现改成了：每个shards所有的数据只会在一块磁盘上面。这样即使一个节点的一块磁盘损坏了，也只是损失了该磁盘上的shards，其它磁盘上的shards安然无事。只需要恢复该块盘上的shards即可。
升级到2.0.0版本时，旧版本一个shard分布到所有磁盘上的数据，会拷贝到一块盘上。
对应这个改变，在设计shards时，如果一个节点有10块磁盘，共3个节点，则shards至少30个，才能分布在30块盘上（即最大限度使用磁盘空间）。
参考
https://www.elastic.co/blog/performance-indexing-2.0
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
3、CPU（threadpool）
线程不是越大越好，一般设置threadpool数为CPU cores的个数
搜索：int((# of cores * 3) / 2) + 1
ElasticSearch服务器有多个线程池大小配置。主要有：index，search，suggest，get，bulk，percolate，snapshot，snapshot_data，warmer，refresh。
在此主要针对index和search进行一个配置调整。index操作包含：创建/更新/删除索引数据。search操作主要针对用户的各种搜索操作。
具体配置如下：
threadpool:
index:
type:fixed
size:100
search:
type:fixed
size:1000
参考文档
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
四：索引过程
大家可能会遇到索引数据比较慢的过程。其实明白索引的原理就可以有针对性的进行优化。ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展，而这ES主要是用tranlog进行各节点之间的数据平衡。所以从上我可以通过索引的settings进行第一优化：
"index.translog.flush_threshold_ops":"10000"
"refresh_interval"
: "1s"
这两个参数第一是到translog数据达到多少条进行平衡，默认为5000，而这个过程相对而言是比较浪费时间和资源的。所以我们可以将这个值调大一些还是设为-1关闭，进而手动进行translog平衡。第二参数是刷新频率，默认为1s是指索引在生命周期内定时刷新，一但有数据进来能refresh像lucene里面commit,我们知道当数据addDoucment后，还不能检索到要commit之后才能行数据的检索，所以可以将其关闭，在最初索引完后手动refresh之，然后将索引setting里面的index.refresh_interval参数按需求进行修改，从而可以提高索引过程效率。
另外的知道ES索引过程中如果有副本存在，数据也会马上同步到副本中去。我个人建议在索引过程中将副本数设为0，待索引完成后将副本数按需量改回来，这样也可以提高索引效率。
“number_of_replicas”:
0
其实检索速度快度与索引质量有很大的关系。而索引质量的好坏主要与以下几方面有关：
1、分片数
分片数是与检索速度非常相关的的指标，如果分片数过少或过多都会导致检索比较慢。分片数过多会导致检索时打开比较多的文件别外也会导致多台服务器之间通讯。而分片数过少会导致单个分片索引过大，所以检索速度慢。基于索引分片数=数据总量/单分片数的计算公式，在确定分片数之前需要进行单服务单索引单分片的测试，目前我们测试的结果单个分片的内容为10G。
分片（Shard）：一个索引会分成多个分片存储，分片数量在索引建立后不可更改，推荐【分片数*副本数=集群数量】
2、确定分片(shard)的数量和副本(replica)的数量
ElasticSearch在创建索引数据时，最好指定相关的shards数量和replicas，否则会使用服务器中的默认配置参数shards=5，replicas=1。
因为这两个属性的设置直接影响集群中索引和搜索操作的执行。假设你有足够的机器来持有碎片和副本，那么可以按如下规则设置这两个值：
1)拥有更多的碎片可以提升索引执行能力，并允许通过机器分发一个大型的索引；
2)拥有更多的副本能够提升搜索执行能力以及集群能力。
对于一个索引来说，number_of_shards只能设置一次，而number_of_replicas可以使用索引更新设置API在任何时候被增加或者减少。
这两个配置参数在配置文件的配置如下：
index.number_of_shards: 5
number_of_replicas:1
Elastic官方文档建议：一个Node中一个索引最好不要多于三个shards.配置total_shards_per_node参数，限制每个index每个节点最多分配多少个发片.
http://www.open-open.com/doc/view/f240d61f8f7745098b4459c2483feb40
3、副本数
副本数与索引的稳定性有比较大的关系，如果Node在非正常挂了，经常会导致分片丢失，为了保证这些数据的完整性，可以通过副本来解决这个问题。建议在建完索引后在执行Optimize后，马上将副本数调整过来。
4、分词
分词对于索引的影响可大可小，看自己把握。大家或许认为词库越多，分词效果越好，索引质量越好，其实不然。分词有很多算法，大部分基于词表进行分词。也就是说词表的大小决定索引大小。所以分词与索引膨涨率有直接关系。词表不应很多，而对文档相关特征性较强的即可。比如论文的数据进行建索引，分词的词表与论文的特征越相似，词表数量越小，在保证查全查准的情况下，索引的大小可以减少很多。索引大小减少了，那么检索速度也就提高了。
5、索引段
索引段即lucene中的segments概念，我们知道ES索引过程中会refresh和tranlog也就是说我们在索引过程中segments number不只一个。而segments number与检索是有直接联系的，segments number越多检索越慢，而将segments numbers有可能的情况下保证为1，这将可以提高将近一半的检索速度。
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
优化建议
1.目前Elasticsearch5.x运行在Oracle JDK1.8以上环境中，ES性能体现在在分布式计算中，一个节点是不足以测试出其性能，一个生产系统至少在三个节点以上。
2.ES集群节点规划良好，master、node、client分离开来，data节点关闭http功能。
3.合理利用内存。
a) JVM内存设置不要超过机器的一半内存，并且不超过32G。（./bin/elasticsearch -Xmx10g -Xms10g或者修改./bin/elasticsearch.in.sh文件：
一般分配主机1/4-1/2的内存
if["x$ES_MIN_MEM"=
"x"];then
ES_MIN_MEM=12g
fi
if["x$ES_MAX_MEM"=
"x"];then
ES_MAX_MEM=12g
fi
JAVA_OPTS="$JAVA_OPTS
-Xms${ES_MIN_MEM}"
JAVA_OPTS="$JAVA_OPTS
-Xmx${ES_MAX_MEM}"
设置每个线程的堆栈大小, ES单线程承载的数据量比较大
JAVA_OPTS="$JAVA_OPTS -Xss128m"
b)修改swapping参数，内存不够用时才进行swapping（vm.swappiness=
1）
c)暂时不要修改GC方法
d）锁定内存，不让JVM写入swapping，避免降低ES的性能
bootstrap.mlockall: true
e）缓存类型设置为Soft Reference，只有当内存不够时才会进行回收
index.cache.field.max_size:50000
index.cache.field.expire: 10m
index.cache.field.type: soft
4.权衡建索引的性能和检索的时效性，修改以下参数。
“index.translog.flush_threshold_ops”:”10000”
“index.refresh_interval”:1
“number_of_replicas”: 0
5.倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment
memory增长趋势。
定期对不再更新的索引做optimize (ES2.0以后更改为force merge api)。这Optimze的实质是对segment file强制做合并，可以节省大量的segment memory
6.根据机器数，磁盘数，索引大小等硬件环境，根据测试结果，设置最优的分片数和备份数，单个分片最好不超过10GB，定期删除不用的索引，做好冷数据的迁移。
7.保守配置内存限制参数，尽量使用doc value存储以减少内存消耗，查询时限制size、from参数。
8.如果不使用_all字段最好关闭这个属性，否则在创建索引和增大索引大小的时候会使用额外更多的CPU，如果你不受限CPU计算能力可以选择压缩文档的_source。这实际上就是整行日志，所以开启压缩可以减小索引大小。
9.避免返回大量结果集的搜索与聚合。缺失需要大量拉取数据可以采用scan &
scroll api来实现。
10.熟悉各类缓存作用，如field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用。
11.必须结合实际应用场景，并对集群使用情况做持续的监控。
