怎樣為我們的正在增長中的應用程序按需擴容呢?當啟動了第三個節點,我們的集群將會擁有三個節點的集群 : 為了分散負載而對分片進行重新分配。

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 倍。

當然,如果只是在相同節點數目的集群上增加更多的副本分片并不能提高性能,因為每個分片從節點上獲得的資源會變少。 你需要增加更多的硬件資源來提升吞吐量。但是更多的副本分片數提高了數據冗余量:按照上面的節點配置,我們可以在失去 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
- 環境搭建
- 索引操作
- 文檔操作