提高Elasticsearch性能的建议
转载自个人博客
之前公司项目中有使用Elasticsearch存储日志，当时使用的功能简单，并没有深入了解Elasticsearch，但是对于该支持文本搜索的存储架构还是很感兴趣，最近因为想在一个新项目中采用ELK（Elasticsearch+Logstash+Kibana）技术栈来存储系统日志，学习有关Elasticsearch的书籍（深入理解Elasticsearch，第二版），现在就书本的第八章——提高性能，总结一些有关使用Elasticsearch的Tips，该书采用的elasticsearch为1.4.X版本。
热点线程检测
热点线程API能向你提供系统变慢变卡顿的必需信息，它给出了什么可能是热点的信息，并使你可以看到系统的哪部分需要更深入的分析，例如查询的执行或者Lucene段的合并。热点线程API返回从CPU的角度来看，elasticsearch哪部分的代码可能是热点的信息，或者由于某些原因elasticsearch卡在了哪里。
使用方法
通过使用如下的命令你可以查看所有节点或者某些、某个节点的情况。
/_nodes/hot_threads
/_nodes/{node or nodes}/hot_threads
例如为了查看所有节点上的热点线程，你可以执行如下的命令：
curl 'localhost:9200/_nodes/hot_threads'
此API支持的参数包括
- threads 需要分析的线程数，默认3
- interval 前后两次检查的时间间隔
- type 需要检查的线程状态的类型，默认是CPU，可以是阻塞、等待等线程状态
- snapshots 需要生产堆栈跟踪快照的数量
例如，想要以1s为周期查看所有节点上处于等待状态的热点线程，可以执行命令：
curl 'localhost:9200/_nodes/hot_threads?type=wait&interval=1s'
执行原理
热点线程检测执行流程如下：
- elasticsearch选取所有运行的线程，收集线程花费CPU的各种信息。
- 等待interval参数指定的时间后，再次收集步骤1中同样的信息。
- 对线程基于其消耗的时间进行排序，取前N（参数threads决定）线程分析
- 每隔几毫秒，对3中选择的线程获取一些堆栈的快照，（数量由snapshots参数决定）
- 组合堆栈信息，返回响应
返回的响应包括：线程所属节点、消耗CPU时间的百分比、使用CPU的方式、线程名，最后跟着一个堆栈跟踪信息，通过以上信息可以定位节点的性能问题。
高负载场景的分类
高负载场景可以分为三种情况：
- 专注于高索引负载
- 专注于高查询负载
- 高查询索引负载并行
后面按照三个场景进行说明
查询、索引负载均衡场景
因为是查询、索引负载均衡的场景，所以一下建议不只是与索引性能、查询性能有关，而是与它们都有关。
正确的存储
选择正确的存储实现，在运行1.3版本以后时尤其重要。
- 如果使用64位系统，考虑使用 mmapfs（内存映射）
- 基于UNIX系统考虑选择 Niofs
- windows系统应该选择 simplefs
- 非持久化的存储考虑 内存存储
elasticsearch 1.3版本以后，默认使用的存储类型是一个 混合 的存储类型default，使用内存映射文件读取term字典，doc values，其他文件采用nio存储。
索引刷新频率
索引刷新的频率是指文档需要多长时间才能出现在搜索结果中。规则非常简单：刷新频率越短，查询越慢，且索引文档的吞吐量越低。默认的刷新频率是1s，这意味着索引查询器每1s都会重新打开一次。如果可以接受一个较慢的刷新频率，可以设置成5s、10s、30s等。
线程池调优
但你看到节点正在填充队列并且仍然有计算能力剩余，且这些计算能力可以被指定用于处理等待处理操作。线程池调优包括线程数以及等待队列长度两个方面。
调整合并过程
Lucene段合并取决与你追加多少数据、多久追加一次等因素，对于Lucene分段和合并，需要记住：有多个段的索引执行查询比只有少量段的索引上执行慢。性能测试显示多个段上执行查询比只有一个段的索引要慢大约10%-15%。
- 如果你希望查询快，就需要更少的段
段合并限流，默认情况下elasticsearch会限制合并的速度在20MB/s，elasticsearch需要限流来避免合并过程中过多的影响搜索。如果使用的是SSD硬盘，那么默认20MB/s是不适合的，通过一下参数设置：
- indices.store.throttle.max_bytes_per_sec设置端合并限流
高查询频率场景
缓存设置
第一个有助于查询性能的缓存是 过滤器缓存 ，可以使用下面的属性，来控制给定节点上能够被过滤器缓存使用的全部内存数量，默认是10%。
indices.cache.filter.size
第二个缓存是 分片查询缓存 ，她的目的是缓存聚合、提示词结果、命中数等，当你的查询使用了聚合、提示词等，最好启用这个缓存。该缓存的大小可以使用如下参数设置：
indices.cache.query.size
查询的思考
- 总是考虑到优化查询结构、过滤器使用等
- 过滤器不影响文档的打分，在计算得分时不被考虑进去
使用路由
如果数据可以使用路由，你应该考虑使用它，可以避免在请求特定数据查询时查询所有的分片。
控制size和shard_size
在处理聚合查询时，合理的设置size、shard_size，size定义了聚合结果返回多少组数据，聚合只会返回前size个结果给客户端；size、shard_size具有相同的意思，只是shard_size其作用是在分片的层次上。
高索引吞吐场景
批量索引
合理的使用批量索引可以显著提高索引的速度，但不要向elasticsearch发送过多的超出其能力的批量索引请求。
doc value 与索引速度的权衡
doc value可以帮助具有 排序、聚合、分组 的操作，但是记录doc value需要在索引时做一些额外的操作，这样会 降低索引速度 和 索引吞吐量 ，所以需要结合具体应用场景，权衡 doc value与索引速度。
控制文档的字段
尽量的保持你存储的字段尽可能的少，你在打多少情况下需要保存的字段是_source，在一些场景下需要判断是否需要存储 _all、_source 等字段。
在禁用_all字段时，设置一个新的默认搜索字段是一个很好的实践，使用如下命令设置：
index.query.default_field：set_your_name
调整事务日志
elasticsearch使用事务日志来获取最新的更新，确保数据的持久化以及优化Lucene索引的写入，默认的事务日志最多保留5000个操作，或者最多占用200MB的空间。两者的参数设置如下：
index.translog.flush_threshold_ops
index.translog.flush_threshold_size
如果需要获取更大的索引吞吐量，愿意付出数据在更长的时间内不能被搜索到，可以调高以上两个默认值。并且在故障发生时，拥有大量事务日志的节点需要更长时间去恢复。
最后
以上是有关elasticsearch使用中的小Tips，后期有时间会继续写一些有关elk技术栈的文章。
转载请标明出处
