Q:有两个人掉到陷阱里了,死的人叫死人,活人叫什么?

elasticsearch节点数据分配不均

Elasticsearch | 作者 zekaifeng | 发布于2021年09月16日 | 阅读数:318

ES集群包含三个节点,索引配置是2个主分片每个主分片带1个副本,业务按周跟换索引。每天凌晨会有数据清理,使用的是delete_query的方式,运行半年后,发现三个节点数据分配不均,第一个节点数据使用率85%,第二个30%,第三个85%。个人怀疑是数据清理的方式不合理,导致有很多的空索引,这些空索引引发的后续的新增的索引数据分配不均衡。有没有什么好的优化方案,让数据均衡分配,不要出现这个三个节点数据分配差别很大的情况。
已邀请:

spoofer

赞同来自: zekaifeng mirror6Y

1、es转发数据到那个节点的shard上是根据路由算法来的,跟磁盘无关。因为一个文档的id(或者说route key是固定)就必须根据hash算法算出固定的节点上的shard。不可能根据节点的负载来作为路由数据的依据,不然搜索时就全乱套了,除非记录哪个文档id被存储在哪个shard上,这样效率太低了,不可取。
2、如果在某个节点上配置了多个路径来使用多个磁盘,那么落到各个磁盘的shard确实有可能不均匀,这个跟你说的不一样~~你的情况是节点间数据倾斜了。
3、上面说使用随机id和hash算法来确保文档数据均匀分布,但是使用自定义的id或者route ke时可能会造成数据倾斜,可以使用index.routing_partition来控制。其计算逻辑在: cluster/routing/OperationRouting.java中。
 
private static int calculateScaledShardId(IndexMetadata indexMetadata, String effectiveRouting, int partitionOffset) {
final int hash = Murmur3HashFunction.hash(effectiveRouting) + partitionOffset;

// we don't use IMD#getNumberOfShards since the index might have been shrunk such that we need to use the size
// of original index to hash documents
return Math.floorMod(hash, indexMetadata.getRoutingNumShards()) / indexMetadata.getRoutingFactor();
}

 
4、对于索引的创建是在allocation模块中处理的,这个模块中主要有allocators和deciders两个基础组件,allocators负责寻找最优节点来进行分配分片,而deciders主要决定是否进行分配。创建新的分片时,allocators会找出拥有分片数量最少的节点列表并且按数量升序排序,但是不会考虑每个分片集体的数据量的大小!!!!
 
 
 
 
 

God_lockin

赞同来自:

数据插入的时候是否有指定 _id 和 routerkey?清理数据可以考虑reindex + delete index的方式
 
节点使用不均衡可能要考虑是否存在分片个数和节点个数不均衡的问题

要回复问题请先登录注册