Elasticsearch中滾動索引的資源使用情況

Question

我的問題主要是基於以下文章： https : //qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index

本文建議不要在每個節點上使用多個分片，這有兩個原因：

• 每個分片本質上是一個Lucene索引，它消耗文件句柄，內存和CPU資源
• 每個搜索請求將觸摸索引中每個分片的副本。 當分片爭奪相同的硬件資源時，就會出現爭用並且性能會下降

本文主張將滾動索引用於看到很多寫入和更少讀取的索引。

問題：

1. 如果舊的索引保持開放狀態，是否會出現Lucene索引的資源消耗問題？
2. 在一個涉及許多索引和許多碎片的較大時間范圍內進行搜索時，是否會出現爭用問題？
3. 搜索許多小索引與搜索一個大索引相比如何？

我應該提到，在我們的特定情況下，只有一個ES節點，盡管對於SO讀者來說，通常適用的答案當然會更有用。

Answer 1

當涉及到集群規模確定時，要制定出通用的最佳實踐和准則非常困難，因為它取決於很多因素。 如果問五位ES專家，您會得到十個不同的答案。

經過幾年的糾纏和擺弄ES，我發現最適合我的方法是始終從小開始（一個節點，您的應用需要多少索引，每個索引一個分片），加載代表性數據集（理想情況下）您的完整數據集）並進行負載測試直至死亡。 負載測試場景應代表您在生產環境中高峰時段正在（或預期）的實際最大負載。

增加群集的容量（添加分片，添加節點，調整旋鈕等），直到通過負載測試為止，並確保將容量增加幾個百分點，以便將來進行增長。 您不希望現在的生產狀況良好，而是希望從現在開始一年內保持良好狀態。 當然，這將取決於您的數據增長速度，而且不太可能以100％的把握預測從現在開始一年之內的情況。 出於這個原因，一旦我的負載測試通過，如果我希望數據呈指數級增長，通常我會在幾個月或一年內必須重新訪問群集拓撲的情況下，將容量增加50％以上。

因此，回答您的問題：

1. 是的，如果舊索引保持打開狀態，則會消耗資源。
2. 是的，您搜索的索引越多，遍歷每個索引的每個分片所需要的資源就越多。 跨多個滾動索引（尤其是在單個節點上）的別名要小心
3. 這個答案太廣泛了，因為它又取決於我們正在討論的數據量以及您要發送的查詢類型，它是否使用聚合，排序和/或腳本編制等

Answer 2

如果舊的索引保持開放狀態，是否會出現Lucene索引的資源消耗問題？

是。

在一個涉及許多索引和許多碎片的較大時間范圍內進行搜索時，是否會出現爭用問題？

是。

搜索許多小索引與搜索一個大索引相比如何？

當ES搜索索引時，它將為每個分片（無論是副本還是主要）獲取一個副本，並要求該副本對自己的數據集運行查詢。 搜索分片將使用節點具有的search線程池中的一個線程（該線程池是每個節點）。 一個線程基本上意味着一個CPU內核。 如果您的節點有8個核心，則在任何給定時間，該節點都可以同時搜索8個分片。

假設您在該節點上有100個分片，而您的查詢將要搜索所有這些分片。 ES將啟動搜索，所有100個分片將爭奪8個核心，因此某些分片將不得不等待一段時間（微秒，毫秒等）才能獲得這8個核心的份額。 擁有很多分片意味着每個文檔上的文檔更少，因此每個文檔的響應時間可能更快。 但是隨后發起請求的節點需要收集所有分片的響應並匯總最終結果。 因此，當最慢的分片最終以其結果集響應時，響應將准備就緒。

另一方面，如果索引很大而分片很少，那么這些CPU內核就沒有太多爭用了。 但是碎片有很多工作需要單獨完成，要花更多的時間來返回單獨的結果。

選擇分片數量時，需要考慮許多方面。 但是，對於某些粗略的指導原則，每個分片30GB是一個很好的限制。 但這不適用於每個人和每個用例，並且本文沒有提及。 例如，如果您的索引使用父/子關系，則每個分片30GB可能太多，而單個分片的響應時間可能太慢。

---

您從上下文中取消了此操作： “本文建議不要在每個節點上使用多個分片” 。 不，本文建議人們先考慮一下構建索引碎片的各個方面。 這里的一個重要步驟是測試步驟。 請先測試您的數據，然后再確定需要多少個分片。

您在“滾動指標”一文中提到過，我假設基於時間的指標。 在這種情況下，一個問題是關於保留期 （需要多長時間的數據）。 根據該問題的答案，您可以確定將擁有多少個索引。 知道您將擁有多少索引將為您提供分片的總數。

另外，對於滾動索引，您需要注意刪除過期的索引 。 看看館長對此。