前言: 了解 ES 的索引管理方法有助于扬长避短,更好的利用 ES 的强大功能,特别是当遇到性能问题时,原因通常都可回溯至数据的索引方式以及集群中的分片数量。如果未能在一开始做出最佳选择,随着数据量越来越大,便有可能会引发性能问题。集群中的数据越多,要纠正这一问题就越难,本文旨在帮助大家了解 ES 容量管理的方法,在一开始就管理好索引的容量,避免给后面留坑。
为什么要做容量管理
- 在生产环境使用 ES 要面对的第一个问题通常是索引容量的规划,不合理的分片数,副本数和分片大小会对索引的性能产生直接的影响。
- Elasticsearch 中的每个索引都由一个或多个分片组成的,每个分片都是一个 Lucene 索引实例,您可以将其视作一个独立的搜索引擎,它能够对 Elasticsearch 集群中的数据子集进行索引并处理相关查询。
- 查询和写入的性能与索引的大小是正相关的,所以要保证高性能,一定要限制索引的大小,具体来说是限制分片数量和单个分片的大小。
- 分片和索引的大小太大和太多容易导致性能问题。
注意: ES 官方推荐分片的大小是 20G - 40G,最大不能超过 50G。
如何管理ES的容量
在介绍了为何要管理ES的容量后,我们接下来需要考虑的是如何进行管理,以下为通常的做法。
1. 使用在索引名称上带上时间的方法管理索引
例如: <logs-{now{yyyyMMddHH|+08:00}}-000001>
需要注意的是,在使用HTTP接口创建索引时,索引名称要进行urlencode编码:
1.1写入和查询索引
|
|
1.2时间索引的缺点
注意: 虽然使用带时间的索引可以带来很多方便,但是在实际过程中使用带时间的索引也有一定的缺陷。
- 对于写入之后需要数据变更的不是用时间索引
- 直接使用时间分割也可能存在某段时间数据量集中,导致索引分片超过设计容量的问题,可能影响性能
- 索引维护起来比较麻烦(当然可以使用template进行管理,前提是满足业务需求)
2. 使用 Rollover 管理索引
Rollover 的原理是使用一个别名指向真正的索引,当指向的索引满足一定条件(文档数或时间或索引大小)更新实际指向的索引。
2.1创建索引
|
|
2.2通过别名写入数据
这里使用bulk
接口进行写入数据
|
|
2.3执行 rollover 操作
给索引设置具体的rollover
条件,任意一个条件触发都会进行rollover:
下面我们给索引别名设置rollover规则为
- 最大文档数为3
- 分片最大大小为5gb
- 文档最长时间7d
|
|
此时,我们已经设置了rollover规则,这个时候尝试继续写入.
|
|
2.4使用 Rollover 的缺点
- 必须对索引别名先进行
rollover
规则设置才可以进行自动roll - 对于开发者不够友好
3. 使用 ILM(Index Lifecycle Management ) 管理索引
ES 一直在索引管理这块进行优化迭代,从 6.7 版本推出了索引生命周期管理(Index Lifecycle Management ,简称 ILM) 机制,是目前官方提供的比较完善的索引管理方法。所谓 Lifecycle (生命周期) 是把索引定义了四个阶段:
Hot
: 索引可写入,也可查询,也就是我们通常说的热数据,为保证性能数据通常都是在内存中的Warm
: 索引不可写入,但可查询,介于热和冷之间,数据可以是全内存的,也可以是在 SSD 的硬盘上的Cold
: 索引不可写入,但很少被查询,查询的慢点也可接受,基本不再使用的数据,数据通常在大容量的磁盘上Delete
: 索引可被安全的删除
这 4 个阶段是 ES 定义的一个索引从生到死的过程,Hot -> Warm -> Cold -> Delete 4 个阶段只有 Hot 阶段是必须的,其他 3 个阶段根据业务的需求可选。
3.1简历Lifecycle策略
如图,只启用了Hot
阶段,并且设置了rollover规则。
对应的HTTP请求参数如下:
|
|
4.2建立索引模板
|
|
注意:
- 模板匹配以索引前缀开头的索引(myindex-)
- 使用此模板的索引会自动创建
myindex_write_alias
的别名,方便数据检索 - 模版绑定了上面创建的 Lifecycle 策略,并且用于 rollover 的别名是
myindex_write_alias
4.3创建索引
|
|
4.4查看索引配置
|
|
4.5写入数据
|
|
4.6配置 Lifecycle 自动 Rollover 的时间间隔
由于ElasticSearch并不是一个realtime的的系统,因此很多操作并不能及时生效,因此需要在lifecycle中设置时间间隔。而ElasticSearch中默认的ILM
策略的时间间隔为10min。
|
|