翻譯自：Elasticsearch Cluster Sizing and Performance Tuning
地址：https://www.elastic.co/cn/blog/found-sizing-elasticsearch
集羣應該有多少個節點?應該創建多少個副本?爲了獲得最佳的搜索性能，分片(Shard)的最佳平均大小是多少？諸如此類的問題只有你自己知道答案。
沒有人知道你的數據和查詢結構，你使用的硬件，你的吞吐量。沒有數學公式，也沒有理論計算方法。如果你帶着這樣的期望而來，我很抱歉讓你失望。但是別擔心，你可以自己回答。
數據的大小
如您所知，由於分佈式體系結構中的硬件限制，數據被劃分爲更小的塊，並分佈在不同的節點上。這些小片段稱爲分片。實際上，當其中一個節點發生故障時，與原始節點完全相同的分片仍保留在備用中。這些分片稱爲副本。
分片的最佳數量是多少?
每個請求在每個分片的單個線程中處理。如果您有多個分片，則可以並行處理查詢。將分片數量增加到一定程度可能會對性能產生積極影響，但這並不完全正確。如果您有很多小分片，則過一會兒，將有大量並行任務需要在隊列中等待。當同時接收到多個請求時，這將降低性能。
分片是Lucene索引，它通過一個或多個段來將數據存儲在磁盤上。較大的段能更有效地存儲數據。因此，增加分片的數量可能並不總是一個好主意。
您可以通過在單節點羣集中創建分片來進行測試。考慮一下索引的大小和我在下一節中提到的平均分片大小，一次增加一個分片。您可以自己找到理想分片的數量。
分片的最佳平均大小是多少?
在這個問題上沒有絕對的準則。您應該爲自己選擇一個起點，然後嘗試找到最佳尺寸。Elasticsearch官網的建議如下：
- 分片的平均大小應在幾GB到幾十GB之間。
- 確定用例的最佳大小的最佳方法是使用您自己的數據和查詢進行測試。
副本的最佳數量是多少?
考慮到硬件故障，建議至少有一個副本。副本提高了搜索性能，但並不總是如此。這取決於您的硬件和索引的行爲(大量寫入或大量搜索)。如果您的索引寫入很多，那麼增加副本的數量不是一個好主意。由於數據複製過程會導致資源使用增加，並且搜索性能會下降。
讓負載更加均衡
Elasticsearch自己管理負載均衡。但是，我們必須考慮要有多少個節點，有多少個分片和副本，並且必須在它們之間建立一定比例以實現均勻的負載分配。
此時，我們應該確保節點的數量和分片(主分片+副本)的數量是成比例的。
例如，如果集羣中有5個節點，那麼分片的數量應該是5的倍數。這對於Elasticsearch確保適當的負載均衡非常重要。如果節點之間存在不均衡的負載分佈，那麼具有更多分片的節點的資源使用率將更高，並且瞬時平均負載將高於其他節點。換句話說，其他節點上的資源將使用得更少，而具有更多分片的節點將使用得更多。
具有更多分片的節點會收到更多請求。一段時間後，這些節點將無法及時處理請求，傳入的請求將在隊列中等待。在這種情況下，這些節點成爲系統的瓶頸，增加了所有請求的響應時間。因爲傳入的請求必須通過所有分片才能完成。例如下圖，每個主碎片共有6個節點(DG_Data1…DG_Data6)、9個主分片(0…8)和2個副本，主分片共有18個副本。我們有6個節點和27個分片。27/6 = 4.5它不是整數。這意味着有些節點有5個分片，有些節點有4個分片。因此，與其他節點相比，節點DG_Data2、DG_Data4和DG_Data6的平均負載更高。因此，如果我們將主分片的數量增加到10個，我們將在集羣中得到均勻的負載分佈。
假設我們向該集羣發送了一個請求。將從0到8的所有分片中搜索與該請求匹配的文檔。那麼將訪問多少個節點？在此羣集中，必須至少訪問3個節點才能完成搜索請求。 Elasticsearch將確定將訪問哪些節點。例如，節點將是DG_DATA1（4,7），DG_DATA2（0,1,3,5），DG_DATA5（2,6,7,8）。
我們的態度和目標應該是通過訪問儘可能少的節點來完成我們的請求。
這並不意味着增加副本的數量直到訪問一個節點就能完成請求，這是非常危險的。因爲將數據複製到副本會浪費資源。
確定索引的行爲
索引的結構及其映射(mapping)非常重要。首先，您需要確定索引是哪種索引。是大量寫入還是大量讀取？其次，我們應該將文檔設計得儘可能平坦。數據去範式化可能是一個選擇，如果我們不關心它的負面影響。如果我們無法設計平面文檔，則根據索引的行爲，我們可能更喜歡嵌套(nested)或子(join)文檔類型。
譯者注：這裏的平坦/面指的是設計mapping的時候，儘量將數據打平，比如之前在關係型數據庫中是關聯表，在elasticsearch中應該冗餘到一個文檔中。
讀密集型索引
如果來自索引的大多數請求都是搜索請求，我們就可以說索引是讀密集型的。換句話說，搜索操作的數量大於索引操作。比如：電商中的產品的索引。一個普通的電商應用更新的產品非常少，但是大量的用戶在搜索產品。
與子文檔相比，嵌套文檔可以提高搜索性能。但是不要忘記將數據寫入嵌套文檔是非常昂貴的。
增加副本的數量可以在一定程度上提高性能。在某些情況下，由於硬件的限制，性能會下降。您可以通過逐個增加副本的數量來找到這個斷點。您可以使用諸如JMeter、Apache Bench ab之類的工具來度量搜索性能，同時增加副本的數量。
寫密集型索引
在這些索引中，索引操作的數量大於搜索操作的數量。在包含此類索引的羣集中，資源通常用於寫入數據。如果增加副本的數量，則寫入分片的文檔將被複制到副本，因此寫入過程將增加。這將導致資源使用量增加。
子文檔讀得快，寫得慢。因此，這種類型的索引更受歡迎。
只要獲取你需要的數據
只需提取所需的數據即可。檢索不必要的數據會增加網絡和計算的成本。不要索引不需要的數據。
在查詢中儘可能有效地使用"from","size"和"source"屬性。請記住，服務器在嘗試寫入數據時也會使用資源。
使用best_compression壓縮_source數據。
監控索引大小
索引的大小可能會隨時間增長，這可能要求您對集羣或硬件進行一些更改。
定期Reindex索引
特別是在寫密集型索引中，索引大小會隨着時間增加。這是由於更新的文檔。實際上，在Elasticsearch中，文檔不會更新，因爲它們是不可變的。因此，使用新數據創建了另一個文檔，並且該文檔的版本增加了一個。重新索引索引時，新索引將包含最新版本的文檔。因此索引大小將減小。
強制合併
在Elasticsearch中，所有分片都是Lucene索引。Lucene索引由一個或多個文件組成。強制合併使我們可以合併這些文件並導致形成更大的段。較大的段能更有效地存儲數據。
刷新間隔
刷新時間是建立索引後可搜索數據所需的時間。 這就是爲什麼Elasticsearch近實時，而不是實時的原因。
如果您的數據不經常更改，並且您不需要實時數據，則應增加或不使用刷新間隔。 如果您根本不希望刷新，則可以將其分配爲-1。刷新是一項昂貴的任務。 較小的刷新時間可能會對搜索性能產生不利影響。
初始索引時，應將刷新間隔設置爲-1。
作爲一種選擇，您可以在建立文檔索引時發送刷新參數。 與刷新整個索引不同，只刷新該文檔更有效。
PUT /test/_doc/1?refresh
{
"test": "test"
}
譯者注：refresh_interval設置爲-1，並不意味着不進行進行refresh操作。
優先過濾上下文而不是查詢
如果您在搜索中不需要評分功能，請避免使用查詢。 您應該首選過濾器上下文。 由於過濾器已緩存且不會影響得分，因此比查詢要快。
https://www.elastic.co/guide/en/elasticsearch/reference/7.6/query-filter-context.html
初始索引時禁用副本
索引文檔時，首先將其寫入主分片，然後將其複製到副本。複製到副本是一個代價高昂的操作，它限制了初始索引。因此，您應該禁用副本，直到初始索引完成。
使用批量請求
在索引操作中發送批量請求，尤其是在初始索引中。 批量請求比單個請求具有更好的性能。 請注意，請求限制爲100 MB。
監控您的集羣和查詢
您應該使用性能監視工具（例如New Relic）監視集羣，該工具具有Elasticsearch插件。 您可以檢查節點的異常行爲，平均負載，響應時間以及更改的影響。 通過_profiling API運行已識別的搜索，以查看各個組件的耗時。
將ElasticClient對象用作Singleton
建議在應用程序的生命週期內使用單個客戶端和連接設置實例。 客戶端是線程安全的，因此可以跨線程共享實例。 從單例中受益的實際移動部分是ConnectionSettings，因爲緩存是按ConnectionSettings進行的。
https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/lifetimes.html
首選去範式化而不是嵌套類型（Nested Type）
如果您對查詢進行概要分析，則可以確定將嵌套文檔與父文檔連接在一起是否需要花費大量時間。 在這種情況下，像在Vivek Mittal的情況下一樣，非範式化可以提高性能。 我在下面分享了作爲參考。
https://blog.gojekengineering.com/elasticsearch-the-trouble-with-nested-documents-e97b33b46194
結論
在我看來，在elasticsearch，數據索引和搜索上創建索引非常簡單。 困難的部分是性能和設計。 在本文中，我想與您分享我的經驗。 儘管我不希望您回答所有問題，但這將提供一個起點。 我的建議是根據此處的信息測試所有內容，以找到適合您的最佳配置。 相信我，即使花費時間，您也會找到理想的解決方案。
譯者：
對於集羣規模的確定，以寫入密集型來看，應該可以通過業務量的預估確定想要的吞吐量，吞吐量/單臺機器寫入速度=》需要的節點數。
與kafka集羣節點數量預估類似，不過kafka集羣還需要考慮consumer的消費能力。
個人微信公衆號：
作者：jiankunking 出處：http://blog.csdn.net/jiankunking