ElasticSearch優化方式

1. ES每一個分片是一個Lucence實例，因此分片數量不該過多。可是分片數一旦設置好就不能修改，若是設置過少等數據量上去後不能擴容，這時能夠考慮增長索引庫的方式來增長分片數。好比一個索引庫設置20個分片，增長一個索引庫就等於增長了20個分片。應用程序如何知道增長了索引庫呢？這時須要用到ES的別名功能，將一個別名映射到多個實際的索引庫，而應用程序使用別名便可，別名映射的實際索引庫能夠動態修改而對應用程序透明。
2. 能夠從這幾個方面來觀測ES的性能指標：
   • cpu消耗
   • 內存消耗
   • 磁盤io和網絡io
   • jvm的gc狀況
   • es的各個線程池和隊列的負荷
3. Elasticsearch 須要使用大量的堆內存, 而 Lucene 則須要消耗大量非堆內存 (off-heap)。推薦給 ES 設置本機內存的一半, 如32G 內存的機器上, 設置 -Xmx16g -Xms16g ，剩下的內存給 Lucene 。
4. 若是不須要對分詞字符串作聚合計算（例如，不須要 fielddata ）能夠考慮下降堆內存。堆內存越小，Elasticsearch（更快的 GC）和 Lucene（更多的內存用於緩存）的性能越好。
5. 針對io高的優化方式：
   • 儘可能保證一個分片只落在一個硬盤上面，這樣不用跨磁盤讀寫
   • 檢查mapping，es默認會將全部字段寫入_all字段，若是實際業務不須要能夠關閉，減小存儲空間
   • 一樣的，若是不須要存儲原始數據，能夠關閉_source，或者只設置某些必要字段的store屬性 store:true
   • 查詢時只返回必要的數據
   • 採用_doc排序能夠依賴lucence內部id排序，提升排序速度
6. 注意防止腦裂：

   • discovery.zen.minimum_master_nodes > = ( master 候選節點個數 / 2) + 1

7. 若是有節點掛掉，不要急於恢復集羣致使分片數據的大量複製和傳輸，應儘可能等節點本身恢復：

   • gateway.recover_after_nodes: 8 # 等待集羣至少存在 8 個節點 後才能進行數據恢復
     gateway.expected_nodes: 10
     gateway.recover_after_time: 5m # 等待 5 分鐘，或者 10 個節點上線後，才進行數據恢復，這取決於哪一個條件先達到

8. 升級的過程由於須要關閉節點再重啓，這時也要防止es自動恢復的操做：
   • 可能的話，中止索引新的數據
   • 禁止分片分配，這樣es不會自動平衡缺失的分片：

     • PUT /_cluster/settings
           {
               "transient" : {
                   "cluster.routing.allocation.enable" : "none"
               }
           }

   • 這時關閉節點，升級好後再加入集羣，而後重啓分片分配便可：
     • "cluster.routing.allocation.enable" : "all"
9. 能夠考慮在ES前面加一個kafka之類的消息緩存，防止數據量的瞬間暴增對es形成壓力。