Elasticsearch實踐指南

http://nginxs.blog.51cto.com/

   從2014年到現在接觸ES（Elasticsearch）已經兩年多了，感觸良多尤其ES的開盒即用特性完全區別于之前接觸復雜的hadoop和solor。ES不需要你對它了解就能很快入門，而且ES的實時搜索，自動拓展，自愈功能深深吸引我。最近很多朋友也開始使用向我問了很多常見問題，我在這總結了一些使用中踩過的坑希望大家對ES有更多的了解。

簡介

  Elasticsearch是基于Lucene開發的一個準實時搜索服務，搜索延時在秒級。ES存儲主要通過自身解析json數據，然后json里面的key映射為Lucene里面的字段，使用lucene進行搜索和索引。ES不僅支持普通的全文搜索和按詞搜索，還支持模糊匹配，近義詞搜索，聚合，排序，geo等特性。ES的開源特性也使得它社區活躍，版本迭代更新迅速，現在主要分為2.0和5.0兩個大版本，建議大家使用最新的5.0版本會更容易升級和獲取一些更高級的特性。

下面是一些上線或者線上使用Elasticsearch需要了解的特性

CPU

es主要依賴于硬盤和內存，所以對CPU要求不高，一般8核就行，如果并發比較多可以適當增加。

硬盤

    硬盤決定你es寫入讀取數據速度，磁盤建議用15k的機械硬盤,并配置為raid0，如果集群節點<5個，請使用raid5，這樣保證一個硬盤故障不會影響服務。雖然es本身可以通過分片去保證數據的冗余，但是es每個節點大量數據爬行還是對較小的集群有一定影響。（土豪直接上SSD，需要正確配置I/O調度程序，陣列卡建議>h710，否則就像ssd跑車上安裝一個拖拉機引擎）

內存優化

1. ES的內存使用分為兩部分ES緩存和Lucene通過內核緩存加速一些數據。

2  . 如果服務器內存  `nG > 64G`,ES的內存盡量設置低于32G，建議最大31G. 因為es使用“內存指針壓縮”技術，一旦內存內存大于32G這項技術將失效，內存有效使用只有原來的60%~70%。你不必為內存浪費而擔心，因為lucene會通過系統把一些聚合和排序的數據緩存起來方便你快速查詢使用。

3 .如果服務器內存  `nG < 64G`，建議給ES分配  內存 (n-2)/2G.  首先2G是給系統預留，然后es和lucene

4 . 如果你想繼續你的實時查詢，盡量不要使用swap(交換分區)，建議關閉系統swap使用

網絡

1. 建議千兆光纖，高速網絡可以保證集群節點故障后快速恢復，以及添加節點后快速再平衡。

2. 盡量不要跨機房，除非需要災備，或者有足夠的帶寬，否則你將迎來es節點數據同步的無限等待。

數據文檔結構數據

因為所有es節點需要實時同步‘索引列表’，‘文檔類型’，‘字段名’等信息，所以在節點數固定的情況下索引，字段名等不要太多否則會給es的master節點造成壓力。

簡單舉例：我要保存用戶提交字段和信息，各個字段名因為是動態生成，理論上是無上限的，但是es的master要實時的同步這些字段信息到每個節點，如果現在只有100個字段還好，要是有1000個字段就會產生問題，如果有2000個字段就嚴重到無法使用了，當然索引的數量也是同樣的意義，

索引優化

es的每個索引默認總計10個分片，5個主分片，每個主分片對應一個副分片。

1 .  當然很多情況下這個無法滿足你實際需求，例如你的集群有8個節點，計劃單個索引超過100億條數據，為了讓這個索引查詢速度快一點，你可以增加索引分片數量：1.增加主副分片對數，增加副分片的數量。這樣不僅加速搜索還增加了數據的冗余。

2 . 一些只讀的索引可以使用‘optimize的API’進行把每個索引合并為一個單獨數據段，這樣可以節省資源加速操作，但是需要注意這樣會消耗一定IO，如果當前節點請求繁忙，不要進行此類操作。

3 . 在使用索引的時候盡量使用索引別名，在以后索引重建或者索引名變更時避免宕機維護。

操作優化

1. 并發請求不要一次太多，否則超過es內部隊列長度將失敗。

2. 如果一次一定要提交太多任務寫入盡量添加失敗判斷，一旦失敗等待3~5秒重試操作，否則數據將丟失。

3.文檔盡量一次寫入不要更改和刪除，因為es的更改和刪除只是給舊數據做了一個標簽，查詢的時候依然會查詢匹配，只是不在結果中計算。

故障處理

1. 如果有ES集群單節點掉出集群不要慌張ES有自愈的能力，你只需要保證集群穩定，磁盤充足即可自動修復。

2. 如果集群突然大多節點掉出集群，且出現分片丟失，那你需要考慮分片丟失是否能夠接受，如果不能你可以通過同時停止全部節點，并啟動全部節點進入時間門來嘗試恢復全部數據。

3. 正常情況下少數節點掉出集群，導致一些只讀的分片丟失，可以把這些掉出的節點重新加入回集群即可恢復分片。

   http://nginxs.blog.51cto.com/