我對運行多個ES節點的瞭解和理解都是爲了啓用索引複製和縮放。我想知道它是否可以幫助我們更快地爲大量文件建立索引。我有兩個問題,他們如下所示:使用多個ES節點進行快速索引?
問題1:想到使用多個ES節點可以讓我們索引多倍的速度會更準確嗎?
問題2:如果我保持啓用所有節點作爲數據節點,它對索引有什麼影響?另一方面,如果我擁有少數數據節點的非數據節點(例如,一個專用主節點和一個專用客戶節點),它對索引有什麼影響?在速度和縮放方面哪個更好?
我對運行多個ES節點的瞭解和理解都是爲了啓用索引複製和縮放。我想知道它是否可以幫助我們更快地爲大量文件建立索引。我有兩個問題,他們如下所示:使用多個ES節點進行快速索引?
問題1:想到使用多個ES節點可以讓我們索引多倍的速度會更準確嗎?
問題2:如果我保持啓用所有節點作爲數據節點,它對索引有什麼影響?另一方面,如果我擁有少數數據節點的非數據節點(例如,一個專用主節點和一個專用客戶節點),它對索引有什麼影響?在速度和縮放方面哪個更好?
正確答案爲:號
索引的速度將實際上減少,如果你啓用複製(雖然它可能會增加搜索性能)。您可以查看this question以改善索引性能。
Answer2:這取決於(如果沒有複製品,則相同)。
在索引期間,數據將只轉到數據節點。您的羣集狀態將包含有關哪些節點是數據節點並相應地路由請求的信息。性能影響將僅僅是因爲接收請求的節點必須將請求重新路由/轉發到數據節點
如果您在不增加副本數的情況下添加機器,您將在索引期間獲得更好的性能。這並不奇怪,因爲您要添加更多的資源,而要完成的工作量仍然幾乎相同。
在我們的環境中,我們在生產中使用20個節點,在調試時使用5-10個節點。兩種環境都保持相同的數據量。由於ES更新速度(我們使用常規腳本將新文檔合併到現有文檔中)是我們的主要瓶頸,因此我們能夠在生產環境中看到更好的性能,以對抗其他環境。
你已經有一些有用的鏈接在你的問題的其他答案。我們可以補充一點,在我們的案例中,數據上傳改進中最重要的三個因素是:減少refresh_interval,增加merge_factor並使用Elastic-Hadoop插件(我們從Spark上傳數據)處理應用程序上的所有主要數據傳輸優化水平。
https://www.elastic.co/blog/performance-considerations-elasticsearch-indexing –