同時將數據以恆定速率推送到Elasticsearch的多個索引上時的性能問題

Question

我們正在對目前正在構建的系統上的彈性搜索進行彈性搜索時遇到一些性能問題或異常情況。

要求： 我們需要爲我們的多個客戶捕獲數據，他們將近實時地查詢和報告他們。所有收到的文檔都是相同的格式，具有相同的屬性並且處於扁平結構（所有字段都是主類型，沒有嵌套對象）。我們希望保持每個客戶的信息彼此分開。

頻率上接收和查詢數據： 我們以每秒200到700文件波動率接收數據，爲每一個客戶 - 與一天中的高峯之中。 查詢將主要集中在每個客戶大約1200萬個文檔上 - 直方圖/百分位可以顯示隨時間變化的模式，偶爾可以找到原始文檔檢索以查明特定時間點發生的情況。我們的目標是以50至100個客戶的不同費率插入文檔 - 最小的文檔可以是20個文檔/秒，最大的文檔可以以1000個文檔/秒的速度達到峯值，持續幾分鐘。

我們如何存儲數據： 每個客戶每天有一個索引。例如，如果我們有5個客戶，那麼整週就會有35個索引。我們每天打破它的原因是因爲它大多是最近兩次偶爾會被其他人查詢。我們也這樣做的，所以我們可以客戶的獨立刪除舊的指標（有些人可能希望保留7天，約14天的數據）的

我們是如何插入： 我們正在分批發送數據10到2000 - 每秒。一個文件大約900bytes原始。

環境 AWS C3-大 - 3個節點 所有指標與10個碎片創建了2副本的測試目的 兩個Elasticsearch 1.3.2和1.4.1

我們已經注意到：

如果我只將數據推送到一個索引，當插入速率大約爲每秒100個文檔時，對於每個批插入的響應時間在80到100ms之間開始。我把它加大了，我可以在插入速率接近每秒1秒之前達到1600，當我將它增加到接近1700時，由於併發插入，它會在某個時間點撞到牆上，時間會旋轉到4或5秒鐘。說，如果我減少插入的速度，Elasticsearch恢復很好。 CPU使用率隨着費率增加而增加。

如果我同時推到兩個索引，我總共可以達到1100，並且CPU每秒約900個文件達到93％。 如果我同時推送3個索引，我總共可以達到150個，CPU達到95％到97％。我嘗試了很多次。有趣的是，當時的響應時間大約是109ms。我可以將負載增加到900，響應時間仍然在400到600左右，但CPU保持不變。

問：

綜觀我們的要求，上述調查結果，是設計方便了什麼要求？我能做些什麼測試來了解更多？是否有任何設置需要檢查（並更改）？

Answer 1

過去幾年裏，我一直在AWS上的成千上萬的Elasticsearch集羣上承載了https://bonsai.io，並且有許多容量規劃會話聽起來像這樣。

首先，這聽起來像你有一個相當不錯的集羣設計和測試裝備在這裏。我的第一個直覺就是你正在接近你的c3.large實例的極限，並且很快就會碰到c3.xlarge（或者更大）。

如果租戶相對較少，則每位租戶每天的索引可能是合理的。您可以考慮爲所有租戶每日索引，使用過濾器將搜索集中在特定租戶上。除非丟棄舊數據明顯節約成本，否則過濾器應該足以強制實施數據保留窗口。

分割每個租戶索引的主要好處是將您的租戶遷移到不同的Elasticsearch集羣之間。如果你有一些租戶使用量比其他用戶大得多，這可能會有所幫助。或者將Elasticsearch集羣狀態管理的潛力降低爲所有租戶的單點故障。

需要注意的其他一些事項可能有助於解釋您所看到的性能差異。

最重要的是，索引是令人難以置信的CPU瓶頸。這是有道理的，因爲Elasticsearch和Lucene基本上只是真正的花哨的字符串解析器，而且你正在發送一堆字符串。 （樁在這裏是一個合法的計量單位，對吧？）您的主要瓶頸將是CPU核心的數量和速度。

爲了在建立索引時充分利用CPU資源，您應該考慮使用的主分片的數量。我建議從三個主要分片開始，將CPU負載均勻分佈到羣集中的三個節點上。

對於生產，你幾乎肯定會在更大的服務器上運行。目標是針對您的峯值索引需求的總CPU負載最終低於50％，因此您在處理搜索時需要額外的開銷。聚合也相當需要CPU。額外的性能開銷也有助於優雅地處理任何其他不可預見的情況。

你提到同時推送到多個索引。在批量更新到Elasticsearch時，我會避免併發性，而採用Bulk API進行批量更新。您可以批量加載羣集級別爲/_bulk端點的多個索引的文檔。讓Elasticsearch在內部管理併發性，而不會增加解析更多HTTP連接的開銷。

這只是對性能基準測試主題的快速介紹。 Elasticsearch文檔在Hardware上有一篇很好的文章，它也可以幫助您規劃您的羣集大小。