最近一年使用 Elasticsearch 完成亿级别日志搜索平台「ELK」，亿级别的分布式跟踪系统。在设计这些系统的过程中，底层都是采用 Elasticsearch 来做数据的存储，并且数据量都超过亿级别，甚至达到百亿级别。
所以趁着有空，就花点时间整理一下具体怎么做 Elasticsearch 性能优化，希望能对 Elasticsearch 感兴趣的同学有所帮助。
Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。Elasticsearch 是用 Java 开发的，并作为 Apache 许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
作为一个开箱即用的产品，在生产环境上线之后，我们其实不一定能确保其的性能和稳定性。如何根据实际情况提高服务的性能，其实有很多技巧。
下面我就从三个方面分别来讲解下优化服务的性能：
索引优化主要是在 Elasticsearch 插入层面优化，如果瓶颈不在这块，而是在产生数据部分，比如 DB 或者 Hadoop 上，那么优化方向就需要改变下。同时，Elasticsearch 本身索引速度其实还是蛮快的，具体数据，我们可以参考官方的 benchmark 数据。
当有大量数据提交的时候，建议采用批量提交。
比如在做 ELK 过程中 ，Logstash indexer 提交数据到 Elasticsearch 中 ，batch size 就可以作为一个优化功能点。但是优化 size 大小需要根据文档大小和服务器性能而定。
像 Logstash 中提交文档大小超过 20MB ，Logstash 会请一个批量请求切分为多个批量请求。
如果在提交过程中，遇到 EsRejectedExecutionException 异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error 级别以上的日志。
优化硬件设备一直是最快速有效的手段。
为了提高索引性能，Elasticsearch 在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1 秒 （index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到操作系统中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能。
当然像我们的内部系统对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效的减少 segment 合并压力，提供索引速度。在做全链路跟踪的过程中，我们就将 index.refresh_interval 设置为 30s，减少 refresh 次数。
同时，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为 -1，数据导入成功后再打开到正常模式，比如 30s。
Elasticsearch 默认副本数量为 3 个，虽然这样会提高集群的可用性，增加搜索的并发数，但是同时也会影响写入索引的效率。
在索引过程中，需要把更新的文档发到副本节点上，等副本节点生效后在进行返回结束。使用 Elasticsearch 做业务搜索的时候，建议副本数目还是设置为 3 个，但是像内部 ELK 日志系统、分布式跟踪系统中，完全可以将副本数目设置为 1 个。
当我们查询文档的时候，Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来
shard = hash(routing) % number_of_primary_shards
routing 默认值是文档的 id，也可以采用自定义值，比如用户 id。
在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2 个步骤
查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。
向上面自定义的用户查询，如果 routing 设置为 userid 的话，就可以直接查询出数据来，效率提升很多。
Ebay 曾经分享过他们使用 Elasticsearch 的经验中说到：
Use filter context instead of query context if possible.
尽可能使用过滤器上下文（Filter）替代查询上下文（Query
Elasticsearch 针对 Filter 查询只需要回答「是」或者「否」，不需要像 Query 查询一下计算相关性分数，同时 Filter 结果可以缓存。
在使用 Elasticsearch 过程中，应尽量避免大翻页的出现。
正常翻页查询都是从 From 开始 Size 条数据，这样就需要在每个分片中查询打分排名在前面的 From + Size 条数据。协同节点收集每个分配的前 From + Size 条数据。协同节点一共会受到 N * （ From + Size ）条数据，然后进行排序，再将其中 From 到 From + Size 条数据返回出去。
如果 From 或者 Size 很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU 资源消耗增大。
可以通过使用 Elasticsearch scroll 和 scroll-scan 高效滚动的方式来解决这样的问题。具体写法，可以参考 Elasticsearch: 权威指南 - scroll 查询
Elasticsearch 默认安装后设置的堆内存是 1 GB。 对于任何一个业务部署来说， 这个设置都太小了。
比如机器有 64G 内存，那么我们是不是设置的越大越好呢？
其实不是的。
主要 Elasticsearch 底层使用 Lucene。Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构。 Lucene 的段是分别存储到单个文件中的。因为段是不可变的，这些文件也都不会变化，这是对缓存友好的，同时操作系统也会把这些段文件缓存起来，以便更快的访问。
如果你把所有的内存都分配给 Elasticsearch 的堆内存，那将不会有剩余的内存交给 Lucene。 这将严重地影响全文检索的性能。
标准的建议是把 50％ 的可用内存作为 Elasticsearch 的堆内存，保留剩下的 50％。当然它也不会被浪费，Lucene 会很乐意利用起余下的内存。
同时了解过 ES 的同学都听过过「不要超过 32G」的说法吧。
其实主要原因是 ：JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。
在 Java 中，所有的对象都分配在堆上，并通过一个指针进行引用。 普通对象指针（OOP）指向这些对象，通常为 CPU 字长 的大小：32 位或 64 位，取决于你的处理器。指针引用的就是这个 OOP 值的字节位置。
对于 32 位的系统，意味着堆内存大小最大为 4 GB。对于 64 位的系统， 可以使用更大的内存，但是 64 位的指针意味着更大的浪费，因为你的指针本身大了。更糟糕的是， 更大的指针在主内存和各级缓存（例如 LLC，L1 等）之间移动数据的时候，会占用更多的带宽.
所以最终我们都会采用 31 G 设置
-Xms 31g
-Xmx 31g假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene
我在51CTO博客开了一个专栏——《带你玩转高可用》希望可以帮助有一定分布式系统架构知识，在架构方面力求进阶的分布式系统架构从业人员，提高架构可用性，实现高可用目标。
《带你玩转高可用带你玩转高可用》
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
