0鼻吮、引言
本文翻譯自Elasticsearch20170918熱乎的官方博客，原作者：Christian Dahlqvist较鼓。 在構建Elasticsearch集群的初期如果集群分片設置不合理椎木，可能在項目的中后期就會出現(xiàn)性能問題。
Elasticsearch是一個非常通用的平臺博烂，支持各種各樣的用例香椎，并且為數(shù)據(jù)組織和復制策略提供了巨大靈活性。這種靈活性使得作為ELK新手的你將數(shù)據(jù)組織成索引和分片變得困難禽篱。雖然不一定會在首次啟動時出現(xiàn)問題畜伐，但由于數(shù)據(jù)量隨時間的推移，可能會導致性能問題谆级。集群所擁有的數(shù)據(jù)越多烤礁，糾正問題就越困難讼积，甚至有時可能需要重新索引大量數(shù)據(jù)肥照。
當我們遇到遭遇性能問題的用戶時脚仔，可以追溯到關于數(shù)據(jù)索引的數(shù)據(jù)和群集數(shù)量的問題并不罕見。 對于涉及multi-tenancy或使用基于時間的索引的用戶尤其如此舆绎。 在與用戶討論這個問題時（會議鲤脏、論壇形式），引申出的一些最常見的問題是：
1）“我應該有多少個分片吕朵？”
2）“我的分片應該有多大”猎醇？
這篇博客文章旨在幫助您回答這些問題，并為使用基于時間的索引的使用案例（ 日志記錄或安全分析 ）提供實用的指導努溃。
1硫嘶、什么是分片？
在開始之前梧税，讓我們約定文章中用到的一些概念和術語沦疾。
Elasticsearch中的數(shù)據(jù)組織成索引。每一個索引由一個或多個分片組成第队。每個分片是Luncene索引的一個實例哮塞，你可以把實例理解成自管理的搜索引擎，用于在Elasticsearch集群中對一部分數(shù)據(jù)進行索引和處理查詢凳谦。
【刷新】當數(shù)據(jù)寫入分片時忆畅，它會定期地發(fā)布到磁盤上的新的不可變的Lucene段中，此時它可用于查詢尸执〖铱——這被稱為刷新。更詳細的解讀請參考：
【合并】隨著分段數(shù)（segment）的增長如失，這些segment被定期地整合到較大的segments肆饶。 這個過程被稱為合并（merging）。
由于所有段都是不可變的岖常， 因為新的合并段需要創(chuàng)建驯镊，舊的分段將被刪除 ，這意味著所使用的磁盤空間通常在索引時會波動竭鞍。 合并可能資源相當密集板惑，特別是在磁盤I/O方面。
分片是Elasticsearch在集群周圍分發(fā)數(shù)據(jù)的單位偎快。 Elasticsearch在重新平衡數(shù)據(jù)時 （例如 發(fā)生故障后） 移動分片的速度 取決于分片的大小和數(shù)量以及網(wǎng)絡和磁盤性能冯乘。
提示：避免有非常大的分片，因為大的分片可能會對集群從故障中恢復的能力產(chǎn)生負面影響晒夹。 對于多大的分片沒有固定的限制裆馒，但是分片大小為50GB通常被界定為適用于各種用例的限制姊氓。
2、索引有效期（ retention period ）
由于段是不可變的喷好，更新文檔需要Elasticsearch首先查找現(xiàn)有文檔翔横，然后將其標記為已刪除，并添加更新的版本梗搅。刪除文檔還需要找到文檔并將其標記為已刪除禾唁。因此，刪除的文檔將繼續(xù)占據(jù)磁盤空間和一些系統(tǒng)資源无切，直到它們被合并荡短，這將消耗大量的系統(tǒng)資源。
Elasticsearch允許從文件系統(tǒng)直接刪除完整索引哆键，而不必明確地必須單獨刪除所有記錄掘托。這是迄今為止從Elasticsearch刪除數(shù)據(jù)的最有效的方式。
提示：盡可能使用基于時間的索引來管理數(shù)據(jù)籍嘹。根據(jù)保留期（retention period闪盔，可以理解成有效期）將數(shù)據(jù)分組∝停基于時間的索引還可以輕松地隨時間改變主分片和副本分片的數(shù)量（以為要生成的下一個索引進行更改）锭沟。這簡化了適應不斷變化的數(shù)據(jù)量和需求。3识补、索引和分片不是空閑的族淮？
【集群狀態(tài)】對于每個Elasticsearch索引，其映射和狀態(tài)的信息都存儲在集群狀態(tài)凭涂。 這些集群狀態(tài)信息保存在內存中以便快速訪問祝辣。 因此，如果在集群中擁有大量索引切油，可能導致大的集群狀態(tài)（特別是如果映射較大）蝙斜。 所有更新集群狀態(tài)操作為了在集群中保證一致性，需要通過單個線程完成澎胡，因此更新速度將變慢孕荠。
提示：為了減少索引數(shù)量并避免大的乃至非常龐大的映射，請考慮將相同索引結構的數(shù)據(jù)存儲在相同的索引中攻谁，而不是基于數(shù)據(jù)的來源將數(shù)據(jù)分割成獨立的索引稚伍。 在每個索引的索引數(shù)量和映射大小之間找到一個很好的平衡很重要。**
每個分片都有數(shù)據(jù)需要保存在內存中并使用堆空間戚宦。 這包括在分片級別保存信息的數(shù)據(jù)結構个曙，也包括在段級別的數(shù)據(jù)結構，以便定義數(shù)據(jù)駐留在磁盤上的位置受楼。 這些數(shù)據(jù)結構的大小不是固定的垦搬，并且將根據(jù)用例而有所不同呼寸。
然而，段相關開銷的一個重要特征是它與分段的大小不成正比猴贰。 這意味著與較小的段相比对雪，較大的段的每個數(shù)據(jù)量具有較少的開銷，且這種差異很大糟趾。
【堆內存的重要性】為了能夠每個節(jié)點存儲盡可能多的數(shù)據(jù)慌植，重要的是盡可能多地管理堆內存使用量并減少其開銷甚牲。 節(jié)點擁有的堆空間越多义郑，它可以處理的數(shù)據(jù)和分片越多。
因此丈钙，索引和分片從集群的角度看待不是空閑的非驮，因為每個索引和分片都有一定程度的資源開銷。
提示1：小分片會導致小分段(segment)雏赦，從而增加開銷劫笙。目的是保持平均分片大小在幾GB和幾十GB之間。對于具有基于時間的數(shù)據(jù)的用例星岗，通程畲螅看到大小在20GB和40GB之間的分片。
提示2：由于每個分片的開銷取決于分段數(shù)和大小俏橘，通過強制操作迫使較小的段合并成較大的段可以減少開銷并提高查詢性能允华。一旦沒有更多的數(shù)據(jù)被寫入索引，這應該是理想的寥掐。請注意靴寂，這是一個消耗資源的（昂貴的）操作，較為理想的處理時段應該在非高峰時段執(zhí)行召耘。
提示3：您可以在集群節(jié)點上保存的分片數(shù)量與您可用的堆內存大小成正比百炬，但這在Elasticsearch中沒有的固定限制。 一個很好的經(jīng)驗法則是：確保每個節(jié)點的分片數(shù)量保持在低于每1GB堆內存對應集群的分片在20-25之間污它。 因此剖踊，具有30GB堆內存的節(jié)點最多可以有600-750個分片，但是進一步低于此限制衫贬，您可以保持更好德澈。 這通常會幫助群體保持處于健康狀態(tài)。
4祥山、分片的大小如何影響性能圃验？
在Elasticsearch中，每個查詢在每個分片的單個線程中執(zhí)行缝呕。然而澳窑，可以并行處理多個分片斧散，并可以在相同分片上執(zhí)行多個查詢和聚合。
【小分片的利弊】這意味著摊聋，在不涉及高速緩存時鸡捐，最小查詢延遲將取決于數(shù)據(jù)、查詢的類型麻裁、分片的大小箍镜。查詢大量小分片將使得每個分片的處理速度更快，但是隨著更多的任務需要按順序排隊和處理煎源，它不一定要比查詢較小數(shù)量的更大的分片更快色迂。如果有多個并發(fā)查詢，則有很多小碎片也會降低查詢吞吐量手销。
提示：從查詢性能角度確定最大分片大小的最佳方法是使用逼真的數(shù)據(jù)和查詢進行基準測試（真實數(shù)據(jù)而非模擬數(shù)據(jù)）歇僧。 始終使用查詢和索引負載進行基準測試，代表節(jié)點在生產(chǎn)中需要處理的內容锋拖，因為單個查詢的優(yōu)化可能會產(chǎn)生誤導性的結果诈悍。
5、如何管理分片大惺薨！侥钳？
當使用基于時間的索引時，每個索引傳統(tǒng)上都與固定的時間段相關聯(lián)柄错。 每日索引非常普遍舷夺，經(jīng)常用于持有時間區(qū)間短或每日量大的數(shù)據(jù)。 這些允許數(shù)據(jù)期限期間以良好的粒度進行管理鄙陡，并且可以方便地對每天更換調整volumes冕房。
時間周期長的數(shù)據(jù)，特別是如果每日不保存每天的索引數(shù)據(jù)趁矾，則通常會使用每周或每月的保存的碎片大小的增加耙册。 這減少了隨著時間的流逝需要存儲在群集中的索引和碎片數(shù)量大小（直譯有點費勁此處）毫捣。
提示：如果使用固定期限的時間索引數(shù)據(jù)详拙，可以根據(jù)時間周期和預期數(shù)據(jù)量調整所涵蓋的時間范圍，以達到目標分片大小蔓同。
【均勻更新&快速變化的索引數(shù)據(jù)對比】具有固定時間間隔的基于時間的索引在數(shù)據(jù)量合理預測并且變化緩慢的情況下工作良好饶辙。 如果索引率可以快速變化，則很難保持均勻的目標分片大小斑粱。
為了能夠更好地處理這種情況弃揽，推出了Rollover和Shrink API。這些增加了如何管理索引和分片的靈活性，尤其適用于基于時間的索引矿微。
此處省略了 Rollover和Shrink API的介紹痕慢。（建議查詢官網(wǎng)補齊概念再深入）
6、結論
這篇博客文章提供了有關如何在Elasticsearch中最好地管理數(shù)據(jù)的提示和實用指南涌矢。 如果您有興趣了解更多掖举，推薦閱讀Google搜索 “Elasticsearch: the definitive guide” （有點舊，值得閱讀）娜庇。
然而塔次，關于如何最好地在索引和分片上分發(fā)數(shù)據(jù)的許多決策將取決于用例細節(jié)，有時可能難以確定如何最佳地應用可用的建議名秀。
文章提及的幾個核心建議清單如下励负，以回答文章開頭的提問。
1） “我應該有多少個分片泰偿？
” 答： 每個節(jié)點的分片數(shù)量保持在低于每1GB堆內存對應集群的分片在20-25之間熄守。
2） “我的分片應該有多大”蜈垮？
答：分片大小為50GB通常被界定為適用于各種用例的限制耗跛。
