ElasticSearch合理分配索引分片原理

Elasticsearch 是一个非常通用的平台,支持各种用户实例,并为组织数据和复制策略提供了极大的灵活性。但是,这种灵活性有时会使我们很难在早期确定如何很好地将数据组织成索引和分片,尤其是不熟悉 Elastic Stack。虽然不一定会在首次启动时引起问题,但随着数据量的增长,它们可能会导致性能问题。群集拥有的数据越多,纠正问题也越困难,因为有时可能需要重新索引大量数据。

因此,当我们遇到性能问题时,往往可以追溯到索引方式以及集群中分片的数量。那么就会遇到问题,我们应该有多少分片以及我的分片应该有多大。

一、什么是分片?

假如我们的集群的架构如下图:

集群(cluster): 由一个或多个节点组成, 并通过集群名称与其他集群进行区分

节点(node): 单个 ElasticSearch 实例. 通常一个节点运行在一个隔离的容器或虚拟机中

索引(index): 在 ES 中, 索引是一组文档的集合

分片(shard): 因为 ES 是个分布式的搜索引擎, 所以索引通常都会分解成不同部分, 而这些分布在不同节点的数据就是分片. ES自动管理和组织分片, 并在必要的时候对分片数据进行再平衡分配, 所以用户基本上不用担心分片的处理细节.

副本(replica): ES 默认为一个索引创建 5 个主分片, 并分别为其创建一个副本分片. 也就是说每个索引都由 5 个主分片成本, 而每个主分片都相应的有一个 copy。对于分布式搜索引擎来说, 分片及副本的分配将是高可用及快速搜索响应的设计核心.主分片与副本都能处理查询请求,它们的唯一区别在于只有主分片才能处理索引请求.副本对搜索性能非常重要,同时用户也可在任何时候添加或删除副本。额外的副本能给带来更大的容量, 更高的呑吐能力及更强的故障恢复能力。

如上图,有集群两个节点,并使用了默认的分片配置. ES自动把这5个主分片分配到2个节点上, 而它们分别对应的副本则在完全不同的节点上。其中 node1 有某个索引的分片1、2、3和副本分片4、5,node2 有该索引的分片4、5和副本分片1、2、3。

当数据被写入分片时,它会定期发布到磁盘上的不可变的 Lucene 分段中用于查询。随着分段数量的增长,这些分段会定期合并为更大的分段。 此过程称为合并。 由于所有分段都是不可变的,这意味着所使用的磁盘空间通常会在索引期间波动,因为需要在删除替换分段之前创建新的合并分段。 合并可能非常耗费资源,特别是在磁盘I / O方面。

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

注1:避免使用非常大的分片,因为这会对群集从故障中恢复的能力产生负面影响。 对分片的大小没有固定的限制,但是通常情况下很多场景限制在 50GB 的分片大小以内。

注2:当在ElasticSearch集群中配置好你的索引后, 你要明白在集群运行中你无法调整分片设置. 既便以后你发现需要调整分片数量, 你也只能新建创建并对数据进行重新索引(reindex)(虽然reindex会比较耗时, 但至少能保证你不会停机).
主分片的配置与硬盘分区很类似, 在对一块空的硬盘空间进行分区时, 会要求用户先进行数据备份, 然后配置新的分区, 最后把数据写到新的分区上。

注3:尽可能使用基于时间的索引来管理数据保留期。 根据保留期将数据分组到索引中。 基于时间的索引还可以轻松地随时间改变主分片和副本的数量,因为可以更改下一个要生成的索引。

二、索引和分片是否是空闲的

对于每个 Elasticsearch 索引,有关映射和状态的信息都存储在集群状态中。它保存在内存中以便快速访问。 因此,在群集中具有大量索引可能导致较大的群集状态,尤其是在映射较大的情况下。 这可能会变得很慢,因为所有更新都需要通过单个线程完成,以便在更改集群中分布之前保证一致性。
每个分片都有需要保存在内存中的数据并使用堆空间。 这包括在分片级别保存信息的数据结构,但也包括在分段级别的数据结构,以便定义数据驻留在磁盘上的位置。 这些数据结构的大小不固定,并且会根据使用场景不同而有所不同。然而,分段相关开销的一个重要特征是它与分段的大小不严格成比例。 这意味着与较小的分段相比,较大的分段每个数据量的开销较小。 差异可能很大。为了能够为每个节点存储尽可能多的数据,管理堆的使用并尽可能减少开销变得很重要。 节点拥有的堆空间越多,它可以处理的数据和分片就越多。
因此,索引和分片在集群视角下不是空闲的,因为每个索引和分片都存在一定程度的资源开销。

分配的每个分片都是有额外的成本的:

每个分片本质上就是一个Lucene索引, 因此会消耗相应的文件句柄, 内存和CPU资源

每个搜索请求会调度到索引的每个分片中. 如果分片分散在不同的节点倒是问题不太. 但当分片开始竞争相同的硬件资源时, 性能便会逐步下降

ES 使用词频统计来计算相关性. 当然这些统计也会分配到各个分片上。如果在大量分片上只维护了很少的数据, 则将导致最终的文档相关性较差。

注1:小的分片会造成小的分段,从而会增加开销。我们的目的是将平均分片大小控制在几 GB 到几十 GB 之间。对于基于时间的数据的使用场景来说,通常将分片大小控制在 20GB 到 40GB 之间。

注2:由于每个分片的开销取决于分段的数量和大小,因此通过 forcemerge 操作强制将较小的分段合并为较大的分段,这样可以减少开销并提高查询性能。 理想情况下,一旦不再向索引写入数据,就应该这样做。 请注意,这是一项比较耗费性能和开销的操作,因此应该在非高峰时段执行。

注3:我们可以在节点上保留的分片数量与可用的堆内存成正比,但 Elasticsearch 没有强制的固定限制。 一个好的经验法则是确保每个节点的分片数量低于每GB堆内存配置20到25个分片。 因此,具有30GB堆内存的节点应该具有最多600-750个分片,但是低于该限制可以使其保持更好。 这通常有助于集群保持健康。

注4:如果担心数据的快速增长, 建议根据这条限制: ElasticSearch推荐的最大JVM堆空间 是 30~32G, 所以把分片最大容量限制为 30GB, 然后再对分片数量做合理估算。例如, 如果的数据能达到 200GB, 则最多分配7到8个分片。

注5:如果是基于日期的索引需求, 并且对索引数据的搜索场景非常少. 也许这些索引量将达到成百上千, 但每个索引的数据量只有1GB甚至更小. 对于这种类似场景, 建议是只需要为索引分配1个分片。如果使用ES的默认配置(5个分片), 并且使用 Logstash 按天生成索引, 那么 6 个月下来, 拥有的分片数将达到 890 个. 再多的话, 你的集群将难以工作--除非提供了更多(例如15个或更多)的节点。想一下, 大部分的 Logstash 用户并不会频繁的进行搜索, 甚至每分钟都不会有一次查询. 所以这种场景, 推荐更为经济使用的设置. 在这种场景下, 搜索性能并不是第一要素, 所以并不需要很多副本。 维护单个副本用于数据冗余已经足够。不过数据被不断载入到内存的比例相应也会变高。如果索引只需要一个分片, 那么使用 Logstash 的配置可以在 3 节点的集群中维持运行 6 个月。当然你至少需要使用 4GB 的内存, 不过建议使用 8GB, 因为在多数据云平台中使用 8GB 内存会有明显的网速以及更少的资源共享.

三、分片大小如何影响性能

在Elasticsearch中,每个查询在每个分片的单个线程中执行。 但是,可以并行处理多个分片,对同一分片也可以进行多个查询和聚合。

这意味着,如果不涉及缓存,则最小查询延迟将取决于数据、查询类型以及分片的大小。 查询大量小的分片将使每个分片的处理速度更快,但是需要按顺序排队和处理更多的任务,它不一定比查询较少数量的较大分片更快。 如果存在多个并发查询,则拥有大量小分片也会降低查询吞吐量。
从查询性能角度确定最大分片大小的最佳方法是使用实际数据和查询进行基准测试。 始终以查询和加载索引的节点在生产中需要处理的内容基准,因为优化单个查询可能会产生误导性结果。

四、如何管理分片大小

当使用基于时间的索引时,通常每个索引都与固定的时间段相关联。 每天的索引非常常见,通常用于保存保留期短的或每日量大的数据。 这些允许以合适的粒度管理保留期,并且可以轻松调整日常基础量。 具有较长保留期的数据,特别是如果每日的量不能保证使用每天的索引,通常使用每周或每月的索引以保证分片大小。 这减少了随着时间的推移需要存储在集群中的索引和分片的数量。

注:如果使用基于时间的索引,这个时间是某个固定的时间段,那么需要根据数据的保留期限和预期的数据量来调整每个索引所覆盖的时间段,以达到目标分片的大小。也就是说,如果我们要确定最终分片的大小,则需要根据我们的数据保存的期限以及预估预期的数据量来调整我们索引需要按照天还是周还是月的时间来进行评估。
当数据量可以合理预测并且变化缓慢时,具有固定时间间隔的基于时间的索引很有效。 如果索引快速变化,则很难保持统一的目标分片大小。为了能够更好地处理这种类型的场景,引入了 Rollover and Shrink API  这些为索引和分片的管理方式增加了很多灵活性,特别是对于基于时间的索引。

Rollover and Shrink API 可以指定应包含的文档和索引的数量和/或应该向其写入最大期限的文档。 一旦超出其中一个标准,Elasticsearch 就可以触发创建新索引,无需停机即可完成写入。 可以切换到特定大小的新索引,而不是让每个索引覆盖特定的时间段,这使得可以更容易地为所有索引实现均匀的分片大小。如果需要更新数据,在使用此API时,事件的时间戳与其所处的索引之间不再存在明显的链接,这可能会使更新效率大大降低,因为每次更新都需要在搜索之前进行。

注:如果我们有基于时间的不可变数据,其中数据量可能会随时间发生显著变化,就可以考虑使用 Rollover API,通过动态更改每个索引所涵盖的时间段来实现最佳目标分片大小。 这提供了极大的灵活性,并且可以帮助避免在数据量不可预测时具有太大或太小的分片。

Shrink API 允许我们将现有索引缩小为具有较少主分片的新索引。 如果在索引期间需要跨节点均匀扩展分片,但这会导致分片太小,一旦索引不再被索引,此 API 可用于减少主分片的数量。 这将生成更大的分片,更适合长期存储数据。
如果需要让每个索引覆盖特定的时间段,并且希望能够在大量节点上扩展索引,请考虑使用 Shrink API 在索引不再编入索引时减少主分片的数量。 如果最初配置了太多分片,此 API 还可用于减少分片数量。

五、总结

关于如何在索引和分片之间最佳地分布数据,这将取决于所使用的场景的细节,有时很难确定如何最好地应用可用的建议。

数据分片也是要有相应资源消耗,并且需要持续投入。当索引拥有较多分片时, 为了组装查询结果, ES 必须单独查询每个分片(当然并行的方式)并对结果进行合并。所以高性能 IO 设备(SSDs)和多核处理器无疑对分片性能会有巨大帮助。尽管如此, 还是要多关心数据本身的大小,更新频率以及未来的状态。在分片分配上并没有绝对的答案。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • python elasticsearch从创建索引到写入数据的全过程

    python elasticsearch从创建索引到写入数据 创建索引 from elasticsearch import Elasticsearch es = Elasticsearch('192.168.1.1:9200') mappings = { "mappings": { "type_doc_test": { #type_doc_test为doc_type "properties": { "id": { "

  • Spring Boot集成ElasticSearch实现搜索引擎的示例

    Elastic Search是一个开源的,分布式,实时搜索和分析引擎.Spring Boot为Elasticsearch及Spring Data Elasticsearch提供的基于它的抽象提供了基本的配置.Spring Boot提供了一个用于聚集依赖的spring-boot-starter-data-elasticsearch 'StarterPOM'. ElasticSearch作为搜索引擎,我们需要解决2大问题: 1,  如何将被搜索的数据在ES上创建反向索引 2,  Java代码如何与E

  • django使用haystack调用Elasticsearch实现索引搜索

    前言: 在做一个商城项目的时候,需要实现商品搜索功能. 说到搜索,第一时间想到的是数据库的 select * from tb_sku where name like %苹果手机% 或者django的 SKU.objects.filter(name__contains="苹果手机") 但是,假如你的数据库有几千万条数据,name字段没有索引,可能查询需要十几分钟,用户可能会等你?那为什么不给name字段增加索引?商品表不仅仅是用来查询,也会经常修改数据,新增删除数据等.建立索引后,做增删

  • python Elasticsearch索引建立和数据的上传详解

    今天我想讲一讲关于Elasticsearch的索引建立,当然提前是你已经安装部署好Elasticsearch. ok,先来介绍一下Elaticsearch,它是一款基于lucene的实时分布式搜索和分析引擎,是后台系统,用来存储数据,检索数据,属于完全命令行交互. 那为什么选择python作为脚本进行命令的写入和数据的上传呢?那是因为Python里面有固定的模板,可以上传数据到Elasticsearch. 接下来就聊一聊该如何编写代码: 我们上传数据之后,数据到哪里去了呢? 存在索引里面了. 那

  • Spring Boot与Kotlin 整合全文搜索引擎Elasticsearch的示例代码

    Elasticsearch 在全文搜索里面基本是无敌的,在大数据里面也很有建树,完全可以当nosql(本来也是nosql)使用. 这篇文章简单介绍Spring Boot使用Kotlin语言连接操作 Elasticsearch.但是不会做很详细的介绍,如果要深入了解Elasticsearch在Java/kotlin中的使用,请参考我之前编写的<Elasticsearch Java API 手册> https://gitee.com/quanke/elasticsearch-java/ 里面包含使

  • 使用Python操作Elasticsearch数据索引的教程

    Elasticsearch是一个分布式.Restful的搜索及分析服务器,Apache Solr一样,它也是基于Lucence的索引服务器,但我认为Elasticsearch对比Solr的优点在于: 轻量级:安装启动方便,下载文件之后一条命令就可以启动: Schema free:可以向服务器提交任意结构的JSON对象,Solr中使用schema.xml指定了索引结构: 多索引文件支持:使用不同的index参数就能创建另一个索引文件,Solr中需要另行配置: 分布式:Solr Cloud的配置比较

  • ElasticSearch合理分配索引分片原理

    Elasticsearch 是一个非常通用的平台,支持各种用户实例,并为组织数据和复制策略提供了极大的灵活性.但是,这种灵活性有时会使我们很难在早期确定如何很好地将数据组织成索引和分片,尤其是不熟悉 Elastic Stack.虽然不一定会在首次启动时引起问题,但随着数据量的增长,它们可能会导致性能问题.群集拥有的数据越多,纠正问题也越困难,因为有时可能需要重新索引大量数据. 因此,当我们遇到性能问题时,往往可以追溯到索引方式以及集群中分片的数量.那么就会遇到问题,我们应该有多少分片以及我的分片

  • Elasticsearch Recovery索引分片分配详解

    目录 基础知识点 减少集群Full Restart造成的数据来回拷贝 减少主副本之间的数据复制 特大热索引为何恢复慢 其他Recovery相关的专家级设置 基础知识点 在Eleasticsearch中recovery指的就是一个索引的分片分配到另外一个节点的过程:一般在快照恢复.索引副本数变更.节点故障.节点重启时发生.由于master保存整个集群的状态信息,因此可以判断出哪些shard需要做再分配,以及分配到哪个结点,例如: 如果某个shard主分片在,副分片所在结点挂了,那么选择另外一个可用

  • MySQL数据库优化之索引实现原理与用法分析

    本文实例讲述了MySQL数据库优化之索引实现原理与用法.分享给大家供大家参考,具体如下: 索引 什么是索引 索引用来快速地寻找那些具有特定值的记录,所有MySQL索引都以B-树的形式保存.如果没有索引,执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录,直至找到符合要求的记录.表里面的记录数量越多,这个操作的代价就越高.如果作为搜索条件的列上已经创建了索引,MySQL无需扫描任何记录即可迅速得到目标记录所在的位置.如果表有1000个记录,通过索引查找记录至少要比顺序扫描记录快100倍.

  • 深入讲解MySQL Innodb索引的原理

    引言 回想四年前,我在学习mysql的索引这块的时候,老师在讲索引的时候,是像下面这么说的 索引就像一本书的目录.而当用户通过索引查找数据时,就好比用户通过目录查询某章节的某个知识点.这样就帮助用户有效地提高了查找速度.所以,使用索引可以有效地提高数据库系统的整体性能. 嗯,这么说其实也对.但是呢,大家看完这种说法,其实可能还是觉得太抽象了!因此呢,我还想再深入的细说一下,所以就有了此文! 需要说明的是,我说的内容只在Mysql的Innodb引擎中是成立的.在Sql Server.oracle.

  • 使用elasticsearch定时删除索引数据

    1.有的时候我们在使用ES 由于资源有限或业务需求,我们只想保存最近一段时间的数据,所以有必要做定时删除数据. 2.编写脚本 vim del_es_by_day.sh #!/bin/bash #定时删除elasticsearch索引 #author menard 2019-3-25 date=`date -d "-7 days" "+%Y.%m.%d"` /usr/bin/curl -v --user elastic:password -XDELETE "

  • MySQL索引失效原理

    目录 1.索引失效原因 2.再来看看哪些情况会破坏索引的有序性. - 对索引字段做函数操作 - 隐式类型转换 - 隐式字符编码转换 3.总结 1.索引失效原因 首先看看哪些情况下,将会导致查找不能利用索引的有序性. 假设一个表test中有a,b,c,d四个字段,c是主键. 在a,b字段上建立联合索引(a,b):CREATE index idx_a_b on test(a,b); B+树联合索引.JPG 可以得到的规律是:优先按a字段从小到大排序,a字段相等的按b字段从小到大排序: 分析以下情况,

  • elasticsearch数据信息索引操作action support示例分析

    目录 抽象类分析 doExecute方法 performOperation代码 master的相关操作 总结 抽象类分析 Action这一部分主要是数据(索引)的操作和部分集群信息操作. 所有的请求通过client转发到对应的action上然后再由对应的TransportAction来执行相关请求.如果请求能在本机上执行则在本机上执行,否则使用Transport进行转发到对应的节点.action support部分是对action的抽象,所有的具体action都继承了support action

  • Elasticsearch文档索引基本操作增删改查示例

    接口幂等性 接口幂等性:数学概念,多次请求,相当于一次请求 get,put,delete都是幂等性的接口 post 存在幂等性的问题 前端速度很快,点了两次,会生成两个订单 用户在访问新增页面时(提交订单)--->接口返回一个唯一id,提交订单,携带唯一id过来,后端判断这个唯一id是否被用过--->没用过,创建订单 你在项目中碰到的问题和如何解决(项目收获)下订单,经常重复订单,点得快,幂等性问题,如何解决的 倒排索引 1.es介绍10个点 2.安装 -jdk :java开发环境 官网下载e

  • 深入理解 MySQL 索引底层原理

    目录 Mysql 索引底层数据结构选型 哈希表(Hash) 二叉查找树(BST) AVL 树和红黑树 B 树 5.B+树 Innodb 引擎和 Myisam 引擎的实现 MyISAM 引擎的底层实现(非聚集索引方式) Innodb 引擎的底层实现(聚集索引方式) 一步一步推导出 Mysql 索引的底层数据结构. Mysql 作为互联网中非常热门的数据库,其底层的存储引擎和数据检索引擎的设计非常重要,尤其是 Mysql 数据的存储形式以及索引的设计,决定了 Mysql 整体的数据检索性能. 我们知

随机推荐