原文鏈接：
https://www.jianshu.com/p/297e13045605
節點(node): 單個 ElasticSearch 實例. 通常一個節點運行在一個隔離的容器或虛擬機中
索引(index): 在 ES 中, 索引是一組文檔的集合
分片(shard): 因為 ES 是個分布式的搜索引擎, 所以索引通常都會分解成不同部分, 而這些分布在不同節點的數據就是分片. ES自動管理和組織分片, 並在必要的時候對分片數據進行再平衡分配, 所以用戶基本上不用擔心分片的處理細節.
副本(replica): ES 默認為一個索引創建 5 個主分片, 並分別為其創建一個副本分片. 也就是說每個索引都由 5 個主分片成本, 而每個主分片都相應的有一個 copy。對於分布式搜索引擎來說, 分片及副本的分配將是高可用及快速搜索響應的設計核心.主分片與副本都能處理查詢請求，它們的唯一區別在於只有主分片才能處理索引請求.副本對搜索性能非常重要，同時用戶也可在任何時候添加或刪除副本。額外的副本能給帶來更大的容量, 更高的呑吐能力及更強的故障恢復能力。
如上圖，有集群兩個節點，並使用了默認的分片配置. ES自動把這5個主分片分配到2個節點上, 而它們分別對應的副本則在完全不同的節點上。其中 node1 有某個索引的分片1、2、3和副本分片4、5，node2 有該索引的分片4、5和副本分片1、2、3。
當數據被寫入分片時，它會定期發布到磁盤上的不可變的 Lucene 分段中用於查詢。隨着分段數量的增長，這些分段會定期合並為更大的分段。 此過程稱為合並。 由於所有分段都是不可變的，這意味着所使用的磁盤空間通常會在索引期間波動，因為需要在刪除替換分段之前創建新的合並分段。 合並可能非常耗費資源，特別是在磁盤I / O方面。
分片是 Elasticsearch 集群分發數據的單元。 Elasticsearch 在重新平衡數據時可以移動分片的速度，例如發生故障后，將取決於分片的大小和數量以及網絡和磁盤性能。
注1：避免使用非常大的分片，因為這會對群集從故障中恢復的能力產生負面影響。 對分片的大小沒有固定的限制，但是通常情況下很多場景限制在 50GB 的分片大小以內。
注2：當在ElasticSearch集群中配置好你的索引后, 你要明白在集群運行中你無法調整分片設置. 既便以后你發現需要調整分片數量, 你也只能新建創建並對數據進行重新索引(reindex)(雖然reindex會比較耗時, 但至少能保證你不會停機).
主分片的配置與硬盤分區很類似, 在對一塊空的硬盤空間進行分區時, 會要求用戶先進行數據備份, 然后配置新的分區, 最后把數據寫到新的分區上。
注3：盡可能使用基於時間的索引來管理數據保留期。 根據保留期將數據分組到索引中。 基於時間的索引還可以輕松地隨時間改變主分片和副本的數量，因為可以更改下一個要生成的索引。
二、索引和分片是否是空閑的
對於每個 Elasticsearch 索引，有關映射和狀態的信息都存儲在集群狀態中。它保存在內存中以便快速訪問。 因此，在群集中具有大量索引可能導致較大的群集狀態，尤其是在映射較大的情況下。 這可能會變得很慢，因為所有更新都需要通過單個線程完成，以便在更改集群中分布之前保證一致性。
每個分片都有需要保存在內存中的數據並使用堆空間。 這包括在分片級別保存信息的數據結構，但也包括在分段級別的數據結構，以便定義數據駐留在磁盤上的位置。 這些數據結構的大小不固定，並且會根據使用場景不同而有所不同。然而，分段相關開銷的一個重要特征是它與分段的大小不嚴格成比例。 這意味着與較小的分段相比，較大的分段每個數據量的開銷較小。 差異可能很大。為了能夠為每個節點存儲盡可能多的數據，管理堆的使用並盡可能減少開銷變得很重要。 節點擁有的堆空間越多，它可以處理的數據和分片就越多。
因此，索引和分片在集群視角下不是空閑的，因為每個索引和分片都存在一定程度的資源開銷。
分配的每個分片都是有額外的成本的:
-
每個分片本質上就是一個Lucene索引, 因此會消耗相應的文件句柄, 內存和CPU資源
-
每個搜索請求會調度到索引的每個分片中. 如果分片分散在不同的節點倒是問題不太. 但當分片開始競爭相同的硬件資源時, 性能便會逐步下降
-
ES 使用詞頻統計來計算相關性. 當然這些統計也會分配到各個分片上。如果在大量分片上只維護了很少的數據, 則將導致最終的文檔相關性較差。
注1：小的分片會造成小的分段，從而會增加開銷。我們的目的是將平均分片大小控制在幾 GB 到幾十 GB 之間。對於基於時間的數據的使用場景來說，通常將分片大小控制在 20GB 到 40GB 之間。
注2：由於每個分片的開銷取決於分段的數量和大小，因此通過 forcemerge 操作強制將較小的分段合並為較大的分段，這樣可以減少開銷並提高查詢性能。 理想情況下，一旦不再向索引寫入數據，就應該這樣做。 請注意，這是一項比較耗費性能和開銷的操作，因此應該在非高峰時段執行。
注3：我們可以在節點上保留的分片數量與可用的堆內存成正比，但 Elasticsearch 沒有強制的固定限制。 一個好的經驗法則是確保每個節點的分片數量低於每GB堆內存配置20到25個分片。 因此，具有30GB堆內存的節點應該具有最多600-750個分片，但是低於該限制可以使其保持更好。 這通常有助於集群保持健康。
注4：如果擔心數據的快速增長, 建議根據這條限制: ElasticSearch推薦的最大JVM堆空間 是 30~32G, 所以把分片最大容量限制為 30GB, 然后再對分片數量做合理估算。例如, 如果的數據能達到 200GB, 則最多分配7到8個分片。
注5：如果是基於日期的索引需求, 並且對索引數據的搜索場景非常少. 也許這些索引量將達到成百上千, 但每個索引的數據量只有1GB甚至更小. 對於這種類似場景, 建議是只需要為索引分配1個分片。如果使用ES的默認配置(5個分片), 並且使用 Logstash 按天生成索引, 那么 6 個月下來, 擁有的分片數將達到 890 個. 再多的話, 你的集群將難以工作--除非提供了更多(例如15個或更多)的節點。想一下, 大部分的 Logstash 用戶並不會頻繁的進行搜索, 甚至每分鍾都不會有一次查詢. 所以這種場景, 推薦更為經濟使用的設置. 在這種場景下, 搜索性能並不是第一要素, 所以並不需要很多副本。 維護單個副本用於數據冗余已經足夠。不過數據被不斷載入到內存的比例相應也會變高。如果索引只需要一個分片, 那么使用 Logstash 的配置可以在 3 節點的集群中維持運行 6 個月。當然你至少需要使用 4GB 的內存, 不過建議使用 8GB, 因為在多數據雲平台中使用 8GB 內存會有明顯的網速以及更少的資源共享.