Elasticsearch 调优实战（一）

❝

大家好呀，我是小羊，如果大家喜欢我的文章的话😁，就关注我一起学习进步吧~

❞

1.简单说两句

Elasticsearch想必大家都知道，它是一个分布式、RESTful 风格的搜索和数据分析引擎,在互联网，教育，医疗，电商行业都有广泛的应用，最近我也在做elasticsearch，对于调优方面有一些心得体会，抛砖引玉分享一下。

2.安装部署

如果学习或者调试可以把Elasticsearch 部署在 windows 或者 Mac 上面，但是生产环境一般都是部署在Linux上面，我们是部署在centos7 上面，并且进行了一些对 linux进行了一些配置

「ulimit」

ulimit 是linux 进程限制数量，因为es在运行的过程中会进行频繁的io 读写，所以 ulimit 太小会影响到 es 的性能，这里可以看下官方的说明，推荐我们把它调整到 65535。

「Disable swapping」

linux 下的 swap 类似于虚拟内存，如果开启了swap, 系统会在内存不够用的时候，拿一些硬盘资源当成内存使用，如果对于内存比较小的机器，这个还是有一些用的，但是它也有缺点，因为硬盘的速度是远远比不上内存的。所以它会影响整体的性能，对于生产环境的机器，内存一般比较大，所以关闭swap是比较好的一个选择，官方也是推荐关闭。

「persistent limits」

persistent limits 是文件打开数量限制，和ulimit一样，es 要进行频繁的io 读写，所以把数量调整大一点对es 性能有一些帮助。官方这边是推荐调整为 65535

「机器内存选择」

es 底层是使用 lucene 来实现的，lucene 的核心技术就是倒排索引，倒排索引通俗的讲，就是将存储的文本分割成不同词组，然后把词组存储到内存中，并和存储的文本关联，查找的时候，如果找到了文字，再根据关联关系，找到存储的文本。所以，内存越大，内存存储的单词就越多，查询的也就越快。所以一般的生产机器的内存需要比较大的内存。比如32g 64g 等。linux 内存可以分2部分，一半给 es jvm 内存使用，另外一半给 lucene 和系统使用，注意，jvm 内存不要超过32g,JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术.如果超过了 32g,jvm 就不再使用内存对象指针压缩了，会造成一些内存浪费，可以用这些内存多增加几个es 节点。更能提升es 集群的性能

3.索引设计

索引 index 是 es 的核心，它是我们查询的基本单元，它有点像是我们mysql 中的表 table,里面存储的是一个个文档，分布式场景下，文档分别存储在各个节点上面，如果配置了副本，每个节点还保存了一定的副本数据，因为数据分散，每个节点都可以进行写入和查询，所以es 的性能很好，但是如果索引设计不好，查询也比较慢。要想查询快，索引的设计非常重要。

我这边以订单索引举例来说明一下索引的设计。

「尽量少的字段」

前面也说了，索引的数据会保存到内存中，尽量少的字段可以更好的使用内存，查询起来也更快。

「大宽表存储数据」

因为es 是不好做 join 操作的，这点和mysql 有很大区别，比如mysql 有2张表订单主表和订单用户表，2张表用订单id 一对一关联，最好是在导入es 的时候，就把整个数据join 关联好，合成一个索引存入到es 中。

「一对多关联」

如果是一对多关联，比如一个订单包含几个商品，订单可以建一个索引，订单商品建一个索引，如果想要查询包含某个商品的订单时，先搜索订单商品索引，再根据订单商品搜索订单。比如像下面这种。

还有一种情况下需要使用订单的字段和订单商品的字段进行搜索，一般有2种做法：

把订单索引的字段冗余到订单商品索引上，这样可以直接查询订单商品索引就可以了。
使用嵌套或者父子文档方式把关联的订单商品文档存储到订单索引上。这样也可以进行一对多关联。

「字段类型设计」

和mysql 类似，es 也有很多字段类型给我们使用，对于不同的场景可以使用不同的类型来存储。

一级分类	二级分类	具体类型
核心类型	字符串类型	string,text,keyword
h	整数类型	integer,long,short,byte
h	浮点类型	double,float,half_float,scaled_float
h	逻辑类型	boolean
h	日期类型	date
h	范围类型	range
h	二进制类型	binary
f	数组类型	array
f	嵌套类型	nested
f	对象类型	object
d	地理坐标类型	geo_point
d	地理地图	geo_shape
特殊类型	IP类型	ip

如果是时间字段，比如创建时间，可以使用 date 类型，对于金额字段可以使用 dubbo 字段，对于文字类型，如果不需要分词，直接使用keyword ，对于要分词的，使用text. 数字类型的，可以使用integer 或者 long , 如果数字字段精确查询较多，范围查询较少，还是用keyword 查询更快。

「文档拆分和冷热分离」如果一个索引数据量比较大的话，查询也会很慢，就拿订单来说，近期的数据查询较多，丽现在比较久的数据查询比较少，如果所有订单存在一个索引里面，有点浪费，可以设计为按每个月或者每个季度创建一个索引，然后使用别名查询，类似2023年10月索引order_2023-10 ，索引别名 order_ 来查询所有的订单，比较久的订单索引比如 order_2020-10 就可以把索引修改为冷数据，提升整体集群的查询性能。

「动态映射字段修改为严格」

PUT /order_2023-10/_mappings
{
    "dynamic": "strict"
}

动态映射字段的的作用是，如果向es 中新加入一个未知的字段，es 会自动判断字段类型，并设置一个类型保存，如果自动判断的类型错误了，es 是不能修改字段类型的，只能重建索引，非常的麻烦和耗时，所以还是关闭笔记好，新增的字段先手动设置类型，然后再写入。而且我这边测试，关闭动态映射字段，es 索引占用的磁盘大小减少了很多，也能减少磁盘的使用。

今天的分享先到这里了，后面的文章再分享一下es查询方面的优化.

喜欢我的话，可以给我点个赞呀。