ElasticSearch修改分片数和副本数及增加字段

本文介绍如何通过重新索引的方式调整Elasticsearch索引库的分片数量,包括创建索引库、复制数据等步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、修改副本数

PUT test/_settings
{
    "index": {
        "number_of_replicas" : 1
    }
}

二、修改分片数

ElasticSearch中的数据会被分别存储在不同的分片上,索引库的分片数量是在索引库创建的时候通过settings去设置的,如果不设置,分片数默认是5,分片数一旦确定就不能改变。如果执行下面语句会报错

PUT test/_settings
{
    "index": {
        "number_of_shards" : 1
    }
}

随着数据量的增大,每个分片中的数据量也会不断增加,为了不使每个分片中的数据量过大,就需要增加分片的数量,但是分片数在索引库创建之初就已经确定,并且不能改变。

为了解决这个问题,ElasticSearch中设置了重新索引机制来实现。本文将通过一个案例进行演示如何通过重新索引修改分片数。

什么是重新索引

简单来说,重新索引就是创建一个和原索引库结构属性都基本一样的新的索引库,然后将原索引库中的数据复制到新的索引库当中。在新的索引库中,除了需要变更的地方,比如某些字段的数据类型和分片数,其他的所有属性都一样。

重新索引的具体实现

1. 创建学生索引库

下列是创建索引库students1的命令,这里创建一个关于学生信息的索引库,指定分片数为3。

DELETE students1

PUT students1
{
"settings":{
"number_of_shards":3,
"number_of_replicas":1
},
"mappings":{
"student":{
"dynamic":"strict",
"properties":{
"id":{"type": "text", "store": true},
"name":{"type": "text","store": true},
"age":{"type": "integer","store": true},
"times": {"type": "text", "index": false}
}
}
}
}

2. 插入数据

创建好索引库students1后,插入一条数据,为后面的验证做数据准备。

PUT students1/student/1 
{ "id" : "1",
 "name" : "张三", 
 "age" : 20 , 
 "times" : "2020-02-01" 
}

3. 新建索引库students2

下列是创建索引库students2的命令,与students1不同的地方是指定分片数为5,其他的属性都和students1一样。

DELETE students2 

PUT students2 
{ "settings":
   { "number_of_shards":5, 
   "number_of_replicas":1 
   },
  "mappings":
  { "student":{ "dynamic":"strict", "properties":{ "id":{"type": "text", "store": true}, "name":{"type": "text","store": true}, "age":{"type": "integer","store": true}, "times": {"type": "text", "index": false} } } 
 }  
}

4. 拷贝数据

通过下面命令,将students1中的数据复制到students2中,这是重新索引的核心步骤。

POST _reindex 
{ 
 "source": {  
   "index": "students1" 
  }, 
 "dest": { 
   "index": "students2" 
  } 
} 

小结

本文通过一个简单的案例,先创建索引库students1和索引库students2,在创建students2的语句中指定新的分片数,然后将students1中数据复制到students2中,实现重新索引,以达到修改索引库分片数的目的。如果生产中需要实现重新索引,需要按照实际

索引库的情况修改创建索引库的命令,在实现重新索引之后,要将程序中的索引库指向新的索引库。另外,本文中的操作命令是通过在kibana中的命令窗口中执行的,本文重点在介绍如何通过重新索引修

三、增加字段

PUT ods_big_epid/_mapping/ods_big_epid
{
  "properties":{
    "reportDate":{
      "type": "date",
      "format":"yyyy-MM-dd HH:mm:ss"
    }
  }
}
<think>嗯,用户之前问过关于Elasticsearch分布式架构如何处理节点故障的问题,现在又接着问分片副本。看来他们可能是在学习ES的分布式机制,或者是正在搭建集群需要了解这些概念。 首先,用户之前的问题是关于节点故障的自动处理,所以现在问分片副本应该是想深入理解据存储冗余的机制。分片副本是ES实现高可用扩展性的核心,需要详细解释两者的区别联系。 用户可能不太清楚分片副本的作用,或者混淆了它们的概念。需要明确分片据分割的单位,而副本是分片的复制,用于故障恢复负载均衡。可能还需要举例说明,比如索引如何被分成多个分片,每个分片如何有副本。 另外,用户可能关心实际应用中的配置,比如如何设置分片副本数,最佳实践是什么。需要提到分片过多或过少的影响,副本数量的调整对集群性能的影响,以及如何根据硬件资源来规划。 还要注意用户可能的误区,比如认为增加副本可以无限提高性能,但实际上副本会占用存储计算资源。需要解释平衡可用性资源消耗的重要性。 用户可能还需要知道分片副本在故障恢复中的具体作用,比如主分片失效时副本如何提升为主分片,恢复过程中据如何同步。这部分可以结合之前的节点故障处理机制来回答,形成知识连贯性。 最后,可能还需要提到一些常见问题,比如分片无法分配的原因,如何监控分片状态,以及调整分片副本时的注意事项。这些实际操作的内容对用户来说可能非常实用。</think>### Elasticsearch 分片(Shard)与副本(Replica)详解 --- #### 一、核心概念对比 | 特性 | **分片(Shard)** | **副本(Replica)** | |-------------|--------------------------------------|--------------------------------------| | **本质** | 据的最小物理存储单元 | 分片的完整拷贝 | | **类型** | 主分片(Primary) / 副本分片(Replica)| 只能是主分片的副本 | | **读写权限** | 主分片可读写,副本分片默认只读 | 仅响应查询请求 | | **创建时机** | 索引创建时固定量(不可修改) | 可动态调整量 | | **作用目标** | 解决**据水平扩展**问题 | 解决**高可用****查询负载均衡**问题 | --- #### 二、技术实现细节 ##### 1. **分片工作机制** - **分片公式**: $$ \text{总据存储量} = \text{主分片} \times (1 + \text{副本数}) \times \text{单分片据量} $$ - **路由机制**: 文档通过哈希算法分配到指定主分片: $$ \text{shard\_num} = hash(\_routing) \% \text{num\_primary\_shards} $$ - **分片限制**: 单个分片建议大小在 `10GB-50GB`(超过 `100GB` 可能影响性能) ##### 2. **副本运作原理** - **实时同步**: 主分片通过 `Translog` 保证据变更顺序,副本采用 `pull` 模式同步据 - **一致性模型**: - **同步写入**:需多副本确认(通过 `wait_for_active_shards` 参控制) - **异步刷新**:默认每秒刷新(`refresh_interval=1s`) --- #### 三、配置与优化策略 ##### 1. **分片量决策** - **黄金法则**: 分片 = 节点 &times; 单节点承载分片(建议 `500-1000`/节点) 例如:3节点集群,单节点承载上限 800 分片 → 总容量约 `2400` 分片 - **动态调整限制**: 主分片创建后不可变,只能通过 `Reindex API` 重建索引调整 ##### 2. **副本配置技巧** ```json // 创建索引时指定分片配置 PUT /my_index { "settings": { "number_of_shards": 3, // 主分片 "number_of_replicas": 2 // 每个主分片副本数 } } // 动态修改副本数(实时生效) PUT /my_index/_settings { "number_of_replicas": 1 } ``` ##### 3. **性能优化要点** - **冷热分离架构**: 使用 `ILM(Index Lifecycle Management)` 将旧索引副本数降为 `0` - **写入优化**: 临时关闭副本(`index.number_of_replicas=0`)提升批量导入速度 - **查询加速**: 增加副本可实现读请求的**多副本负载均衡** --- #### 四、故障场景应对 ##### 1. **分片未分配(UNASSIGNED)** - **常见原因**: - 磁盘空间不足(`85%` 水位线触发只读模式) - 节点属性不匹配分配规则(如 `rack` 标签约束) - **解决方案**: ```bash # 强制分配分片(慎用) POST /_cluster/reroute { "commands": [{ "allocate_stale_primary": { "index": "my_index", "shard": 0, "node": "node-1", "accept_data_loss": true } }] } ``` ##### 2. **副本同步延迟** - **检测方法**: ```bash GET /_cat/shards?v&h=index,shard,prirep,state,docs,store ``` - **处理方案**: - 检查网络带宽(`indices.recovery.max_bytes_per_sec`) - 优化映射字段类型,减少 `_source` 体积 --- #### 五、最佳实践总结 1. **容量规划**: - 预估据总量 → 确定主分片 - 根据 SLA 要求 → 确定副本数(生产环境至少 `1` 副本) 2. **硬件匹配原则**: - 单个分片据量 ≈ 节点内存的 `1/10`(如 `64GB` 内存 → 分片大小 `6-7GB`) - 使用 `SSD` 磁盘降低副本同步延迟 3. **监控关键指标**: - `indices.search.fetch_current`(副本查询负载) - `indices.indexing.index_current`(主分片写入压力) - `thread_pool` 的 `write`/`search` 队列深度 4. **特殊场景处理**: - **时序据**:使用 `Rollover API` 自动创建新分片 - **全局搜索**:设置 `preference=_primary` 强制主分片查询 --- #### 六、经典误区解析 - **误区1**:"增加副本数一定能提升查询性能" ✅ 实际:当查询为 `CPU 密集型` 时,过多副本可能引发线程竞争 - **误区2**:"主分片越多越好" ✅ 实际:分片过多会导致 `元据管理开销` 指级增长 - **误区3**:"副本可以替代备份" ✅ 实际:副本不能防范 `误删除`,仍需 `Snapshot` 实现真正备份 --- 通过合理配置分片与副本,可在**据可靠性**、**查询性能**、**硬件成本**之间找到最佳平衡点。建议通过 `Elasticsearch Rally` 进行分片方案的基准测试验证。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值