ElasticSearch架构解析与最佳实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. Elasticsearch
架构解析与最佳实践
ElasticSearch Architecture Analysis and Best Practices
2. 目录
CONTENTS
1
背景概述
Elasticsearch Application Overview
2 内核原理
3 架构解析
4
5 最佳实践
Core Principle
Structure Analysis
Best practices
调优实战
Performance Tuning
3. 一、ElasticSearch应用概述
大规模数据如何检索？
当系统数据量上了10亿、100亿条的时候，我们在做系统架构需要考虑的问题：
• 用什么数据库好？(MySQL、Oracle、Postgre、MongoDB、Hbase…)
• 如何解决单点故障；(LVS、F5、A10、Zookeeper、MQ)
• 如何保证数据安全性；(热备、冷备、异地多活)
• 如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;)
• 如何解决统计分析问题；(离线、近实时)
4. 一、ElasticSearch应用概述
对于关系型数据，我们通常采用以下 对于Nosql数据库，以mongodb为例， 完全把数据放在内存中，当我们的数
方案去解决查询和写入瓶颈： 原理类似，解决要点： 据达到PB级别时：
1）通过主从备份解决数据安全性问题； 1）通过副本备份保证数据安全性； 1PB=1024T=1048576G
2）通过数据库代理中间件心跳监测， 2）通过节点竞选机制解决单点问题； 节点数=1048576/96=10922个
解决单点故障问题； 3）先从配置库检索分片信息，然后将 实际上，考虑到数据备份，节点数往
3）通过代理中间件将查询语句分发到 请求分发到各个节点，最后由路由节 往在2.5万台左右。
各个slave节点进行查询，并汇总结果 点合并汇总结果 成本高昂到无法接受！
传统方案
NoSql方案
内存方案
5. 一、ElasticSearch应用概述
ElasticSearch一站式解决！
如果有数百万的文档需要通过关键词进行定位时，ElasticSearch肯定是最佳选择；
如果文档是JSON的，也可以把ElasticSearch当作一种“NoSQL数据库”， 应用
ElasticSearch数据聚合分析（aggregation）的特性，针对数据进行多维度的分析。
但不支持事务！
6. 一、ElasticSearch应用概述
ElasticSeach核心是从做搜索引擎开始，到现在主攻大数据分析领域，逐步进化成了一个全能型的数据产品，在es诸多优
秀的功能中，与很多数据产品有越来越多的交叉竞争。
① ES源于Lucene，但完美封装了Lucene核心库，引入分片与副本机制，
直接解决了集群下性能与高可用问题。
② RDBMS数据量超过百万级千万级之后性能下降厉害，但ES查询性能
高效稳定（本质上B+树算法不如倒排索引算法高效）
③ RDBMS聚合（求sum/avg/count等）性能较低，数据量到百万级、聚
合列增多耗时越长，但ES很聚合分析表现更好些。
④ 与文档型数据库Mongo相比，ES的文档查询与聚合性能更强，集群
分片副本的架构设计更优，虽然Mongo支持事务但一般都不会使用
MongoDB做事务开发。
⑤ ClickHouse主要是查询分析型DB，上亿级的聚合分析时要更强于ES。
7. 二、Lucene内核原理
1 ElasticSearch的起源
2000年，伦敦一个叫Shay Banon的待就业工程师，他的妻
子想学习做一名厨师，于是他基于Lucene的早期版本为自
己的妻子开发一个方便搜索菜谱的应用。
但直接上手Lucene难用且坑多，于是他基于Lucene封装出
来第一版开源搜索产品Compass（指南针）。
Shay后来找到了一份新工作，是在一个高性能分布式的开
发环境中，触发灵感重写Compass，将它从一个库打造成
了一个独立的server，并改名为Elasticsearch。
2010年2月，Elasticsearch发布的第一个版本，过去的10年
从1.0发展到最新的7.7.0版本，更新非常快，虽然对一些高
级特性做了商业化包装，但ES承诺永远开源且免费的。
Elasticsearch作者：Shay Banon
8. 二、Lucene内核原理
Elasticsearch集群中的
一个数据节点
2 Elasticsearch数据分层结构
Cluster=>Node=>Index=> Shard=>Segment=>Inverted Index
Mysql
Elasticsearch Node-01
Segment1
倒排表
Segment2
Shard01
……
倒排表
Index-01
索引库中的一个index
Index-02
Index-03
……
index
中的
一个
分片
Shard
02
Shard
03
……
Elasticsearch
database index
table type
row document
schema mapping
index everything is
index
select * GET http://
update * PUT http://
注意：7.X版本支持一个type，
8.x版本将废弃type，从这个
角度来看index将等同于
Mysql中的表。
9. 二、Lucene内核原理
3 Lucene构建index原理——新增文档
doc1 home sales rise in July.
doc2 increase in home sales in July.
新增文档步骤
新增文档时，doc经过Analyzer分词器分词之后，我们
可以得到词(term)和文档ID的对应列表。
然后对这些词集进行一次排序，然后合并相同的词
并统计出现频率，以及记录出现的文档ID，得到倒
排索引（与正排相反）。由于不是通过一条数据记
录来确定属性值，而是由属性值来确定记录的位置，
因而称为倒排索引(inverted index)。
词典文件不仅保存有每个关键词，还保留了指向频
率文件和位置文件的指针，通过指针可以找到该关
键字的频率信息和位置信息。
•
•
•
词典文件（Term Dictionary）
频率文件(frequencies)
位置文件 (positions)
索引时，拿到单词先对词典二元查找、找到该词，
通过指向频率文件的指针读出所有文章号，然后返
回结果。词典通常非常小，整个过程是毫秒级的。
10. 二、Lucene内核原理
3 Lucene构建index原理——segment段
Commit point
已提交落盘的segment段
段不可变
近实时
搜索
分片由多个segment段组成，每个段都是一个独立的倒排索引集，且具有不变性；
Segment段不可变=>则不需要锁，且不需要更新，但也是由于不可变性导致增删改都需要新建段文件。
新增文档首先写入文件系统缓存（高效），默认每秒refresh成新增段（不落盘），变成可搜索的状态。
删除文档在旧段中也不会删除，只是放在.del文件中在查询时被过滤掉。
更新文档时，旧版本的文档在.del 文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依
然能匹配查询，但是会在结果中被过滤掉。
11. 二、Lucene内核原理
3 Lucene构建index原理——持久化变更
1、新的文档被添加
到内存缓冲区并且
被追加到了translog
事务日志。 2、刷新（refresh）
完成后, 缓存被清空
但是事务日志不会。
4、在刷新（flush）
之后，段被全量
提交，并且事务
日志被清空。 3、更多的文档被添
加到内存缓冲区和
追加到事务日志。
分片每30分钟被自动刷新（flush），或者在 translog 太大的时候也会flush！
12. 二、Lucene内核原理
3 Lucene构建index原理——段合并
自动refresh每秒会创建一个新段 ，导致短时间内的段数量暴增。每个搜索请求都必须轮流检查每个段，所
以段越多，搜索也就越慢，Elasticsearch会在后台进行段合并来解决这个问题，主动将这些零散的 segment 做
数据归并，尽量让索引内只保有少量的、每个都比较大的segment 文件。
Fig:两个提交了的段和一个未提交的段正在被合并到一个更大的段
Fig：一旦合并结束，老的段被删除
13. 二、Lucene内核原理
4 Lucene与Mysql内核比较
Mysql和lucene都会在内存维护热数据，提高查询效率；
Mysql更新数据时会同步更新内存和磁盘文件，而Lucene
靠“新开段文件”来维护新数据，保证搜索优先。
Mysql通过undo、redo以及binlog日志来保证高可用，
lucene也会通过translog日志来确保数据安全。
Mysql维护复杂的日志文件提供了强大事务功能，Lucene
Mysql
的日志仅做灾备恢复，功能简单不支持事务。
Lucene
14. 三、Elasticsearch集群架构解析
1 ES基础概念
lucene：就是一个jar包，里面包含了封装好的各种操作倒排索引、搜索查询的代码。我们用java开发的时候，引入这
个jar，就可以基于lucene的api做CURD，lucene会在本地磁盘上面，组织索引的数据结构并提供搜索接口。但是如果直
接基于Lucene开发有什么问题呢？
如果采用分布式架构，用普通服务器来组成集群对外提供服务，索
引的数据如何均衡的落到各个节点上存储？查询数据时又如何从各
个节点上汇聚自己想要的结果呢？
如果采用集中式架构来封装
lucene提供搜索服务，那就需
要非常非常高的CPU、内存
和硬盘配置，比如支撑上亿
数据量的机器需要至少
16C320G的内存和3T磁盘，
单机成本负担不起。
分布式架构还会有经典的
CAP不可能三角问题，比如
分布式节点如何选举leader问
题，分布式环境各节点如何
协调通信？发生单点故障以
后如何保证服务的高可用和
数据灾备？
15. 三、Elasticsearch集群架构解析
1 ES基础概念
Elasticsearch 是一个分布式、RESTful 风格的搜索和数据分析引擎，支持对海量数据进行近实时（最低1s延迟）的处理。
可以作为一个大型分布式集群（数百台服务器）技术，处理PB级数据服务大公司；也可以运行在单机上，服务小公司。
自建分布式协调服务，抽离出独立的master节点服务，来管理元数据与集群健康。
引入Shard分片，将索引数据打散，存储于各个节点的分片之上，引入副本，解决容错、提高并发查询效率。
自动请求路由：任何一个节点接收到请求后，都可以把这个请求自动路由到相关分片上去处理该请求。
响应收集：最原始节点会从其他分片上接收响应数据，然后把这些数据返回给客户端。
Elasticsearch Cluster
data Master data
Data Data Data
Shard-1/1T Shard-2/1T Shard-3/1T
http
16. 三、Elasticsearch集群架构解析
1 ES基础概念
Master
Coordinating
Data
名词 解释
Cluster：集群 单个ES可以作为一个独立的服务。不过，为了处理大
型数据集、实现容错和高可用性，ES可以组合一个大
型集群来对外提供搜索服务。
Node：节点 形成集群的每个服务器称为节点。
Shard：分片 索引数据可以拆分为较小的分片，每个分片放到不同
的服务器上，提高并发能力。
Replia：副本 副本是一个基于分片级别（非节点）的精确复制，每
个分片可以有零个或多个副本。
主节点：负责集群中元数据管理，如索引的创建、删除、分片分配以及数据的Rebalance等，不负责数据的检索与聚
合，所以负载较轻。
协调节点：处理路由请求，搜索聚合以及分发批量索引请求等，客户端请求到的节点都可以充当协调节点角色，但
是在大型ES集群中一般会独立出协调节点角色。路由节点负载介于master与data之间！
数据节点：保存了数据分片，负责数据相关操作，比如分片的CRUD、搜索和整合等操作。数据节点上面执行的操
作都比较消耗CPU、内存和I/O，负载最高，因此数据节点服务器要选择较好的硬件配置。
17. 三、Elasticsearch集群架构解析
2 主节点配置与选举
Zookeeper
etcd Paxos ？
分布式系统要解决的第一个问题就是节点之间互相发现以及选主的机制，ES并未选择Zookeeper/Etcd 等成熟的服
务发现工具，也没有采用Paxos这样复杂的一致性算法，带来的好处是部署服务的成本和复杂度降低了，不用依赖
一个外部的服务发现集群，缺点当然是将复杂度带入了Elasticsearch 内部，需要自己实现。
node.master:true
node.data:false
discovery.zen.ping.unicast.hosts:["host1:port","host2:port","host3:port"]
discovery.zen.minimum_master_nodes:2
基于
6.X版本
前两个参数定义了该节点为master eligible（后选主节点）角色。
discovery.zen.ping.unicast.hosts配置项是所有节点的要填写主节点地址列表，当整个集群所有的node形成一个联通
图时，所有节点都可以知道集群中有哪些节点，不会形成孤岛。
discovery.zen.minimum_master_nodes，形成集群所需的最小主节点数目，也是选举中满足“多数”的quorum值。
注意：ES 7.x版本上述配置分别改为：discovery.seed_hosts，cluster.initial_master_nodes
18. 三、Elasticsearch集群架构解析
2 主节点配置与选举
ES集群采用的Bully算法来实现master的选举，不是像Zookeeper（paxos）等用投票来选主，而是通过一个规则，只
要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的。如果不对等，就说明
发生脑裂，这里再加一个限制“要求可用节点必须大于quorum”就可以解决！
节点启动后先向主节点列表发ping请求，Ping的response会包含该节点
的基本信息以及该节点认为的master节点。
选举开始，先从各节点认为的master中选，按照id的字典序排序，取第
一个。
如果对某个节点的投票数达到一定的quorum值（master eligible节点数
n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重
新选举。
对于brain split（脑裂）双主问题，需要把候选master节点最小值设置为
可以成为quorum（ master eligible节点数n/2+1 ）。
19. 三、Elasticsearch集群架构解析
3 ES写数据的流程
客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）；
coordinating node，根据docId对document进行路由，将请求转发给对应的node（primary shard）；
实际的node上的primary shard处理请求，然后将数据同步到replica node；
coordinating node，如果发现primary node和所有replica node都搞定之后，就返回响应结果给客户端；
路由公式：shard = hash(_routing) % (num_of_primary_shards)，其中_routing默认为docId，即文档id值
20. 三、Elasticsearch集群架构解析
3 ES搜索流程
搜索被执行成一个两阶段过程，称之为 Query Then Fetch；
在Query阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片），每个分片在本地执
行搜索并构建一个匹配文档的大小为 from + size 的优先队列。
每个分片返回各自优先队列中所有文档的ID和排序值给协调节点，协调节点合并这些值到自己的优
先队列中来产生一个全局排序后的结果列表。
在Fetch取回阶段，协调节点辨别出哪些文档需要被取回，并向相关分片（primary或replica分片随机选
择）提交多个GET请求，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果
给客户端。
Query阶段
Fetch阶段
21. 四、最佳实践
1 ES集群规划——资源规划
当前的数据量有多大？数据增长情况如何？
用于构建业务搜索需求，且垂直领域的搜索，数据量级几千万到数十亿级别，一般3-6台机器的规模。
用于大规模数据的实时OLAP（统计处理分析），如ELK Stack和BI等，数据规模可以达到千亿或更多，可能
需要几十到上百节点的规模。
机器配置如何？cpu、内存、硬盘容量等？
大多数的ES集群对于CPU要求都不高，一般2C~8C的配置都可以，具体CPU数根据业务场景来。
ES对内存要求高，主要不是吃JVM堆内存，而是OS cache，ES会尽量将频繁访问的磁盘文件的数据在操作系
统的内存中进行缓存。
ES JVM heap 最大设置到31G ，30G heap 大概能处理的数据量 10 T，其余都给系统缓存，标准的建议是分
50%的机器内存给JVM，剩余给OS cache，或可适当将OS cache比例上调。
磁盘容量的占用率要设置80%的警戒线，永远不要给ES使用Nas盘！
22. 四、最佳实践
1 ES集群规划——资源规划实战
通过数据量预估=》磁盘量预估
腾讯云在2019年4月的 meetup 分享中建议：磁盘容量大小 = 原始数据大小 * 3.38。假设一条文档数据1k，预计数据量
有10亿条，那么就有100G的原始数据大小，磁盘占用上可能就会有300多G的内容（存储倒排索引，行存和列存等）。
通过搜索吞吐率=》系统配置
Lucene引擎非常依赖底层的File System Cache，搜索如果需要达到 ms 级响应，那就需要有足够的内存去缓存大部分的
索引数据。
比如10亿级文档数，300G数据总量，假设用到5台数据服务器，8C64G，内存总量大小为300G，其中150G分给JVM堆
内存，剩余150G分给OS cache，操作系统用掉了50G大小，那么剩余100G的OS cache可以用于存储索引数据，大约会
有30%的概率是基于OS cache做磁盘索引文件的读写，平均响应差不多会在亚秒级~秒级。
23. 四、最佳实践
2 ES集群规划——角色规划
一个节点可以充当一个或多个角色，默认三个角色都有。
协调节点：凡是接收客户端请求处理的默认就是协调节点，如果集群负载较重，可以将协调节点单独抽取出来作为
独立角色。
小规模集群，不需严格区分。
中大规模集群（十个以上节点），应考虑单独的角色充当——一台服务器上只部署一个Node。如果并发查询量
大，聚合分析量大，可以再增加独立的协调节点。角色分开的好处是分工分开，不互影响。
Master
Node
Master
Node
node.master:true
Coordinating
Node
node.master:false
node.data:false
Data
Node
node.node:true
存储 低 低 极高
内存 低 中 高
计算 低 中 高
24. 四、最佳实践
3 ES集群规划——索引设计
索引设计十分关键，要根据业务场景来定，核心是要避免单个TB甚至PB级的索引，大索引一般要拆分
到GB级，比如海量日志场景可以采用 Template + Rollover + Curator 滚动创建索引，动态使用的效果如下：
index_2020-01-01
index_2020-01-02
index_2020-01-03
index_2020-01-04
index_2020-01-05
具体的操作就是：
在索引模板设计阶段，模板定义一个全局别名：用途是全局检索，比如index_all，每次更新
到新的索引后，新索引指向一个用于实时新数据写入的别名index_2020-01-05，同时将旧索
引的别名 index_2020-01-01 移除。然后再通过curator按照日期定期删除、归档历史数据。
25. 四、最佳实践
4 ES集群规划——分片与副本
Shard分片：一个index由多个shard组成，每个shard承载index的一部分数据（ES单分片的最大上线20亿doc数）。
index数据切分分片的主要好处如下，但是分片一旦创建，就不能改变大小！
水平分割/缩放内容量 。
跨分片（可能在多个节点上）分布和并行化操作，提高性能/吞吐量。
分片设计步骤
Master
Node
1、预估一下数据量的规模。一共要存储多久的数据，每天新增多少数据。
2、预估分多少个索引存储。
3、官方推荐Shard值在 20-40GB性能最好，日志类：单分片<50GB；搜索类：单分片<20GB
经验公式：分片数 = 索引大小/分片大小经验值 30GB
不足100G，可直接设置3-5个分片（结合节点数和扩展性），超过100G则可以按照如上经验公式来规划。
Replica副本设置：对于集群数据节点 >=2 的场景，建议副本至少设置为 1（一主一从，共两个副本），
可以提高集群容错和搜索吞吐量（副本分片可用于查询）。
26. 四、最佳实践
5 ES数据建模——Mapping模板
Mapping 是定义文档和字段的字段的存储和索引方式的过程（类似于Mysql里的表结构设计），一般会从
如下角度去设计与优化：
何种数据类型
只设置keyword
或关闭index no
关闭doc_values
列存储 no
"filed_name": {
"type": "keyword",
"doc_values": false
}
//默认开启，关闭无法进行agg运算
是否需全文检索
yes
"content": {
"analyzer": "ik_max_word",
"type": "text",
"fields": {
"keyword": {
"ignore_above": 256,
"type": "keyword"
}
}
}
同时设置text和
keyword两个属性
是否需要排序+聚合
是否需要行存储
根据业务场景关闭字段属性，可以节约存储，但也会牺
牲一些特性，后面要加回来只能通过ReIndex方式！
no
_source字段存储原
始doc，占比最大
{
"mappings": {
"my_type": {
"_source": {
"enabled": false
}
}
}
//默认开启，关闭_source后， update,
updatebyquery, reindex等接口无法使用。
27. 四、最佳实践
5 ES集群规划——Mapping模板设计
包含 Mapping 的 template 设计万能模板，已经在 7.2 验证 ok。
——《 Elasticsearch 索引设计实战指南》
"id": {
"available": {"type":
"type": "long"
"boolean"},
},
"type": "date",
"review": {
"title": {
"type": "keyword"
},
"type": "nested",
Master
Node
"properties": {
"nickname": {
"content": {
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-
dd||epoch_millis"
},
"expected_attendees": {
"type": "text"
"type": "integer_range"
"analyzer": "ik_max_word", }, },
"type": "text", "text": { "ip_addr": {
"fields": {
"type": "text"
"keyword": {
"ignore_above": 256,
},
"stars": { "suggest": {
"type": "integer"
}
}
"type": "ip"
},
"type": "keyword"
}
"publish_time": {
}
}
},
"type": "completion"
}
28. 四、最佳实践
6 ES开发及部署建议
ES的Java客户端主要有两大类，一类是基于TCP协议的transport客户端，一类是基于Http协议的rest客户端。
TransportClient 将会在7以后的版本中弃用，因此不推荐后续使用
High Level Rest Client ES官方的推出的高阶Rest Client，值得信赖，推荐！
Jest Java社区开发的，是Elasticsearch的Java Http Rest客户端，更新慢不推荐。
Spring Data Elasticsearch 主要是融入Spring生态对接，但底层是TransportClient，需注意。
bboss 国内维护的开源ES客户端，底层基于es restful api，目前有一定热度和用户基数。
ES的数据安全尤为重要，今年年发生多起ES数据裸奔等事件敲响了安全的警钟，对于公网部署ES集群服务，
需要注意如下事项：
防火墙上限制如下公共端口：9200（http端口）、9300（transport端口）、5601（kibana端口）；
将elasticsearch.yml中的配置更改为仅绑定到私有IP地址或将单个节点实例绑定到环回接口，如设置如下配置
network.bind_host: 127.0.0.1
高阶ES版本可以通过设置Elasticsearch数据的权限并控制对Kibana空间的访问。
较低的ES版本可以使用Nginx进行身份验证和SSL / TLS。
29. 五、性能调优
0 调优总原则
优化漏斗是一个调优过程中的分层漏斗，我们可以在每一层上执行相应的优化调整。总体来说，层级越靠
上，其调优的效果越明显，整体优化效果是自上而下衰减的。对操作系统层的优化很重要，但效果往往不
如想象得那么好，与应用程序层的优化效果相比，它是有很大差距的。
30. 五、性能调优
1 系统层调优
交换分区是性能杀手，需要关闭以防止内存置换降低性能。 将/etc/fstab 文件中包含swap的行注释掉。
[root@SHC~]# vi elasticsearch.yml
bootstrap.memory_lock : true
修改最大文件句柄数，默认单进程打开的最大句柄数是 1024。vi /etc/security/limits.conf 添加配置重启可生效：
[root@SHC~]# vi /etc/security/limits.conf
*
soft
nofile
1000000
*
hard
nofile
1000000
修改最大映射数量MMP，以便有足够的虚拟内存可用于 mmapped 文件。
sysctl -w vm.max_map_count=262144
磁盘层面，性能选择上的优先级是SSD>RAID0>本地磁盘，但是价格也是SSD>RAID0>本地磁盘，可按
照预算来申请，但千万不要使用Nas或者NFS等远程存储设备。单节点磁盘大小控制在2T内，超过这个
大小则建议对数据节点进行水平扩展！
31. 五、性能调优
2 JVM调优
JVM堆内存参数 -Xms 和 -Xmx 设置为相同的值，推荐设置为机器内存的一半左右，预留一半留给系统
cache使用。ES会使用多核大内存服务器，也需要优先使用G1作为垃圾回收器，提供系统吞吐和响应速度。
G1参数
描述 默认值 推荐值
XX:MaxGCPauseMillis=N 最大GC停顿时间。柔性目标，
JVM满足90%，不保证100%。 200 100，降低延迟
-XX:InitiatingHeapOccupancyPercent=n 当整个堆的空间使用百分比超
过这个值时，就会触发MixGC 45 50，提高吞吐
假设配置了8C32G的Elasticsearch服务器，推荐如下的JVM参数模板：
-Xms16g -Xmx16g -Xss1m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:InitiatingHeapOccupancyPercent=50
32. 五、性能调优
3 ES架构调优
当集群的节点数量较大时（比如超过10个节点），集群的管理和路由分发工作会变得很重，需要进行节点的
角色隔离，设置专门的master、coordinating和data节点，以免功能重叠相互影响，造成集群整体不稳定。
index的设计是避免出现过大的index（TB级别）,拆分索引可以缩小搜索的数据集范围。一般的拆分策略是按
照数据源拆分，或者为每个数据源建独立索引。
前面shard分片和副本设计已经做过最佳实践，大索引（超100G）的设计核心是控制大小在30G~50G，原则
上一个分片大小不要超过50个，分片越多，路由和合并就越复杂！副本可以提高容错和并发查询效率，但也
会占用磁盘空间，一般设置1~2个副本数即可！
对于日志类索引，可以设置过期删除策略，如只存近三天日志，过期索引直接进行物理删除，释放磁盘空间。
33. 五、性能调优
4 应用层调优——写入调优
1、flush调优：主要在translog的持久化策略上，默认对于每个写入请求都做一次flush，如果ES有大量的写请求会导致
频繁IO影响性能，在允许数据丢失情况（极低概率，断电或宕机等故障）可以调低translog的刷盘频率、提高落盘文
件的大小和周期、并改用异步方式来提升写的性能：
"translog": {
"sync_interval": “120s",
"durability": "async",
"flush_threshold_size":"1g“
"flush_threshold_period":"120m"
}
2、refresh_interval调优，默认情况下，ES每一秒会refresh一次，产生一个新的segment，这样会导致产生的
segment较多，segment merge较为频繁，系统开销增大。如果对数据的实时可见性要求较低，可以通过下面的命
令提高refresh的时间间隔，降低系统开销：
"refresh_interval": "30s"
当然，也可以将其设置为-1，临时关闭refresh，但是在数据导入完成后一定要把该值再改回来。
34. 五、性能调优
4 应用层调优——写入调优
3、merge并发控制，Lucene会不断地把一些小的segment合并成一个大的segment，合并时并发线程数默认值是
Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors()/2))，当节点配置的cpu核数较高时，merge占用的资源
可能会偏高，影响集群的性能，可以通过下面的命令调整某个index的merge过程的并发度：
"index.merge.scheduler.max_thread_count":2
4、bulk批量插入，客户端批量写入数据时尽量使用下面的bulk接口批量写入，提高写入效率。
POST _bulk
{"index": {"_index": "test","_type":"type1"}}
{"index": {"_index": "test","_type":"type1"}}
5、写入数据不指定_id，让ES自动产生，如果用户显示指定id写入数据时，ES会先发起查询来确定index中是否已经
有相同id的doc存在，若有则先删除原有doc再写入新doc，这样每次写入时，ES都会耗费一定的资源做查询。如果不
指定就直接跳过查询直接随机id入库，性能可快一倍。
35. 五、性能调优
4 应用层调优——查询调优
1、精确查找时，使用query-bool-filter组合取代普通query，可以不用计算相关性打分，避免算分类似于mysql里的=查
询，可提高查询效率：
#query - bool - filter加速查询
POST my_index/_search
#普通查询
{
"query": {
POST my_index/_search
"bool": {
{
"filter": {
"query": {
"term": {
"term": {
"user": "Kimchy"
"user": "Kimchy"
}
}
}
}
}
}
}
}
36. 五、性能调优
4 应用层调优——查询调优
2、避免深度翻页，如果要查询从from开始的size条数据，则需要在每个分片中查询打分排名在前面的 from + size 条
数据。协同节点收集每个分片的前 from + size 条数据。协同节点将收集到的 n * ( from + size ) 条数据合并起来再进
行一次排序，然后从 from+1 开始返回size条数据。页码越深，排序任务越重。如果业务上不可避免则需用scroll优化。
3、减少wildcard模糊匹配，它使用标准的 shell 模糊查询：? 匹配任意字符，* 匹配0个或多个字符，这种基于正则表
达式的模糊匹配常常导致CPU飙升，建议禁用！
4、使用日期字段搜索范围，日期字段设置为string类型也支持字典排序，但是采用原始的data日期格式，range排序效
率会更高。
5、如果需要考虑查询速度的优化，且排序字段基本固定，则可以考虑把 indexSort 配上，查询时会提前中断，大大
减少了需要扫描的数据量。
37. 五、性能调优
5 ELK海量日志平台的实战调优
Elasticsearch
FileBeat
基于Go的轻量级的日志
采集器，需在服务器启
动beat进程来扫描日志文
件发送到下游收集器。
Kafka cluster
数据流管道与缓冲区，
可支持海量数据的堆积，
防止上游生产速度过快
冲快下游消费者。
Logstash
基于JRuby开发的日志
处理器，运行于JVM之
上，可对日志进行筛选、
过滤和清洗。
Kibana
基于Node开发的日志
可视化查询工具，可制
作各种图表和dashboard，
便于OLAP。
38. 五、性能调优
4 ELK海量日志平台的实战调优
名词 优化点
Filebeat：文件采集器 1、运行在线上服务器，核心在控制beats对宿主机的cpu、内存使用率。
2、禁用压缩算法，节约CPU；关闭贪婪采集，只采集日志文件更新内容。
3、限制文件缓冲池对内存使用，池满则批量发送kafka。
Kafka：数据流缓冲池 1、独立部署的Kafka集群，划分物理内存的50%给jvm，剩余都给OS cache。
2、设置日志留存时间，3~5天有效期以节约磁盘内容。
3、设置0副本，设置分区数为broker节点数的2~3倍，提升系统并发吞吐量。
Logstash：日志过滤清洗器 1、运行在JVM上的，需设置好堆大小为物理内存一半。
2、对beats采集上报的日志字段进行实体抽取，删除无用字段节约空间。
3、开启批量线程提高消费速度。
Kibana：可视化展示工具 只需要设置最核心一点：开启X-pack登录认证，避免ES数据裸奔。
基于Kafka+ELK的海量日志平台中，最消耗资源、最核心的调优组件在Elasticsearch系统，需要从JVM、分片副本、
索引设计以及DSL查询优化上。
39. 五、性能调优
5 ELK海量日志平台的实战调优
ES调优层级
调优项目
JVM 1、数据节点全部采用G1回收器
2、分配一半的物理内存给堆内存，最大不超过31G
3、设置GC最大暂停时间不超过100ms，-XX:MaxGCPauseMillis=100
索引 1、基于日期建立index-*滚动索引，避免单个过大的索引
2、设计索引三天有效期，过期索引进行物理删除
3、单个索引大小控制在100~200G内，过大则进行索引拆分
分片和副本 1、分片数设计遵循两点：a.分片数与节点数保持一致，b.单个索引不超过30G
2、副本设置为1即可
Mapping模板 1、translog日志优化，改为120s异步刷盘模式
2、refresh_interval，改为30s刷新段，降低系统开销
3、数据字段优化，除搜索字段配置分词查询，其余string类型一律设置为keyword，关闭
所有文档的行存与列存。
DSL优化 1、编写自定义DSL查询语句
2、采用query-bool-filter组合取代普通query，先快速定位系统。
3、然后再基于message分词匹配查询
40. 五、性能调优
5 ELK海量日志平台的实战调优
等待调优前后的数据补充：
1、jvm gc频率，耗时对比
2、cpu、iops以及load等对比
3、查询响应耗时对比
4、kibana上监控指标中写入速度对比
41. 后续课程规划
Elasticsearch本期内容聚焦于Lucene原理、分布式架构设计以及集群建设，尤其花了较多的篇幅去讲述ES部署方案
和最佳实践，为什么要这样设计内容呢？原因在于Elasticsearch目前在后端生态体系中仍旧属于“中间件”的范畴，
ES不同于后端的数据层生态——比如Mysql、Hbase和Redis都会有专门的DBA来负责搭建和维护，其实ES也属于一
款“数据库”，提供了一站式数据存储和查询分析能力但却无DBA团队维护，中间件团队负责标装，运维负责部
署与维护，只有开发才能站在业务角度评估出需要多少机器和配置、给出集群部署方案、设计最佳索引模板，所
以对开发人员的要求更高，掌握此文的内容并不能称之熟练使用ES，后续大家可以关注如下方向！
倒排索引与分词
相关性评分
DSL与聚合
搜索优化
42. 参考&推荐文章列表
推荐阅读文章：
elastic.guide. 分片内部原理
Quintessence Anx. Elasticsearch Performance Tuning
进击的辣条. Elasticsearch由浅入深（二）ES基础分布式架构、横向扩容、容错机制
铭毅天下. Elasticsearch 索引设计实战指南
至尊宝.将 ELASTICSEARCH 写入速度优化到极限
腾讯云. Elasticsearch调优实践
Morningchen.腾讯技术工程. Elasticsearch调优实践
黄华.千台 ElasticSearch 集群在腾讯的优化实践
李海亮.Elasticsearch搜索引擎性能调优看懂这一篇就够了
Jolestar.Elasticsearch 架构以及源码概览
推荐Elasticsearch专栏：
Elastic官网. Elasticsearch权威指南
铭毅天下. 死磕 Elasticsearch 方法论认知清单
东天里的冬天. ElasticSearch教程——汇总篇
进击的辣条. ElasticSearch专栏