谈Elasticsearch下分布式存储的数据分布

标签: geek | 发表时间:2018-10-31 00:00 | 作者:
出处:http://itindex.net/relian

  对于一个分布式存储系统来说,数据是分散存储在多个节点上的。如何让数据均衡的分布在不同节点上,来保证其高可用性?所谓均衡,是指系统中每个节点的负载是均匀的,并且在发现有不均匀的情况或者有节点增加/删除时,能及时进行调整,保持均匀状态。本文将探讨Elasticsearch的数据分布方法,文中所述的背景是Elasticsearch 5.5。
  在Elasticsearch中,以Shard为最小的数据分配/迁移单位。数据到节点的映射分离为两层:一层是数据到Shard的映射( Route),另一层是Shard到节点的映射( Allocate)。

  一方面,插入一条数据时,ES会根据指定的Key来计算应该落到哪个Shard上。默认Key是自动分配的id,可以自定义,比如在我们的业务中采用CompanyID作为Key。因为Primary Shard的个数是不允许改变的,所以同一个Key每次算出来的Shard是一样的,从而保证了准确定位。

   shard_num = hash(_routing) % num_primary_shards

  另一方面,Master会为每个Shard分配相应的Data节点进行存储,并维护相关元信息。通过Route计算出来的Shard序号,在元信息中找到对应的存储节点,便可完成数据分布。Shard Allocate的映射关系并不是完全不变的,当检测到数据分布不均匀、有新节点加入或者有节点挂掉等情况时就会进行调整,称为 Relocate。那么,Elasticsearch是根据什么规则来为Shard选取节点,从而保证数据均衡分布的?概括来看,主要有三方面的影响: 节点位置磁盘空间单个节点上的Index和Shard个数

节点位置

   对于一个ES节点来说,它可能是某台物理机器上的一个VM,而这个物理机器位于某个Zone的某个机架(Rack)上。通过将Primary Shard和Replica Shard分散在不同的物理机器、Rack、Zone,可以尽可能的降低数据丢失和系统不可用的风险,这一点几乎在所有的分布式系统中都会考量。

   Elasticsearch是通过设置awareness.attribute对集群中的节点进行分组,从而实现Rack和Zone的发现。比如按照下列方式对elasticsearch.yml进行配置,再启动相应的节点,即可实现Zone的区分。

   // elasticsearch.yml
cluster.routing.allocation.awareness.attributes: zone

// 启动ES
./bin/elasticsearch -Enode.attr.zone=zone_one
./bin/elasticsearch -Enode.attr.zone=zone_two

  实践中,如果使用了这样的Awareness机制,应该保证不同分组类的机器个数一致,不会发生倾斜。比如,在Zone Awareness下,如果集群有10台机器,应该保证每个Zone各有5台机器(2个Zone)。

磁盘空间

  磁盘空间是制约存储的硬性条件,单机的可用磁盘空间决定了能否继续往这个节点写入新数据、分配新Shard以及是否需要迁移数据等。在ES中,有三个参数用来控制与此相关的特性,默认每30秒检查一次。

  • cluster.routing.allocation.disk.watermark.low: 默认为85%,超过这个阈值后,就不允许往这个节点分配Shard。
  • cluster.routing.allocation.disk.watermark.high:默认为90%,超过这个阈值后,就需要将该节点的Shard迁移出去。
  • cluster.routing.allocation.disk.watermark.flood_stage:默认为95%,超过这个阈值后,与该节点上的Shard有关的Index都变成只读,不允许写入数据。

单个节点上的Index和Shard个数

  在满足节点位置和磁盘空间的条件后,单个节点上的Index和Shard个数是否均匀,决定了Shard可以分配/迁移到哪个节点。ES通过计算权值来量化这样的分配方式。
  以检测某个Shard是否需要迁移到其他节点为例,ES会先计算该Shard所在节点(A)的权值,然后依次跟其他节点的权值比较,如果与节点B的差值(Delta-A)超过了阈值,再进一步计算节点A去掉该Shard后的权值与节点B增加该Shard后的权值之间的差值(Delta-B),如果Delta-A大于Delta-B,则表明Shard可以迁移到节点B。
  这里的权值计算简化如下,其中indexBalance与shardBalance分别由参数控制,而阈值由cluster.routing.allocation.balance.threshold设置,默认为1.0f。当然,这里只描述了核心思想,详细逻辑请阅读 BalancedShardsAllocator.java中的源码。通过调整三个参数,可以控制策略的松紧。

   // indexBalance = cluster.routing.allocation.balance.index, default is 0.55f
// shardBalance = cluster.routing.allocation.balance.shard, default is 0.45f

float sum = indexBalance + shardBalance;
float theta0 = shardBalance / sum;
float theta1 = indexBalance / sum;

private float weight(Balancer balancer, ModelNode node, String index, int numAdditionalShards) {
    final float weightShard = node.numShards() + numAdditionalShards - balancer.avgShardsPerNode();
    final float weightIndex = node.numShards(index) + numAdditionalShards - balancer.avgShardsPerNode(index);
    return theta0 * weightShard + theta1 * weightIndex;
}

Primary与Replica分布

  最初关注Elasticsearch的数据分布,是因为在性能调优时遇到了一个与Primary/Replica分布有关的问题。背景是这样的,为了能够复用单个节点上的Disk Cache,我们对查询请求进行了限制,只允许其访问Primary Shard。然而总是有那么一两台机器的查询会被Queue住,通过调研发现,这些机器上面的Primary Shard比其他机器多(对某一个Index而言),即下图中左边所示,而我们希望的是右图所示的均匀分布。
  引起这个问题的根源是,Elasticsearch中的Shard均匀分布是针对Primary+Replica整体而言的,也就是说没法做到只针对Primary Shard单方面做均匀分布,所以才会出现下图左边所示,某个节点上有3个Primary Shard,而另一个节点只有1个。目前尚未发现可以调节的地方。


  本文探讨了Elasticsearch的数据分布方法,其思想对很多其他分布式存储系统是通用的,而了解相关原理是做很多调优工作的前提。


(全文完,本文地址: https://blog.csdn.net/zwgdft/article/details/83478241
(版权声明:本人拒绝不规范转载,所有转载需征得本人同意,并且不得更改文字与图片内容。大家相互尊重,谢谢!)

Bruce
2018/10/30 晚

相关 [elasticsearch 分布 数据] 推荐:

谈Elasticsearch下分布式存储的数据分布

- - IT瘾-geek
  对于一个分布式存储系统来说,数据是分散存储在多个节点上的. 如何让数据均衡的分布在不同节点上,来保证其高可用性. 所谓均衡,是指系统中每个节点的负载是均匀的,并且在发现有不均匀的情况或者有节点增加/删除时,能及时进行调整,保持均匀状态. 本文将探讨Elasticsearch的数据分布方法,文中所述的背景是Elasticsearch 5.5.

ElasticSearch —修改ES数据

- -
ElasticSearch能够以接近实时的速度提供数据操作和搜索功能. 在默认情况下,从索引/更新/删除数据到出现在搜索结果之间,你可能会感受到有1秒的延迟时间(刷新间隔). 这是与SQL等其他平台的一个重要区别,这些平台在完成事务之后,它们的数据立即可用. 先前,我们已经知道如何索引一个单个的文档.

Elasticsearch 数据备份、迁移

- - 枯惠
在时候我们面临将Elasticsearch的数据进行迁移亦或是数据备份的场景,此时我们可以使用 elasticsearch-dump这个工具来实现:. mappings从production环境复制到staging环境. 数据从production环境复制到staging. template数据导出导入.

[Elasticsearch] 分布式搜索

- - 编程语言 - ITeye博客
本文翻译自Elasticsearch官方指南的 Distributed Search Execution一章. 在继续之前,我们将绕一段路来谈谈在分布式环境中,搜索是如何执行的. 和在分布式文档存储(Distributed Document Store)中讨论的基本CRUD操作相比,这个过程会更加复杂一些.

通过HBase Observer同步数据到ElasticSearch

- - SegmentFault 最新的文章
Observer希望解决的问题. HBase是一个分布式的存储体系,数据按照RowKey分成不同的Region,再分配给RegionServer管理. 但是RegionServer只承担了存储的功能,如果Region能拥有一部分的计算能力,从而实现一个HBase框架上的MapReduce,那HBase的操作性能将进一步提升.

Elasticsearch、Kibana数据导出实战

- -
以下两个导出问题来自Elastic中文社区. 问题1、kibana怎么导出查询数据. 问题2:elasticsearch数据导出. 就像数据库数据导出一样,elasticsearch可以么. 或者找到它磁盘上存放数据的位置,拷贝出来,放到另一个es服务器上或者转成自己要的数据格式. 实际业务实战中,大家或多或少的都会遇到导入、导出问题.

分布式检索系统 ElasticSearch

- - 丕子
ElasticSearch最近发展不错,github等都用它,可以关注I下. ElasticSearch是分布式,REST风格,搜索和分析系统. 具有实时数据,实时分析,分布式,高可用性,多租户,全文搜索,面向文档,冲突管理,自由模式,rest风格API,每个操作的持久性,Apache 2的开源许可证,基于Apache Lucene之上的特点.

Elasticsearch分布式搜索架构原理 | Elasticsearch权威指南(中文版)

- -
在继续之前,我们将绕道讲一下搜索是如何在分布式环境中执行的. 它比我们之前讲的基础的增删改查(create-read-update-delete,CRUD)请求要复杂一些. 本章的信息只是出于兴趣阅读,使用Elasticsearch并不需要理解和记住这里的所有细节. 阅读这一章只是增加对系统如何工作的了解,并让你知道这些信息以备以后参考,所以别淹没在细节里.

ElasticSearch 亿级数据检索深度优化

- - IT瘾-dev
数据平台已迭代三个版本,从头开始遇到很多常见的难题,终于有片段时间整理一些已完善的文档,在此分享以供所需朋友的实现参考,少走些弯路,在此篇幅中偏重于ES的优化,关于HBase,Hadoop的设计优化估计有很多文章可以参考,不再赘述. 在一业务系统中,部分表每天的数据量过亿,已按天分表,但业务上受限于按天查询,并且DB中只能保留3个月的数据(硬件高配),分库代价较高.

数据同步工具 Elasticsearch-datatran v6.2.9 发布

- - 开源中国-软件更新资讯
Elasticsearch版本兼容性:支持各种Elasticsearch版本(1.x,2.x,5.x,6.x,7.x,+)之间相互数据迁移. 数据同步改进:完善ip2region和geoip数据库热加载机制. Restclient改进:升级httpcliet组件版本到最新的官方版本4.5.13. Restclient改进:升级fastxml jackson databind版本2.9.10.8.