Elasticsearch全方面优化点

Elastic优化点

优化点

分片策略
分片分配行为
segement
路由优化
避免内存交换(内存交换空间一定要关闭)
副本
控制索引合并
tranlog
内存分配大小
http://www.tuicool.com/articles/7fueUbb

分片

• 上面讲到的每个分片最好不超过30GB的原则依然使用
• 一个好的方案是根据你的节点数量按照1.5~3倍的原则来创建分片

如果你有3个节点, 则推荐你创建的分片数最多不超过9(3x3)个

当索引拥有较多分片时,为了组装查询结果,ES必须单独查询每个分片(当然并行的方式)并对结果进行合并.所以高性能IO设备(SSDs)和多核处理器无疑对分片性能会有巨大帮助

如果你真的认为这可能是你能达到200GB（但不多进一步而无其他基础设施的变化），那么我们建议最多的7个碎片或8个碎片的分配
您仍然可以使用30GB的最大碎片尺寸指引
Max number of nodes = Number of shards * (number of replicas +1)

路由机制

• Elasticsearch的路由机制即是通过哈希算法

它会将文档的ID值作为依据将其哈希到相应的主分片上，这种算法基本上会保持所有数据在所有分片上的一个平均分布，而不会产生数据热点
shard = hash(routing) % number_of_primary_shards

segment

• http://udn.yyuap.com/doc/mastering-elasticsearch/chapter-3/36_README.html

因为默认每 1 秒，都会有一个新文件产生一天有86400秒，设想一下，每次请求要扫描一遍 86400 个文件，这个响应性能绝对好不了！
为了解决这个问题，ES 会不断在后台运行任务，主动将这些零散的 segment 做数据归并，尽量让索引内只保有少量的，每个都比较大的，segment 文件

归并策略
归并线程是按照一定的运行策略来挑选 segment 进行归并的。主要有以下几条：
index.merge.policy.floor_segment 默认 2MB，小于这个大小的 segment，优先被归并。
index.merge.policy.max_merge_at_once 默认一次最多归并 10 个 segment
index.merge.policy.max_merge_at_once_explicit 默认 forcemerge 时一次最多归并 30 个 segment。
index.merge.policy.max_merged_segment 默认 5 GB，大于这个大小的 segment，不用参与归并。forcemerge 除外。
根据这段策略，其实我们也可以从另一个角度考虑如何减少 segment 归并的消耗以及提高响应的办法：加大 flush 间隔，尽量让每次新生成的 segment 本身大小就比较大

• elasticsearch中的每个分片包含多个segment，每一个segment都是一个倒排索引；在查询的时，会把所有的segment查询结果汇总归并后最为最终的分片查询结果返回
• elasticsearch会把文档信息写到内存bugffer中（为了安全，也一起写到translog），定时（可配置）把数据写到segment缓存小文件中，然后刷新查询，使刚写入的segment可查
• index.refresh_interval：1s
• 合并原因

索引中存在的段越多，搜索响应速度就会越慢，内存占用也会越大
段合并还能够提高搜索的效率，毕竟同样的信息，在一个段中读取会比在多个段中读取要快得多

副本

副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务
我们既可以从主分片上获取文档又可以从副本上获得文档
读操作——搜索和返回数据——可以同时被主分片或副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量

为了读取请求，协调节点在每次请求的时候将选择不同的副本分片来达到负载均衡；通过轮询所有的副本分片

文档元数据

_index 文档在哪存放
_type 文档表示的对象类别
_id 文档唯一标识

最佳方案（查询级别segment）

• 有聚合(汇总)操作(最好完全利用到集群的核数)

ssd
分片数等于节点数
段减少（不能太少，保证并发数）

• 无聚合操作（完全利用到集群的核数）

分片越多越好（并发高，单个数据小查询快返回快）

• 影响因素

段大小影响性能（明显）

内存大小

不超过３２G，超过３２Ｇ就不会使用压缩指针，分配内存越大（ＧＣ时间越长，停顿时间越长）
ＣＰＵ（８核心的服务器CPU）
jdk8以上