本次分享主要包含兩個方面的實戰經驗：索引性能和查詢性能。
一. 索引性能（Index Performance）
首先要考慮的是，索引性能是否有必要做優化？
索引速度提高與否？主要是看瓶頸在什么地方，若是 Read DB（產生DOC）的速度比較慢，那瓶頸不在 ElasticSearch 時，優化就沒那么大的動力。實際上 Elasticsearch 的索引速度還是非常快的。
我們有一次遇到 Elasticsearch 升級后索引速度很慢，查下來是新版 IK 分詞的問題，修改分詞插件后得到解決。
如果需要優化，應該如何優化？
SSD 是經濟壓力能承受情況下的不二選擇。減少碎片也可以提高索引速度，每天進行優化還是很有必要的。在初次索引的時候，把 replica 設置為 0，也能提高索引速度。
bulk 是不是一定需要呢？
若是 Elasticsearch 普通索引已經導致高企的 LA，IO 壓力已經見頂，這時候 bulk 也無法提供幫助，SSD 應該是很好的選擇。
在 create doc 速度能跟上的時候，bulk 是可以提高速度的。
記得 threadpool.index.queue_size ++，不然會出現索引時隊列不夠用的情況。
indices.memory.index_buffer_size:10% 這個參數可以進行適當調整。
調整如下參數也可以提高索引速度：index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查詢性能（Query Perofrmance）
王道是什么？routing，routing，還是 routing。
我們為了提高查詢速度，減少慢查詢，結合自己的業務實踐，使用多個集群，每個集群使用不同的 routing。比如，用戶是一個routing維度。
在實踐中，這個routing 非常重要。
我們碰到一種情況，想把此維度的查詢（即用戶查詢）引到非用戶routing 的集群，結果集群完全頂不住！
在大型的本地分類網站中，城市、類目也是一個不錯的維度。我們使用這種維度進行各種搭配。然后在前端分析查詢，把各個不同查詢分別引入合適的集群。這樣做以后，每個集群只需要很少的機器，而且保持很小的 CPU Usage 和 LA。從而查詢速度夠快，慢查詢幾乎消滅。
分合？
分別（索引和routing）查詢和合並（索引和routing）查詢，即此分合的意思。
索引越來越大，單個 shard 也很巨大，查詢速度也越來越慢。這時候，是選擇分索引還是更多的shards？
在實踐過程中，更多的 shards 會帶來額外的索引壓力，即 IO 壓力。
我們選擇了分索引。比如按照每個大分類一個索引，或者主要的大城市一個索引。然后將他們進行合並查詢。如：http://cluster1:9200/shanghai,beijing/_search?routing=fang，自動將查詢中城市屬性且值為上海或北京的查詢，且是房類目的，引入集群 cluster1，並且routing等於fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引，我們使用城市做 routing，如本例中同時查詢濟南和臨沂城市。
http://cluster1:9200/_all/_search，全部城市查詢。
再如： http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查詢上海和北京在小分類汽車、整租的信息，那我們進行如上合並查詢。並將其引入集群 cluster2。
使用更多的 shards？
除了有 IO 壓力，而且不能進行全部城市或全部類目查詢，因為完全頂不住。
Elastic 官方文檔建議：一個 Node 最好不要多於三個 shards。
若是 "more shards”，除了增加更多的機器，是沒辦法做到這一點的。
分索引，雖然一個 Node 總的shards 還是挺多的，但是一個索引可以保持3個以內的shards。
我們使用分索引時，全量查詢是可以頂住的，雖然壓力有點兒高。
索引越來越大，資源使用也越來越多。若是要進行更細的集群分配，大索引使用的資源成倍增加。
有什么辦法能減小索引？顯然，創建 doc 時，把不需要的 field 去掉是一個辦法；但是，這需要對業務非常熟悉。
有啥立竿見影的辦法？
根據我們信息的特點，內容（field:description）占了索引的一大半，那我們就不把 description 索引進 ES，doc 小了一倍，集群也小了一倍，所用的資源（Memory, HD or SSD, Host, snapshot存儲，還有時間）大大節省，查詢速度自然也更快。
那要查 description 怎么辦？
上面的實例中，我們可以把查詢引入不同集群，自然我們也可以把 description 查詢引入一個非實時（也可以實時）集群，這主要是我們業務特點決定的，因為description查詢所占比例非常小，使得我們可以這樣做。
被哪些查詢搞過？第一位是 Range 查詢，這貨的性能真不敢恭維。在最熱的查詢中，若是有這貨，肯定是非常痛苦的，網頁變慢，查詢速度變慢，集群 LA 高企，嚴重的時候會導致集群 shard 自動下線。所以，建議在最熱的查詢中避免使用 Range 查詢。
Facet 查詢，在后續版本這個被 aggregations 替代，我們大多數時候讓它在后端進行運算。
三. 其他
1)線程池
線程池我們默認使用 fixed，使用 cached 有可能控制不好。主要是比較大的分片 relocation時，會導致分片自動下線，集群可能處於危險狀態。在集群高壓時，若是 cached ，分片也可能自動下線。自 1.4 版本后，我們就一直 fixed，至於新版是否還存在這個問題，就沒再試驗了。
兩個原因：一是 routing王道帶來的改善，使得集群一直低壓運行；二是使用fixed 后，已經極少遇到自動下線shard了。
我們前面說過，user 是一個非常好的維度。這個維度很重要，routing 效果非常明顯。其他維度，需要根據業務特點，進行組合。
所以我們的集群一直是低壓運行，就很少再去關注新版本的 使用 cached 配置問題。
hreadpool.search.queue_size 這個配置是很重要的，一般默認是夠用了，可以嘗試提高。
2）優化
每天優化是有好處的，可以大大改善查詢性能。max_num_segments 建議配置為1。雖然優化時間會變長，但是在高峰期前能完成的話，會對查詢性能有很大好處。
3) JVM GC的選擇：選擇 G1還是 CMS？
應該大多數人還是選擇了 CMS，我們使用的經驗是 G1 和 CMS 比較接近；但和 CMS 相比，還是有一點距離，至少在我們使用經驗中是如此。
JVM 32G 現象？
128G內存的機器配置一個 JVM，然后是巨大的 heapsize （如64G）？
還是配多個 JVM instance，較小的 heapsize（如32G）？
我的建議是后者。實際使用中，后者也能幫助我們節省不少資源，並提供不錯的性能。具體請參閱 “Don’t Cross 32 GB!" （https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops）
跨 32G 時，有一個現象，使用更多的內存，比如 40G，效果還不如31G！
這篇文檔值得大家仔細閱讀。
JVM 還有一個配置 bootstrap.mlockall: true，比較重要。這是讓 JVM 啟動的時候就 鎖定 heap 內存。
有沒有用過 較小的 heapsize，加上SSD？我聽說有人使用過，效果還不錯，當然，我們自己還沒試過。
4）插件工具
推薦 kopf，是一個挺不錯的工具，更新及時，功能完備，可以讓你忘掉很多 API :)。
索引，查詢，和一些重要的配置，是今天分享的重點。
Q&A
Q1：您建議生產環境JVM采用什么樣的參數設置？FULL GC頻率和時間如何？
CMS 標准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我們使用 Elasticsearch 在JVM上花的時間很少。
Q2：生產環境服務器如何配置性價比較高？單機CPU核數、主頻？內存容量？磁盤容量？
內存大一些，CPU 多核是必要的，JVM 和 Elasticsearch 會充分使用內存和多核的。 關於內存容量的問題，很多是 JVM Tunning 的問題。 磁盤容量沒啥要求。
Q3： 分組統計(Facet 查詢或 aggregations )大多數時候讓它在后端進行運算，怎么實現？應用如果需要實時進行統計而且並發量較大，如何優化？
因為我們是網站系統，所以對於 Facet 請求，引導到后端慢慢計算，前端初始的時候可能沒數據，但是此后就會有了。
如果是精確要求的話，那就只能從 提高 facet 查詢性能去下手，比如 routing、filter、cache、更多的內存...
Q4：存進Elasticsearch的數據，timestamp是UTC時間，Elasticsearch集群會在UTC 0點，也就是北京時間早上8點自動執行優化？如何改參數設置這個時間？
我們沒有使用Elasticsearch的自動優化設置。自己控制優化時間。
Q5：我的Java程序，log4j2 Flume appender，然后機器上的Flume agent ，直接Elasticsearch 的sink avro到 es節點上，多少個agent 連在單個Elasticsearch節點比較合適 ？
ElasticSearch本身是一個分布式計算集群，所以，請求平均分配到每個 node 即可。
Q6：我代碼里直接用 Java API 生成Flume appender 格式，Flume agent 里interceptor去拆分幾個字段，這樣是不是太累了？比較推薦的做法是不是還是各業務點自己控制字段，調用Elasticsearch API 生成索引內容？
業務點自己控制生成的文檔吧？如果需要產生不同routing，並且分了索引，這些其實是業務相關的。routing和不同索引，都是根據業務情況哪些查詢比較集中而進行處理的。
Q7：您見過或管理過的生產環境的Elasticsearch數據量多大？
我們使用 Elasticsearch 進行某些業務處理，數據量過億。
Q8：SSD性能提升多少？
SSD 對索引幫助非常大，效果當當的，提高幾十倍應該是沒問題。不過，我們沒有試過完全使用SSD頂查詢，而是使用內存，內存性價比還是不錯的。
Q9：我們現在有256個shard，用uid做routing，所有查詢都是走routing。每個shard有30多G，每次擴容很慢，有什么建議？
可以考慮使用分合查詢嗎？ 或者使用更多的維度？ 256個 shard 確實比較難以控制。但是如果是分索引和查詢，比more shards(256) 效果應該會好不少。
Q10：Elasticsearch排序等聚合類的操作需要用到fielddata，查詢時很慢。新版本中doc values聚合查詢操作性能提升很大，你們有沒有用過？
Facet 查詢需要更大的內存，更多的 CPU 資源。可以考慮routing、filter、cache等多種方式提高性能。
Aggs 將來是要替換 Facet，建議盡快替換原來的facet API。
Q11：Elasticsearch配置bootstrap.mlockall，我們在使用中發現會導致啟動很慢，因為Elasticsearch要獲取到足夠的內存才開始啟動。
啟動慢是可以接受的，啟動慢的原因也許是內存沒有有效釋放過，比如文件 cached了。 內存充足的情況下，啟動速度還是蠻快的，可以接受。 JVM 和 Lucene 都需要內存，一般是JVM 50%, 剩下的50% 文件cached 為Lucene 使用。
Q12：優化是一個開銷比較大的操作，每天優化的時候是否會導致查詢不可用？如何優化這塊？
優化是開銷很大的。不會導致查詢不可用。優化是值得的，大量的碎片會導致查詢性能大大降低。 如果非常 care 查詢，可以考慮多個集群。在優化時，查詢 skip 這個集群就可以。
Q13：Elasticsearch適合做到10億級數據查詢，每天千萬級的數據實時寫入或更新嗎？
10億是可以做到的，如果文檔輕量，10億所占的資源還不是很多。
ELK 使用 Elasticsearch ，進行日志處理每天千萬是小case吧？
不過我們除了使用 ELK 進行日志處理，還進行業務處理，10億級快速查詢是可以做到，不過，需要做一些工作，比如索引和shards的分分合合：）
Q14：Elasticsearch相比Solr有什么優勢嗎？
我們當年使用 Solr 的時候，Elasticsearch 剛出來。他們都是基於 Lucene的。 Elasticsearch 相對於 solr ，省事是一個優點。而且現在 Elasticsearch 相關的應用軟件也越來越多。Solr 和 Lucene 集成度很高，更新版本是和Lucene一起的，這是個優點。
很多年沒用 Solr了，畢竟那時候數據量還不大，所以折騰的就少了，主要還是折騰 JVM。所以，就不再過多的比較了。
Q15：分詞用的什么組件？Elasticsearch自帶的嗎？
我們使用 IK 分詞，不過其他分詞也不錯。IK分詞更新還是很及時的。而且它可以遠程更新詞典。：）
Q16： reindex有沒有好的方法？
reindex 這個和 Lucene 有關，它的 update 就是 delete+ add。
Q17：以上面的兩個例子為例 ： 是存儲多份同樣的數據么？
是兩個集群。第一個集群使用大城市分索引，不過，還有大部分小城市合並一個索引。大城市還是用類目進行routing，小城市合並的索引就使用城市進行routing 。
第二個集群，大類分得索引，比如fang、che，房屋和車輛和其他類目在一個集群上，他們使用 city+二級類目做routing。
Q18：集群部署有沒有使用 Docker ？ 我們使用的時候 ，同一個服務器 節點之間的互相發現沒有問題 ，但是跨機器的時候需要強制指定network.publish_host 和discovery.zen.ping.unicast.hosts 才能解決集群互相發現問題。
我們使用puppet進行部署。暫沒使用 Docker。 強制指定network.publish_host 和discovery.zen.ping.unicast.hosts 才能解決集群，跨IP段的時候是有這個需要。
Q19：您建議采用什么樣的數據總線架構來保證業務數據按routing寫入多個Elasticsearch集群，怎么保證多集群Elasticsearch中的數據與數據庫中數據的一致性？
我們以前使用 php在web代碼中進行索引和分析 query，然后引導到不同集群。 現在我們開發了一套go rest系統——4sea，使用 redis + elastic 以綜合提高性能。
索引時，更新db的同時，提交一個文檔 ID 通知4sea 進行更新，然后根據配置更新到不同集群。
數據提交到查詢時，就是分析 query 並引導到不同集群。
這套 4sea 系統，有機會的可以考慮開源，不算很復雜的。
Q20： 能介紹一下Elasticsearch的集群rebanlance、段合並相關的原理和經驗嗎？
“段”合並？，我們是根據業務特點，產生幾個不一樣的集群，主要還是 routing 不一樣。
shards 比較平均很重要的，所以選擇routing 維度是難點，選擇城市的話，大城市所在分片會非常大，此時可以考慮 分索引，幾個大城市幾個索引，然后小城市合並一個索引。
如果 shards 大小分布平均的話，就不關心如何 allocation 了。
Q21：關於集群rebalance，其實就是cluster.routing.allocation配置下的那些rebalance相關的設置，比如allow_rebalance／cluster_concurrent_rebalance／node_initial_primaries_recoveries，推薦怎么配置？
分片多的情況下，這個才是需要的吧。
分片比較少時，allow_rebalance disable，然后手動也可以接受的。
分片多，一般情況會自動平衡。我們對主從不太關心。只是如果一台機器多個 JVM instance （多個 Elasticsearch node）的話，我們寫了個腳本來避免同一shard 在一台機器上。
cluster_concurrent_rebalance 在恢復的時候根據情況修改。正常情況下，再改成默認就好了。
node_initial_primaries_recoveries，在保證集群低壓的情況下，不怎么care。
kopf 上面有好多這種配置，你可以多試試。
Q22：合並查詢是異步請求還是同步請求？做緩存嗎？
合並查詢是 Elasticsearch 自帶 API。
Q23：用httpurlconnection請求的時候，會發現返回請求很耗時，一般怎么處理？
盡可能減少慢查詢吧？我們很多工作就是想辦法如何減少慢查詢，routing和分分合合，就是這個目的。
Q24：生產環境單個節點存儲多少G數據？
有大的，有小的。小的也幾十G了。不過根據我們自己的業務特點，某些集群就去掉了全文索引。唯一的全文索引，使用基本的routing（比較平衡的routing，比如user。城市的話，就做不到平衡了，因為大城市數據很多），然后做了 快照，反正是增量快照，1小時甚至更短時間都可以考慮！！！去掉全文索引的其他業務集群，就小多了。