写给Java应用开发看的Elasticsearch调优手册

随着数据量的增长，MySQL在很多场景下，似乎已经无能为力了，所以有不少应用的数据从MySQL迁移到了Elasticsearch，我们的应用就在其中。由于开发时间紧张，所以仅仅只是了解了下Elasticsearch的基本知识，随便写了几个Demo，然后直接在正式的环境中使用Elasticsearch。因为给我们应用分配的Elasticsearch服务器足够强大，Elasticsearch本身也设计的足够好，当时数据量也没有那么海量，并发也没有那么高，所以一直没有问题，但是该来的总会来，随着公司的发展，数据量也在直线增长，并发越来越高，性能问题越来越明显，看着公司内，有越来越多的应用接入了Elasticsearch，看着公司外，有越来越的公司也引入了Elasticsearch，我意识到必须深入的了解下Elasticsearch。经过大半年的断断续续学习，终于对Elasticsearch有了一定的了解，但是我毕竟不是专门做搜索引擎的，更没有强大的算法、数据结构思维，所以对Elasticsearch的了解也仅仅是停留在“用的不这么差”的程度上，所以本篇博客主要是写给Java应用开发看的，如果是专门做搜索引擎的，就一笑而过吧。

优化漏斗

凡是涉及到某个组件的性能调优，我们在脑海中就要浮现出一张很经典的优化漏斗图：

左边就是很经典的漏斗图，漏斗分为四层，从上到下分别为：

使用
应用配置
JVM
OS

总的来说，层级在上面的，调优的效果越明显，由于我们的Elasticsearch是独立部署在服务器上的，所以服务器的配置也至关重要。对于Elasticsearch而言，硬件配置是基础，正确的使用姿势是核心，缺一不可。

本篇博客，我们就从这五个方面来对Elasticsearch进行调优。

硬件

Elasticsearch和普通应用不同，普通应用也许4C8G的配置就足够了，但是Elasticsearch需要比较好的配置，如果配置实在太低，就放弃Elasticsearch吧。

节点配置

Elasticsearch有三个常用的节点类型：Master节点、数据节点、协调节点，我们来看下这三种节点的职责以及需要什么样的配置。

数据节点：主要负责保存数据，查询数据，所以这个节点的配置要求是最高的，不管是CPU、内存、磁盘，都要高配的，磁盘最好采用RAID0、SSD，为什么是RAID0？因为Elasticsearch本身就有冗余副本的存在，可以保证不丢失数据；
Master节点：一个Elasticsearch集群中只会有一个Master节点，Master主要负责管理集群变更、元数据的管理，该节点不需要太好的配置；
协调节点：接受客户端的请求，并将请求路由到数据节点，然后将数据节点返回的内容进行处理，比如合并，排序等等，所以此节点对CPU、内存的要求是比较高的。

为了更加清晰，我给大家准备了一个表格：

节点类型	CPU	内存	磁盘
数据节点	高配置	高配置	高配置
Master节点	低配置	低配置	低配置
协调节点	高配置	高配置	低配置

我们在做数据查询的时候，协调节点会把请求路由给多个数据节点，多个数据节点再把数据响应给协调节点，协调节点再对数据进行加工处理，返回给客户端，需要做多次数据搬运，而且数据可能都不小，所以低延迟的网络也是必需的。

节点的单一职责

编码的时候，为了代码的扩展性、可维护性，我们需要满足“单一职责”，在分配节点的时候，为了Elasticsearch的性能，也需要满足“单一职责”，即：一个节点只做一件事情。

想想也是，Master节点作为集群的老大，相当于公司管理，数据节点是大头兵，如果Matser节点既要做管理的事情，又要做大头兵的事情，那会出现什么局面？

所以在条件允许的情况下，一个节点只做一件事情。

分片数（每个分片的大小控制在30-50G，3-5个分片可以满足大部分场景）

每个分片的大小控制在30-50G，Elasticsearch是严重依赖PageCache的，最好保证分片中的数据有1/3都在PageCache中。

如果你不想计算到底需要多少个分片，可以无脑配置3-5个分片，这满足大部分场景，毕竟一般的公司，你申请Elasticsearch集群，没有特殊的说明，运维小伙伴也是直接给你一个默认配置下的Elasticsearch集群，也不会特意问你数据的规模，如果你查询一下，会发现就是3-5个分片。

副本数（一个副本就够）

一个副本就够了，如果是数据迁移，为了追求迁移的速度，甚至可以把副本关闭了，等数据迁移完毕，再开启副本。

OS配置

禁用/少用swap

OS在内存不够用的时候，会将部分数据交换到swap空间（磁盘）上，但是磁盘的速度哪比得上内存的速度，所以会导致性能直线下降，所以应该关闭swap。

如果完全禁用swap，当内存不够用，OS可能会kill进程，所以为了可用性，也有一些人认为不要完全禁用swap，可以将swap设置成一个很小的数值，这样当性能直线下降，开发、运维都会有感知，可以给开发、运维处理的时间。

文件描述符设置为65535或更大

关闭atime

每次读取文件，Linux都会更新atime，没有实际用处，可以关闭。

设置最少的线程数量

Elasticsearch运行时会创建多种线程池来执行各种各样的操作，所以必须保证Elasticsearch可以创建足够的线程，而这个数量最少为4096。

减少TCP重传次数

Elasticsearch集群各个节点间的通信是使用TCP的，但是在丢包的情况下，Linux最多重传15次，而这15次重传会耗时900秒以上。这意味着系统发现网络分区故障需要非常长的时间，所以可以适当降低TCP重传次数。

JVM配置

最小堆内存和最大堆内存必须一样

如果最小堆内存、最大堆内存不一样，在运行的过程中，会频繁的进行伸缩。

最大堆内存不要超过服务器内存的一半

Elasticsearch是严重依赖PageCache的，最好保证分片中的数据有1/3都在PageCache中，所以最大堆内存不要超过服务器内存的一半，剩下的给OS使用。

最大堆内存不要超过32G（为了保险，可以设置30G）

最大堆内存一旦超过32G，JVM就会禁用指针压缩技术，这个时候，可能需要40-50G的内存才可以达到原先32G的效果，所以最大堆内存不要超过32G。32G是一个估算值，有些时候，可能不到32G就已经禁用了指针压缩技术，所以为了保险，最大堆内存可以设置30G。

垃圾收集器选用G1

对于大内存来说，G1比CMS给力，所以可以采用G1垃圾收集器，还需要调整两个参数，如果G1清理失败了，会转为单线程垃圾收集，这就太恐怖了，而G1默认的InitiatingHeapOccupancyPercent设置太乐观了，可能导致清理失败，所以需要适当降低InitiatingHeapOccupancyPercent。

-XX:G1HeapRegionSize=16m
-XX:InitiatingHeapOccupancyPercent=30
复制代码

应用配置

调整刷写频率

将文档写入Elasticsearch，会先写到buffer中，然后定时将buffer中的数据刷写到segment中，默认是1秒，可以适当调高此配置，当然buffer写满了，也会刷写到segment，但是大部分场景下，都是满足了时间的条件才触写刷新的。

配置项如下：

index.refresh_interval //默认是1秒，可以适当调高此配置
indices.memory.index_buffer_size //既可以配置字节数，又可以配置比例，这个参数是节点内所有分片共享的
复制代码

写translog改为异步形式

translog是用来保证数据不丢失的，类似于MySQL的binlog，默认写translog是同步的，可以改为异步的形式。

配置项如下：

index.translog.durability: async //默认是request
index.translog.sync_interval: 60s
复制代码

使用

尽可能使用系统自动生成的Id

如果不使用系统自动生成的Id，Elasticsearch会检查给定的Id是否重复，从而产生IO，如果可以的话，尽可能使用系统自动生成的Id。

批量写入

经验值是一次性写入5000到10000条数据。

以前我一直觉得批量写入几乎只有在数据迁移的时候才可能实现，平时几乎都是单条写入的，其实如果业务允许，可以先将请求用MQ中转下，Consumer消费MQ数据，将数据放入阻塞队列，另外一个线程用Google Guava提供的方法批量从阻塞队列中获取数据，最终批量写入Elasticsearch。

示例代码如下：

当然这样就增加代码的复杂度了，还要处理各种的异常场景，我这里仅仅是突然想到一个方法，和大家分享下。

mapping

字段越少越好，合适的数据类型

使用Keyword类型

对于等值查询而言，keyword比数值类型性能更好，所以如果不需要范围查询，可以使用Keyword类型。不需要分词的文本，最好使用keyword，不然既影响写入性能，又占用空间。

如果不需要被索引，设置index为no

有不需要进行搜索的字段，可以设置其不需要索引，不然既影响写入性能，又占用空间。

如果不需要聚合、排序，设置doc_values为false

Doc values是基于列式存储的结构，聚合、排序非常高效，默认开启，占用空间。

扁平化（尽可能避免nested、parent-child）

尽可能避免nested、parent-child，不然既影响写入性能，又影响查询性能。

如果一个字段不需要算分，可以关闭Norms

如果当前字段不需要计算评分，设置false可以节省大量的磁盘空间，有助于提升性能。

不要使用Dynamic Mapping

如果使用Dynamic Mapping，那默认情况下，所有字段都是需要被索引的，而且都会创建doc_values，这肯定不是我们希望的，所以不要使用Dynamic Mapping，要自己严格定义mapping。

不要对text类型的字段进行排序

预索引

商品价格区间的搜索，比如可以查看价格100-200的商品，200-500的商品，500-1000的商品，那索引中必然含有price字段，我们可以通过范围查询搜索出对应的商品，但是范围查询的性能必然没有等值查询好，那我们可以在索引中再加一个字段：price_type（当price为100-200，price_type=1，当price为200-500，price_type=2，以此类推），这样我们就可以使用等值查询了。

查询某个月的数据，那索引中必然含有time字段，我们可以通过范围查询搜索出对应的数据，如果我们加一个month字段（yyyyMM），就可以采用等值查询了。

使用索引模板，对数据进行分片

相当于MySQL的分库分表，但是更加方便，只要定义一个模板，推送的数据满足相应的条件，就可以自动将索引创建出来。

避免深度分页，使用scroll和search_after分页

HBase和Elasticsearch搭配更香

Elasticsearch严重依赖PageCache，最好不要把太多字段放入Elasticsearch，会占用大量PageCache，查询会走到硬盘，严重影响查询性能，可以把核心字段、条件字段放Elasticsearch，其余数据放到HBase，通过_id去HBase查询更为明细的数据，如果HBase不可用，再查询MySQL，提高可用性。