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