Elasticsearch究竟要设置多少分片数?

0、引言

本文翻译自Elasticsearch20170918热乎的官方博客,原作者:Christian Dahlqvist。 在构建Elasticsearch集群的初期如果集群分片设置不合理,可能在项目的中后期就会出现性能问题。

Elasticsearch是一个非常通用的平台,支持各种各样的用例,并且为数据组织和复制策略提供了巨大灵活性。这种灵活性使得作为ELK新手的你将数据组织成索引和分片变得困难。虽然不一定会在首次启动时出现问题,但由于数据量随时间的推移,可能会导致性能问题。集群所拥有的数据越多,纠正问题就越困难,甚至有时可能需要重新索引大量数据。

当我们遇到遭遇性能问题的用户时,可以追溯到关于数据索引的数据和群集数量的问题并不罕见。 对于涉及multi-tenancy或使用基于时间的索引的用户尤其如此。 在与用户讨论这个问题时(会议、论坛形式),引申出的一些最常见的问题是:

1)“我应该有多少个分片?”2)“我的分片应该有多大”?

这篇博客文章旨在帮助您回答这些问题,并为使用基于时间的索引的使用案例( 日志记录或安全分析 )提供实用的指导。

1、什么是分片?

在开始之前,让我们约定文章中用到的一些概念和术语。

Elasticsearch中的数据组织成索引。每一个索引由一个或多个分片组成。每个分片是Luncene索引的一个实例,你可以把实例理解成自管理的搜索引擎,用于在Elasticsearch集群中对一部分数据进行索引和处理查询。

【刷新】当数据写入分片时,它会定期地发布到磁盘上的新的不可变的Lucene段中,此时它可用于查询。——这被称为刷新。更详细的解读请参考: http://t.cn/R05e3YR

【合并】随着分段数(segment)的增长,这些segment被定期地整合到较大的segments。 这个过程被称为合并(merging)。

由于所有段都是不可变的, 因为新的合并段需要创建,旧的分段将被删除 ,这意味着所使用的磁盘空间通常在索引时会波动。 合并可能资源相当密集,特别是在磁盘I/O方面。

分片是Elasticsearch在集群周围分发数据的单位。 Elasticsearch在重新平衡数据时 (例如 发生故障后) 移动分片的速度 取决于分片的大小和数量以及网络和磁盘性能。

提示:避免有非常大的分片,因为大的分片可能会对集群从故障中恢复的能力产生负面影响。 对于多大的分片没有固定的限制,但是分片大小为50GB通常被界定为适用于各种用例的限制。

2、索引有效期( retention period )

由于段是不可变的,更新文档需要Elasticsearch首先查找现有文档,然后将其标记为已删除,并添加更新的版本。删除文档还需要找到文档并将其标记为已删除。因此,删除的文档将继续占据磁盘空间和一些系统资源,直到它们被合并,这将消耗大量的系统资源。

Elasticsearch允许从文件系统直接删除完整索引,而不必明确地必须单独删除所有记录。这是迄今为止从Elasticsearch删除数据的最有效的方式。

提示:尽可能使用基于时间的索引来管理数据。根据保留期(retention period,可以理解成有效期)将数据分组。基于时间的索引还可以轻松地随时间改变主分片和副本分片的数量(以为要生成的下一个索引进行更改)。这简化了适应不断变化的数据量和需求。3、索引和分片不是空闲的?

【集群状态】对于每个Elasticsearch索引,其映射和状态的信息都存储在集群状态。 这些集群状态信息保存在内存中以便快速访问。 因此,如果在集群中拥有大量索引,可能导致大的集群状态(特别是如果映射较大)。 所有更新集群状态操作为了在集群中保证一致性,需要通过单个线程完成,因此更新速度将变慢。

提示:为了减少索引数量并避免大的乃至非常庞大的映射,请考虑将相同索引结构的数据存储在相同的索引中,而不是基于数据的来源将数据分割成独立的索引。 在每个索引的索引数量和映射大小之间找到一个很好的平衡很重要。**

每个分片都有数据需要保存在内存中并使用堆空间。 这包括在分片级别保存信息的数据结构,也包括在段级别的数据结构,以便定义数据驻留在磁盘上的位置。 这些数据结构的大小不是固定的,并且将根据用例而有所不同。

然而,段相关开销的一个重要特征是它与分段的大小不成正比。 这意味着与较小的段相比,较大的段的每个数据量具有较少的开销,且这种差异很大。

【堆内存的重要性】为了能够每个节点存储尽可能多的数据,重要的是尽可能多地管理堆内存使用量并减少其开销。 节点拥有的堆空间越多,它可以处理的数据和分片越多。

因此,索引和分片从集群的角度看待不是空闲的,因为每个索引和分片都有一定程度的资源开销。

提示1:小分片会导致小分段(segment),从而增加开销。目的是保持平均分片大小在几GB和几十GB之间。对于具有基于时间的数据的用例,通常看到大小在20GB和40GB之间的分片。

提示2:由于每个分片的开销取决于分段数和大小,通过强制操作迫使较小的段合并成较大的段可以减少开销并提高查询性能。一旦没有更多的数据被写入索引,这应该是理想的。请注意,这是一个消耗资源的(昂贵的)操作,较为理想的处理时段应该在非高峰时段执行。

提示3:您可以在集群节点上保存的分片数量与您可用的堆内存大小成正比,但这在Elasticsearch中没有的固定限制。 一个很好的经验法则是:确保每个节点的分片数量保持在低于每1GB堆内存对应集群的分片在20-25之间。 因此,具有30GB堆内存的节点最多可以有600-750个分片,但是进一步低于此限制,您可以保持更好。 这通常会帮助群体保持处于健康状态。

4、分片的大小如何影响性能?

在Elasticsearch中,每个查询在每个分片的单个线程中执行。然而,可以并行处理多个分片,并可以在相同分片上执行多个查询和聚合。

【小分片的利弊】这意味着,在不涉及高速缓存时,最小查询延迟将取决于数据、查询的类型、分片的大小。查询大量小分片将使得每个分片的处理速度更快,但是随着更多的任务需要按顺序排队和处理,它不一定要比查询较小数量的更大的分片更快。如果有多个并发查询,则有很多小碎片也会降低查询吞吐量。

提示:从查询性能角度确定最大分片大小的最佳方法是使用逼真的数据和查询进行基准测试(真实数据而非模拟数据)。 始终使用查询和索引负载进行基准测试,代表节点在生产中需要处理的内容,因为单个查询的优化可能会产生误导性的结果。

5、如何管理分片大小?

当使用基于时间的索引时,每个索引传统上都与固定的时间段相关联。 每日索引非常普遍,经常用于持有时间区间短或每日量大的数据。 这些允许数据期限期间以良好的粒度进行管理,并且可以方便地对每天更换调整volumes。

时间周期长的数据,特别是如果每日不保存每天的索引数据,则通常会使用每周或每月的保存的碎片大小的增加。 这减少了随着时间的流逝需要存储在群集中的索引和碎片数量大小(直译有点费劲此处)。

提示:如果使用固定期限的时间索引数据,可以根据时间周期预期数据量调整所涵盖的时间范围,以达到目标分片大小。

【均匀更新&快速变化的索引数据对比】具有固定时间间隔的基于时间的索引在数据量合理预测并且变化缓慢的情况下工作良好。 如果索引率可以快速变化,则很难保持均匀的目标分片大小。

为了能够更好地处理这种情况,推出了RolloverShrink API。 这些增加了如何管理索引和分片的灵活性,尤其适用于基于时间的索引。

此处省略了 Rollover和Shrink API的介绍。(建议查询官网补齐概念再深入)

6、结论

这篇博客文章提供了有关如何在Elasticsearch中最好地管理数据的提示和实用指南。 如果您有兴趣了解更多,推荐阅读Google搜索 “Elasticsearch: the definitive guide” (有点旧,值得阅读)。

然而,关于如何最好地在索引和分片上分发数据的许多决策将取决于用例细节,有时可能难以确定如何最佳地应用可用的建议。

文章提及的几个核心建议清单如下,以回答文章开头的提问。

1) “我应该有多少个分片? ” 答: 每个节点的分片数量保持在低于每1GB堆内存对应集群的分片在20-25之间。 2) “我的分片应该有多大”? 答:分片大小为50GB通常被界定为适用于各种用例的限制。

还是读起来有点拗口,一些概念还是不够深入,不能很好的深入浅出的讲解。 待我实践中更新吧。更多细节,欢迎讨论!

原文发布于微信公众号 - 铭毅天下(gh_0475cf887cf7)

原文发表时间:2017-09-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

insert into太慢?Roger 带你找真凶

李真旭(Roger) ACOUG 核心专家,Oracle ACE,云和恩墨技术专家 编辑手记:昨天谈到索引并不是万能的,事实上很多无用的索引给数据库带来很大的维...

4394
来自专栏李俊飞的专栏

数据库性能评测:整体性能对比

随着版本升级,关系型数据库和缓存数据库整体性能比之前都有大幅度的提升,衡量数据库性能的三个重要指标是:数据库吞吐量(QPS)、延迟时长(Latency)和稳定性...

2.9K0
来自专栏实用工具入门教程

如何部署 MediaWiki

MediaWiki是一个流行的免费wiki软件包。它与维基百科使用的软件相同,是完全动态的,可以在LAMP堆栈上运行,利用PHP语言和MySQL数据库后端。通过...

2892
来自专栏农夫安全

一次比较简单的手工ASP注入

前言 这是一个比较新手中的新手注入。这是之前群里一个朋友丢给我的站点,说有注入点,但是他手上没有工具,他知道我有工具就叫我帮忙看一下。 一般我有个习惯,进去先在...

8706
来自专栏性能与架构

又拍网数据库架构案例分析

这篇文章是对又拍网公布的数据库案例的分析总结 又拍网是一个大型照片分享社区,数据库架构也是从简单到复杂发展起来的 数据库进化过程 (1)一主一从 最初...

3046
来自专栏数据和云

不以规矩 不成方圆

我在多年以前写下的DBA四大守则,其中的一条是“不以规矩,不成方圆”。任何一个企业的运维环境,都需要基本的规矩和准则,有所遵守、有所规范,才能保持长治久安,不出...

2813
来自专栏数据和云

终于来了,Percona发布XtraBackup for MySQL 8.0

Percona在9月12日,终于宣布第一个测试用的XtraBackup for MySQL 8.0版本给大家试用:

2003
来自专栏数据库新发现

Percona最新发布XtraBackup for MySQL 8.0

Percona在9月12日,终于宣布第一个测试用的XtraBackup for MySQL 8.0版本给大家试用:

1261
来自专栏「3306 Pai」社区

构建MySQL自动化平台思路

这里做个小预告,可能下周或者下下周。我的好基友顺子要给大家讲讲MHA的故事。请期待~~

1902
来自专栏架构师之路

数据库中间件TDDL调研笔记

前篇: 《数据库中间件cobar调研笔记》 13年底负责数据库中间件设计时的调研笔记,拿出来和大家分享,轻拍。 一,TDDL是什么 TDDL是Taobao Di...

5369

扫码关注云+社区

领取腾讯云代金券