elasticsearch 分片(Shards)的理解

分片重要性

ES中所有数据均衡的存储在集群中各个节点的分片中,会影响ES的性能、安全和稳定性, 所以很有必要了解一下它。

分片是什么?

简单来讲就是咱们在ES中所有数据的文件块,也是数据的最小单元块,整个ES集群的核心就是对所有分片的分布、索引、负载、路由等达到惊人的速度

实列场景:

假设 IndexA 有2个分片,我们向 IndexA 中插入10条数据 (10个文档),那么这10条数据会尽可能平均的分为5条存储在第一个分片,剩下的5条会存储在另一个分片中。

和主流关系型数据库的表分区的概念有点类似,如果你比较熟悉关系型数据库的话。

分片的设置

创建 IndexName 索引时候,在 Mapping 中可以如下设置分片 (curl)

PUT indexName
{
    "settings": {
        "number_of_shards": 5
    }
}

注意

索引建立后,分片个数是不可以更改的

分片个数(数据节点计算)

分片个数是越多越好,还是越少越好了?根据整个索引的数据量来判断。

实列场景:

如果 IndexA 所有数据文件大小是300G,改怎么定制方案了?(可以通过Head插件来查看)

建议:(仅参考)

   1、每一个分片数据文件小于30GB

   2、每一个索引中的一个分片对应一个节点

   3、节点数大于等于分片数

根据建议,至少需要 10 个分片。

结果: 建10个节点 (Node),Mapping 指定分片数为 10,满足每一个节点一个分片,每一个分片数据带下在30G左右。

SN(分片数) = IS(索引大小) / 30

NN(节点数) = SN(分片数) + MNN(主节点数[无数据]) + NNN(负载节点数)

分片查询

我们可以指定es去具体的分片查询从而进一步的实现es极速查询。

  1. randomizeacross shards

    随机选择分片查询数据,es的默认方式

  2. _local

    优先在本地节点上的分片查询数据然后再去其他节点上的分片查询,本地节点没有IO问题但有可能造成负载不均问题。数据量是完整的。

  3. _primary

    只在主分片中查询不去副本查,一般数据完整。

  4. _primary_first

    优先在主分片中查,如果主分片挂了则去副本查,一般数据完整。

  5. _only_node

    只在指定id的节点中的分片中查询,数据可能不完整。

  6. _prefer_node

    优先在指定你给节点中查询,一般数据完整。

  7. _shards

    在指定分片中查询,数据可能不完整。

  8. _only_nodes

    可以自定义去指定的多个节点查询,es不提供此方式需要改源码。

    /** 
         * 指定分片 查询 
         */  
        @Test  
        public void testPreference()  
        {  
            SearchResponse searchResponse = transportClient.prepareSearch(index)  
                    .setTypes("add")  
                    //.setPreference("_local")  
                    //.setPreference("_primary")  
                    //.setPreference("_primary_first")  
                    //.setPreference("_only_node:ZYYWXGZCSkSL7QD0bDVxYA")  
                    //.setPreference("_prefer_node:ZYYWXGZCSkSL7QD0bDVxYA")  
                    .setPreference("_shards:0,1,2")  
                    .setQuery(QueryBuilders.matchAllQuery()).setExplain(true).get();  

            SearchHits hits = searchResponse.getHits();  
            System.out.println(hits.getTotalHits());  
            SearchHit[] hits2 = hits.getHits();  
            for(SearchHit h : hits2)  
            {  
                System.out.println(h.getSourceAsString());  
            }  
        }  
<think>嗯,用户想了解Elasticsearch分片分配策略以及如何选择合适的方法。首先,我需要回忆一下Elasticsearch分片的基本概念。分片分为主分片和副本分片,主分片用于存储数据,副本分片用于备份和查询负载均衡。分片分配策略可能涉及如何分布这些分片到不同的节点上,以优化性能、可靠性和资源利用。 接下来,用户提到的分片分配策略可能包括集群层面的设置,比如动态分配、数据层划分、节点角色分离等。动态分配策略允许Elasticsearch自动决定分片的分布,这可能根据节点的负载、磁盘空间等因素进行调整。而数据层划分可能是将热数据、温数据和冷数据存储在不同类型的节点上,比如使用SSD存储热数据,HDD存储冷数据,这样可以优化存储成本和访问速度。 节点角色分离也是一个重要策略,将主节点、数据节点、协调节点分开,这样可以避免资源竞争,提高集群的稳定性。比如,主节点负责集群管理,数据节点处理存储和查询,协调节点处理请求分发。这样各司其职,提高效率。 然后,用户想知道如何选择正确的分片策略。可能需要考虑的因素包括数据量、读写压力、节点硬件配置、容灾需求等。比如,对于大索引,可能需要更多的分片来分散压力,但分片过多也会带来管理开销。另外,副本分片的数量会影响查询性能和容灾能力,增加副本可以提高可用性,但也会占用更多存储和资源。 在分片分配策略中,还有一些高级设置,比如分片分配过滤、强制感知和分片重新平衡策略。分片分配过滤可以根据节点属性(如区域、机架)来分配分片,确保分片分布在不同的物理位置,提高容灾能力。强制感知策略可以防止同一分片的主副本在同一区域,避免单点故障。分片重新平衡策略则是在节点增减时如何调整分片分布,保持集群的均衡。 用户可能还关心容量规划,比如如何根据数据增长和业务需求调整分片方案。例如,参考中的例子,用户为不同的索引选择了不同的分片方案,比如1x1、3x2,这可能基于索引的大小、增长速度和重要性。比如产品索引可能数据量大且重要,所以需要更多分片和副本。 此外,分片大小的最佳实践也很重要,比如每个分片推荐在10GB到50GB之间,但具体还要看使用场景。分片过多会导致资源浪费,过少则可能成为性能瓶颈。 用户可能在实际应用中遇到问题,比如分片分配不均导致某些节点压力大,或者分片数量过多影响查询性能。这时候需要根据监控数据调整分片策略,比如调整分片数量、重新分配节点角色,或者使用索引生命周期管理(ILM)自动管理数据的分片策略。 最后,生成相关问题时需要考虑用户可能进一步想了解的内容,比如如何监控分片分配、具体的配置步骤、分片策略调整后的影响,或者如何处理分片分配失败的情况。这些问题可以帮助用户更深入地理解和应用分片策略。</think>### Elasticsearch 分片分配策略及选择方法 #### 1. 分片分配基础概念 - **分片类型**:分为主分片(Primary Shard)和副本分片(Replica Shard),主分片存储数据,副本分片提供冗余和查询负载均衡。 - **分片分配目标**:通过合理分配分片,实现负载均衡、高可用性和性能优化[^1]。 #### 2. 分片分配策略 **(1) 动态分配策略(默认)** - Elasticsearch 自动根据节点的负载、磁盘使用率和分片分布情况分配分片。 - 适用场景:小型集群或对性能要求不高的场景。 **(2) 数据层划分策略** - 将节点划分为热(Hot)、温(Warm)、冷(Cold)层: - **热层**:高性能硬件(如 SSD),存储高频访问数据。 - **温层/冷层**:低性能硬件(如 HDD),存储低频或归档数据。 - 通过索引生命周期管理(ILM)自动迁移数据。 **(3) 节点角色分离** - 区分主节点、数据节点、协调节点: - **主节点**:管理集群状态。 - **数据节点**:存储分片。 - **协调节点**:处理请求分发。 - 优势:减少资源竞争,提升稳定性。 **(4) 分片分配过滤** - 根据节点属性(如 `zone`、`rack`)分配分片,避免分片集中在单一物理区域。 - 示例配置: ```json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.include.zone": "east,west" } } ``` #### 3. 如何选择分片策略? | **考量因素** | **策略选择** | |----------------------|----------------------------------| | 数据规模与增长 | 动态分配 + 分片数量优化(如 3x2)| | 读写性能需求 | 数据层划分 + 热层高配硬件 | | 容灾需求 | 分片分配过滤 + 多副本(≥2) | | 硬件资源限制 | 节点角色分离 + 分片分配过滤 | #### 4. 分片分配高级配置 **(1) 强制感知策略** - 确保主分片和副本分片不在同一物理区域: ```json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.awareness.attributes": "zone", "cluster.routing.allocation.awareness.force.zone.values": "east,west" } } ``` **(2) 分片重新平衡策略** - 控制分片在节点间的迁移频率: ```json PUT _cluster/settings { "persistent": { "cluster.routing.rebalance.enable": "primaries" } } ``` #### 5. 最佳实践 - **分片大小**:推荐单个分片容量为 $10\text{GB} \leq V \leq 50\text{GB}$,避免过大或过小。 - **分片数量公式**: $$N = \frac{\text{总数据量}}{\text{单分片容量}} \times (1 + \text{副本数})$$ - **监控工具**:使用 Elasticsearch 的 `_cat/shards` API 或 Kibana 监控分片状态。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值