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