让 Elasticsearch 飞起来!——功用优化实践干货

0、题记

Elasticsearch功用优化的终究意图：用户体会爽。

关于爽的界说——闻名产品人梁宁从前说过“人在满意时分的状况叫做愉悦，人不被满意就会难过，就会开端寻求。假如这个人在寻求中，能马上得到即时满意，这种感觉便是爽！”。

Elasticsearch的爽点便是：快、准、全!

关于Elasticsearch功用优化，阿里、腾讯、京东、携程、滴滴、58等都有过许多深化的实践总结，都对错常好的参阅。本文换一个思路，依据Elasticsearch的爽点，进行功用优化相关讨论。

1、集群规划优化实践

1.1 依据方针数据量规划集群

在事务初期，常常被问到的问题，要几个节点的集群，内存、CPU要多大，要不要SSD？

最主要的考虑点是：你的方针存储数据量是多大？能够针对方针数据量反推节点多少。

1.2 要留出容量Buffer

留意：Elasticsearch有三个警戒水位线，磁盘运用率到达85%、90%、95%。

不同警戒水位线会有不同的应急处理战略。

这点，磁盘容量选型中要规划在内。操控在85%之下是合理的。

当然，也能够经过装备做调整。

1.3 ES集群各节点尽量不要和其他事务功用复用一台机器。

除非内存十分大。

举例：一般服务器，安装了ES+Mysql+redis，事务数据量大了之后，必然会呈现内存缺乏等问题。

1.4 磁盘尽量挑选SSD

Elasticsearch官方文档必定引荐SSD，考虑到本钱的原因。需求结合事务场景，假如事务对写入、检索速率有较高的速率要求，主张运用SSD磁盘。

阿里的事务场景，SSD磁盘比机械硬盘的速率提高了5倍。但要因事务场景而异。

1.5 内存装备要合理

官方主张：堆内存的巨细是官方主张是：Min（32GB，机器内存巨细/2）。

Medcl和wood大叔都有清晰说过，不必要设置32/31GB那么大，主张：热数据设置：26GB，冷数据：31GB。

整体内存巨细没有具体要求，但必定是内容越大，检索功用越好。

经验值供参阅：每天200GB+增量数据的事务场景，服务器至少要64GB内存。除了JVM之外的预留内存要满足，不然也会常常OOM。

1.6 CPU核数不要太小

CPU核数是和ESThread pool相关的。和写入、检索功用都有相关。

主张：16核+。

1.7 超很多级的事务场景，能够考虑跨集群检索

除非事务量级十分大，例如：滴滴、携程的PB+的事务场景，不然根本不太需求跨集群检索。

1.8 集群节点个数无需奇数

ES内部保护集群通讯，不是依据zookeeper的分发布置机制，所以，无需奇数。

可是discovery.zen.minimum_master_nodes的值要设置为：候选主节点的个数/2+1，才干有用防止脑裂。

1.9 节点类型优化分配

集群节点数：<=3，主张：全部节点的master：true， data：true。既是主节点也是路由节点。 集群节点数：>3, 依据事务场景需求，主张：逐渐独立出Master节点和协调/路由节点。

1.10 主张冷热数据别离

热数据存储SSD和一般前史数据存储机械磁盘，物理上进步检索功率。

2、索引优化实践

Mysql等联系型数据库要分库、分表。Elasticserach的话也要做好充沛的考虑。

2.1 设置多少个索引？

主张依据事务场景进行存储。

不同通道类型的数据要分索引存储。举例：知乎收集信息存储到知乎索引；APP收集信息存储到APP索引。

2.2 设置多少分片？

主张依据数据量衡量。

经验值：主张每个分片巨细不要超越30GB。

2.3 分片数设置？

主张依据集群节点的个数规划，分片个数主张>=集群节点的个数。

5节点的集群，5个分片就比较合理。

留意：除非reindex操作，分片数是不能够修正的。

2.4副本数设置？

除非你对体系的健壮性有反常高的要求，比方：银行体系。能够考虑2个副本以上。不然，1个副本满足。

留意：副本数是能够经过装备随时修正的。

2.5不要再在一个索引下创立多个type

即使你是5.X版别，考虑到未来版别晋级等后续的可扩展性。

主张：一个索引对应一个type。6.x默许对应_doc，5.x你就直接对应type一致为doc。

2.6 依照日期规划索引

跟着事务量的添加，单一索引和数据量激增给的对立凸显。依照日期规划索引是必然挑选。

优点1：能够完成前史数据秒删。很对前史索引delete即可。留意：一个索引的话需求凭借delete_by_query+force_merge操作，慢且删去不完全。

优点2：便于冷热数据分隔办理，检索最近几天的数据，直接物理上指定对应日期的索引，速度快的一逼！

操作参阅：模板运用+rollover API运用。

2.7 有必要运用别号

ES不像mysql方面的更改索引称号。运用别号便是一个相对灵敏的挑选。

3、数据模型优化实践

3.1 不要运用默许的Mapping

默许Mapping的字段类型是体系自动识别的。其间：string类型默许分红：text和keyword两种类型。假如你的事务中不需求分词、检索，仅需求准确匹配，仅设置为keyword即可。

依据事务需求挑选适宜的类型，有利于节约空间和提高精度，如：浮点型的挑选。

3.2 Mapping各字段的选型流程

3.3 挑选合理的分词器

常见的开源中文分词器包括：ik分词器、ansj分词器、hanlp分词器、结巴分词器、海量分词器、“ElasticSearch最全分词器比较及运用方法” 查找可检查比照作用。

假如挑选ik，主张运用ik_max_word。由于：粗粒度的分词成果根本包括细粒度ik_smart的成果。

3.4 date、long、仍是keyword

依据事务需求，假如需求依据时间轴做剖析，有必要date类型；假如仅需求秒级回来，主张运用keyword。

4、数据写入优化实践

4.1 要不要秒级呼应？

Elasticsearch近实时的实质是：最快1s写入的数据能够被查询到。

假如refresh_interval设置为1s，必然会发生很多的segment，检索功用会受到影响。

所以，非实时的场景能够调大，设置为30s，乃至-1。

4.2 削减副本，提高写入功用。

写入前，副本数设置为0，写入后，副本数设置为本来值。

4.3 能批量就不单条写入

批量接口为bulk，批量的巨细要结合行列的巨细，而行列巨细和线程池巨细、机器的cpu核数。

4.4 禁用swap

在Linux体系上，经过运转以下指令暂时禁用交流：

1sudo swapoff -a

5、检索聚合优化实战

5.1 禁用 wildcard含糊匹配

数据量级到达TB+乃至更高之后，wildcard在多字段组合的状况下很简单呈现卡死，乃至导致集群节点溃散宕机的状况。

后果不堪设想。

代替计划：

计划一：针对准确度要求高的计划:两套分词器结合，standard和ik结合，运用match_phrase检索。

计划二：针对准确度要求不高的代替计划：主张ik分词，经过match_phrase和slop结合查询。

5.2极小的概率运用match匹配

中文match匹配明显成果是不准确的。很大的事务场景会运用短语匹配“match_phrase”。

match_phrase结合合理的分词词典、词库，会使得查找成果准确度更高，防止噪音数据。

5.3 结合事务场景，很多运用filter过滤器

关于不需求运用核算相关度评分的场景，无疑filter缓存机制会使得检索更快。

举例：过滤某邮编号码。

5.4操控回来字段和成果

和mysql查询相同，事务开发中，select * 操作简直是不有必要的。

同理，ES中，_source 回来悉数字段也对错有必要的。

要经过_source 操控字段的回来，只回来事务相关的字段。

网页正文content，网页快照html_content相似字段的批量回来，或许便是事务上的规划缺点。

明显，摘要字段应该提早写入，而不是查询content后再截取处理。

5.5 分页深度查询和遍历

分页查询运用：from+size;
遍历运用：scroll；
并行遍历运用：scroll+slice。

酌量调集事务选型运用。

5.6 聚合Size的合理设置

聚合成果是不准确的。除非你设置size为2的32次幂-1，不然聚合的成果是取每个分片的Top size元素后归纳排序后的值。

实践事务场景要求准确反应成果的要留意。
尽量不要获取全量聚合成果——从事务层面取TopN聚合成果值对错常合理的。由于确实排序靠后的成果值含义不大。

5.7 聚合分页合理完成

聚合成果展现的时，必然面对聚合后分页的问题，而ES官方依据功用原因不支持聚合后分页。

假如需求聚合后分页，需求自开发完成。包括但不限于：

计划一：每次取聚合成果，拿到内存中分页回来。

计划二：scroll结合scroll after调集redis完成。

6、事务优化

让Elasticsearch做它拿手的作业，很明显，它更拿手依据倒排索引进行查找。

事务层面，用户想最快速度看到自己想要的成果，中心的“字段处理、格式化、标准化”等一堆操作，用户是不重视的。

为了让Elasticsearch更高效的检索，主张：

1）要做足“前戏”
字段抽取、倾向性剖析、分类/聚类、相关性断定放在写入ES之前的ETL阶段;

2）“睡服”产品司理
产品司理依据各种奇葩事务场景或许会提各种无理需求。

作为技术人员，要“告诉以情晓之以理”，给产品司了解说了解查找引擎的原理、Elasticsearch的原理，哪些能做，哪些真的“臣妾做不到”。

7、小结

实践事务开发中，公司一般要求又想马儿不吃草，又想马儿飞快跑。

关于Elasticsearch开发也是，硬件资源缺乏（cpu、内存、磁盘都爆满）简直没有办法提高功用的。

除了检索聚合，让Elasticsearch做N多相关、不相干的作业，然后得出结论“Elastic也就那样慢，没有想像的快”。

你脑海中是否也有相似的场景显现呢？

供给相对NB的硬件资源、做好前期的各种预备作业、让Elasticsearch轻装上阵，相信你的Elasticsearch也会飞起来！

引荐阅览：

• 1、阿里：https://elasticsearch.cn/article/6171
• 2、滴滴：http://t.cn/EUNLkNU
• 3、腾讯：http://t.cn/E4y9ylL
• 4、携程：https://elasticsearch.cn/article/6205
• 5、社区：https://elasticsearch.cn/article/6202
• 6、社区：https://elasticsearch.cn/article/708
• 7、社区：https://elasticsearch.cn/article/6202