elasticsearch叢集的使用總結

目前在維護的elasticsearch叢集儲存了超過百億的資料，日常呼叫也超過幾千萬，這裡總結一下使用中的心得體會。總的來說elasticsearch的分散式效能強勁，但是也需要使用者深入的理解原理，精心維護，合理使用。優化上不僅有elasticsearch設定合理的引數，還有使用上的約束。

引數優化

關閉系統的swap

swap虛擬記憶體，安裝elasticsearch的伺服器都是高配服務，全部關閉虛擬記憶體

master和data節點分開部署

設定合理的記憶體大小

官方建議的記憶體大小最小為1G,最大不要超過32G,

Don’t set Xms and Xmx to above the cutoff that the JVM uses for compressed object pointers (compressed oops); the exact cutoff varies but is near 32 GB. You can verify that you are under the limit by looking for a line in the logs like the following:

heap size [1.9gb], compressed ordinary object pointers [true]
 

32G 的大小涉及java的指標壓縮，理論上也可以設定超過32G，但是需要分配更多的記憶體。並沒有實踐過。我們將記憶體大小設定為31G

修改檔案控制代碼限制

這裡的如果太小，啟動時也會提示檔案控制代碼數太小。不過修改檔案控制代碼數有兩種方式，一種是永久生效的，需要伺服器重啟才能生效；一種是臨時生效的，不需要重啟即可生效，記得兩種都修改，避免伺服器故障重啟後，服務無法啟動

效能更高的磁碟

建議單獨分配磁碟只給elasticsearch例項使用，如果有條件，直接ssd

同一臺機器安裝多個例項

由於部署elasticsearch的機器是高配服務，可以在上面部署多個節點充分利用機器效能，安裝多個例項，可以在elasticsearch啟動的命令中指定不同例項的配置檔案即可，無需複製多個包，可以減少安裝elasticsearch外掛的管理成本

使用優化

限制返回大資料

elasticsearch並不是適合返回大量的資料，更適合的是匹配查詢條件的少量資料，因此我們要求所有的明細查詢都必須有時間引數，可以很好的避免返回大量資料（elasticsearch預設也有深翻頁限制，最多10000條）

集合拆分

官方建議的單個分片不要超過40g, 曾經因為意外產生過一個超大的集合，每次寫入都會出現查詢超時和伺服器告警，接著就是運維的連環call，超大的分片的集合會給elasticsearch的節點帶來巨大的壓力，可以通過按日或者按月來拆分集合

只存索引不存資料

在新建elasticsearch集合時，指定配置source 設定為false，在elasticsearch中只存索引，將資料儲存在hbase中，利用hbase的儲存效能減輕elasticsearch的儲存壓力，將elasticsearch和hbase搭配使用，一條資料在寫入時，在elasticsearch中只儲存索引資料和hbase中的rowkey（查詢條件相關的欄位），在hbase中儲存具體的資料，查詢時根據查詢條件在es中查詢到rowkey，在用rowkey去hbase中查詢原始資料，再返回給請求方，減少elasticsearch的儲存壓力，不過這種方式需要開發者對elasticsearch和hbase都比較熟悉，要求相對高一點，這也是一種常見的hbase的二級索引方案