首先對不必要的字段不做分詞也就是不做索引，禁止內存交換
1.shard
- 一個Shard就是一個Lucene實例，是一個完整的搜索引擎。
- 分片數過多會導致檢索時打開比較多的文件，多臺服務器之間通訊成本加大。
- 而分片數過少會導至單個分片索引過大，所以檢索速度也會慢。
-
建議單個分片最多存儲10G-20G左右的索引數據，並且儘量集羣的所有節點都分片數一致，不要出現分片數不一樣導致的一個實例負載過大，等待合併的時間變長；
2.shard副本
- 使用副本的優點：數據備份，提高對大索引的查詢效率，建議副本在1-2個左右，過多的副本會延遲合併時間以及磁盤使用率提高，性價比不高
- 當要導入大量數據時，設置副本爲0，之後動態添加副本 //（ 效率較大）當導入大量索引時，設置了副本數，es會同時打開副本同步，消耗系統資源，同時需要額外提供主副之間的通信
- 設置副本數curl -XPOST 'http://localhost:9200/{_index}/_settings' -d '{"index":{"number_of_replicas":1}}'
3.segment
- 每個分片包含多個segment，每一個segment都是一個倒排索引；在查詢的時，會把所有的segment查詢結果彙總歸併後最爲最終的分片查詢結果返回； segment越多,加載到內存中的segment越多，佔用segment memory越多，查詢性能可能就會下降，因此應該合併小的segment，減小segment數，提高檢索的segment數來提高查詢效率；創建索引的時候，elasticsearch會把文檔信息寫到內存buffer中，elasticsearch定期會執行flush操作，把segment持久化到磁盤上，索引越大，segment越多，查詢效率就會下降
---- 合併索引段落語句
curl -XPOST 'http://localhost:9200/{_index}/_forcemerge?max_num_segments=1'
4： 路由優化
- ES中所謂的路由和IP網絡不同，是一個類似於Tag的東西。在創建文檔的時候，可以通過字段爲文檔增加一個路由屬性的Tag。ES內在機制決定了擁有相同路由屬性的文檔，一定會被分配到同一個分片上，無論是主分片還是副本。那麼，在查詢的過程中，一旦指定了感興趣的路由屬性，ES就可以直接到相應的分片所在的機器上進行搜索，而避免了複雜的分佈式協同的一些工作，從而提升了ES的性能。於此同時，假設機器1上存有路由屬性A的文檔，機器2上存有路由屬性爲B的文檔，那麼我在查詢的時候一旦指定目標路由屬性爲A，即使機器2故障癱瘓，對機器1構不成很大影響，所以這麼做對災況下的查詢也提出瞭解決方案。所謂的路由，本質上是一個分桶（Bucketing）操作。當然，查詢中也可以指定多個路由屬性，機制大同小異
-
轉Elasticsearch模塊功能之-路由（routing）https://blog.csdn.net/changong28/article/details/38427311
5:GC調優
- elasticSearch本質上是個Java程序，所以配置JVM垃圾回收器本身也是一個很有意義的工作。我們使用JVM的Xms和Xmx參數來提供指定內存大小，本質上提供的是JVM的堆空間大小，當JVM的堆空間不足的時候就會觸發致命的OutOfMemoryException。這意味着要麼內存不足，要麼出現了內存泄露。處理GC問題，首先要確定問題的源頭，一般有兩種方案
- 開啓ElasticSearch上的GC日誌：在ES的配置文件elasticsearch.yml中有相關的屬性可以配置
- 使用jstat命令：jstat命令可以幫助我們查看JVM堆中各個區的使用情況和GC的耗時情況。
- 生成內存Dump：最後的辦法就是將JVM的堆空間轉儲到文件中去，實質上是對JVM堆空間的一個快照
想了解更多關於JVM本身GC調優方法請參考：http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
- 採用G1垃圾回收機制代替默認CMS(得觀察是否真的有必要)
- JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
- JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"