Elasticsearch 是一個非常通用的平臺，支持各種用戶實例，併爲組織數據和複製策略提供了極大的靈活性。但是，這種靈活性有時會使我們很難在早期確定如何很好地將數據組織成索引和分片，尤其是不熟悉 Elastic Stack。雖然不一定會在首次啓動時引起問題，但隨着數據量的增長，它們可能會導致性能問題。羣集擁有的數據越多，糾正問題也越困難，因爲有時可能需要重新索引大量數據。
因此，當我們遇到性能問題時，往往可以追溯到索引方式以及集羣中分片的數量。那麼就會遇到問題，我們應該有多少分片以及我的分片應該有多大。
一、什麼是分片？
假如我們的集羣的架構如下圖：
image.png
集羣(cluster): 由一個或多個節點組成, 並通過集羣名稱與其他集羣進行區分
節點(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 內存會有明顯的網速以及更少的資源共享.
三、分片大小如何影響性能
在Elasticsearch中，每個查詢在每個分片的單個線程中執行。 但是，可以並行處理多個分片，對同一分片也可以進行多個查詢和聚合。
這意味着，如果不涉及緩存，則最小查詢延遲將取決於數據、查詢類型以及分片的大小。 查詢大量小的分片將使每個分片的處理速度更快，但是需要按順序排隊和處理更多的任務，它不一定比查詢較少數量的較大分片更快。 如果存在多個併發查詢，則擁有大量小分片也會降低查詢吞吐量。
從查詢性能角度確定最大分片大小的最佳方法是使用實際數據和查詢進行基準測試。 始終以查詢和加載索引的節點在生產中需要處理的內容基準，因爲優化單個查詢可能會產生誤導性結果。
四、如何管理分片大小
當使用基於時間的索引時，通常每個索引都與固定的時間段相關聯。 每天的索引非常常見，通常用於保存保留期短的或每日量大的數據。 這些允許以合適的粒度管理保留期，並且可以輕鬆調整日常基礎量。 具有較長保留期的數據，特別是如果每日的量不能保證使用每天的索引，通常使用每週或每月的索引以保證分片大小。 這減少了隨着時間的推移需要存儲在集羣中的索引和分片的數量。
注：如果使用基於時間的索引，這個時間是某個固定的時間段，那麼需要根據數據的保留期限和預期的數據量來調整每個索引所覆蓋的時間段，以達到目標分片的大小。也就是說，如果我們要確定最終分片的大小，則需要根據我們的數據保存的期限以及預估預期的數據量來調整我們索引需要按照天還是周還是月的時間來進行評估。
當數據量可以合理預測並且變化緩慢時，具有固定時間間隔的基於時間的索引很有效。 如果索引快速變化，則很難保持統一的目標分片大小。爲了能夠更好地處理這種類型的場景，引入了 Rollover and Shrink API （https://www.jianshu.com/writer#/notebooks/27738831/notes/31623194） 。 這些爲索引和分片的管理方式增加了很多靈活性，特別是對於基於時間的索引。
Rollover and Shrink API 可以指定應包含的文檔和索引的數量和/或應該向其寫入最大期限的文檔。 一旦超出其中一個標準，Elasticsearch 就可以觸發創建新索引，無需停機即可完成寫入。 可以切換到特定大小的新索引，而不是讓每個索引覆蓋特定的時間段，這使得可以更容易地爲所有索引實現均勻的分片大小。如果需要更新數據，在使用此API時，事件的時間戳與其所處的索引之間不再存在明顯的鏈接，這可能會使更新效率大大降低，因爲每次更新都需要在搜索之前進行。
注：如果我們有基於時間的不可變數據，其中數據量可能會隨時間發生顯著變化，就可以考慮使用 Rollover API，通過動態更改每個索引所涵蓋的時間段來實現最佳目標分片大小。 這提供了極大的靈活性，並且可以幫助避免在數據量不可預測時具有太大或太小的分片。
Shrink API 允許我們將現有索引縮小爲具有較少主分片的新索引。 如果在索引期間需要跨節點均勻擴展分片，但這會導致分片太小，一旦索引不再被索引，此 API 可用於減少主分片的數量。 這將生成更大的分片，更適合長期存儲數據。
如果需要讓每個索引覆蓋特定的時間段，並且希望能夠在大量節點上擴展索引，請考慮使用 Shrink API 在索引不再編入索引時減少主分片的數量。 如果最初配置了太多分片，此 API 還可用於減少分片數量。
五、總結
關於如何在索引和分片之間最佳地分佈數據，這將取決於所使用的場景的細節，有時很難確定如何最好地應用可用的建議。
數據分片也是要有相應資源消耗,並且需要持續投入。當索引擁有較多分片時, 爲了組裝查詢結果, ES 必須單獨查詢每個分片(當然並行的方式)並對結果進行合併。所以高性能 IO 設備(SSDs)和多核處理器無疑對分片性能會有巨大幫助。儘管如此, 還是要多關心數據本身的大小,更新頻率以及未來的狀態。在分片分配上並沒有絕對的答案。
參考：
https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
https://segmentfault.com/a/1190000008868585