怎样为我们的正在增长中的应用程序按需扩容呢?当启动了第三个节点,我们的集群将会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配。
![](https://img.kancloud.cn/1e/93/1e93dc9fc99c6240a0b44472fa654ee9_1060x493.png)
Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点,现在每个节点上都拥有 2 个分片,而不是之前的 3 个。 这表示每个节点的硬件资源(CPU, RAM, I/O)将被更少的分片所共享,每个分片的性能将会得到提升。
<br/>
分片是一个功能完整的搜索引擎,它拥有使用一个节点上的所有资源的能力。 我们这个拥有 6 个分片(3 个主分片和 3 个副本分片)的索引可以最大扩容到 6 个节点,每个节点上存在一个分片,并且每个分片拥有所在节点的全部资源。
<br/>
**但是如果我们想要扩容超过 6 个节点怎么办呢?**
主分片的数目在索引创建时就已经确定了下来。实际上,这个数目定义了这个索引能够存储的最大数据量。(实际大小取决于你的数据、硬件和使用场景。) 但是,读操作——搜索和返回数据,可以同时被主分片 或 副本分片所处理,所以当你拥有越多的副本分片时,也将拥有越高的吞吐量。
<br/>
在运行中的集群上是可以动态调整副本分片数目的,我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2。
```json
PUT /users/_settings
{
#"number_of_shards" : 3, #3个主分片
"number_of_replicas" : 2 #每个分片2个副本,所以总共有9个分片
}
```
users 索引现在拥有 9 个分片:3 个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点,每个节点上一个分片。相比原来 3 个节点时,集群搜索性能可以提升 3 倍。
![](https://img.kancloud.cn/d5/46/d546162146bb20c969fa1ac59b61555d_1059x272.png)
当然,如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能,因为每个分片从节点上获得的资源会变少。 你需要增加更多的硬件资源来提升吞吐量。但是更多的副本分片数提高了数据冗余量:按照上面的节点配置,我们可以在失去 2 个节点的情况下不丢失任何数据。
- Elasticsearch是什么
- 全文搜索引擎
- Elasticsearch与Solr
- 数据结构
- 安装Elasticsearch
- Linux单机安装
- Windows单机安装
- 安装Kibana
- Linux安装
- Windows安装
- es基本语句
- 索引操作
- 文档操作
- 映射操作
- 高级查询
- es-JavaAPI
- maven依赖
- 索引操作
- 文档操作
- 高级查询
- es集群搭建
- Linux集群搭建
- Windows集群搭建
- 核心概念
- 索引(Index)
- 类型(Type)
- 文档(Document)
- 字段(Field)
- 映射(Mapping)
- 分片(Shards)
- 副本(Replicas)
- 分配(Allocation)
- 系统架构
- 分布式集群
- 单节点集群
- 故障转移
- 水平扩容
- 应对故障
- 路由计算
- 分片控制
- 写流程
- 读流程
- 更新流程
- 多文档操作流程
- 分片原理
- 倒排索引
- 文档搜索
- 动态更新索引
- 近实时搜索
- 持久化变更
- 段合并
- 文档分析
- 内置分析器
- 分析器使用场景
- 测试分析器
- 指定分析器
- 自定义分析器
- 文档处理
- 文档冲突
- 乐观并发控制
- 外部系统版本控制
- es优化
- 硬件选择
- 分片策略
- 合理设置分片数
- 推迟分片分配
- 路由选择
- 写入速度优化
- 批量数据提交
- 优化存储设备
- 合理使用合并
- 减少Refresh的次数
- 加大Flush设置
- 减少副本的数量
- 内存设置
- 重要配置
- es常见问题
- 为什么要使用Elasticsearch
- master选举流程
- 集群脑裂问题
- 索引文档流程
- 更新和删除文档流程
- 搜索流程
- ES部署在Linux时的优化方法
- GC方面ES需要注意的点
- ES对大数据量的聚合实现
- 并发时保证读写一致性
- 字典树
- ES的倒排索引
- Spring Data Elasticsearch
- 环境搭建
- 索引操作
- 文档操作