什么是Elasticsearch?

Elasticsearch(后簡(jiǎn)稱ES)是一個(gè)基于Apache Lucene(TM)的開(kāi)源搜索引擎。

為什么使用ES?

ES是Lucene面向企業(yè)搜索應(yīng)用的擴(kuò)展，極大的縮短研發(fā)周期。

注：本文主要圍繞ES的優(yōu)化，基礎(chǔ)知識(shí)請(qǐng)移步~

在某省的大數(shù)據(jù)日志分析平臺(tái)項(xiàng)目中，我們對(duì)網(wǎng)絡(luò)設(shè)備日志，操作系統(tǒng)日志，數(shù)據(jù)庫(kù)日志，中間件日志，業(yè)務(wù)日志進(jìn)行7*24小時(shí)采集，搜索(能夠搜索2個(gè)月以內(nèi)的數(shù)據(jù))由于日志量十分的龐大(日志源大約在1000個(gè)左右)，并且當(dāng)業(yè)務(wù)繁忙的時(shí)候(工作日9:00-17:00)中間件日志和業(yè)務(wù)日志的產(chǎn)生會(huì)出現(xiàn)井噴式的爆發(fā)，每天大約1.2T的數(shù)據(jù)量，但由于系統(tǒng)組各方面原因，現(xiàn)有硬件資源無(wú)法支撐如此高的并發(fā)。為此，團(tuán)隊(duì)對(duì)ES(底層存儲(chǔ))進(jìn)行深度優(yōu)化，使其能夠應(yīng)對(duì)場(chǎng)景。

描述:

數(shù)據(jù)產(chǎn)生的量平均大約為: 15MB/秒≈15000條/秒

業(yè)務(wù)繁忙期大約為: 20MB/秒≈20000條/秒

機(jī)器配置為:

CPU：80個(gè)核心（超線程）

內(nèi)存：256G

磁盤：7塊機(jī)械硬盤（每塊14T）

機(jī)器數(shù)量：1臺(tái)

機(jī)器所安裝的組件，以及數(shù)據(jù)流走向

服務(wù)器上安裝了：

Kafka（2GB + 1core） * 1

Flume（2GB + 2core） * 1

ES（32G + 12core） * 3

遇到的問(wèn)題

數(shù)據(jù)在kafka中嚴(yán)重堆積（數(shù)據(jù)輸入速度大于落地速度），ES在運(yùn)行一段時(shí)間后寫入速度只有1M/秒。導(dǎo)致最后直接癱瘓奔潰。

優(yōu)化后

1. 數(shù)據(jù)實(shí)時(shí)落地ES并且在Kafka無(wú)堆積

2. 每天1.2T數(shù)據(jù)增量,穩(wěn)定無(wú)崩潰

3. 2個(gè)月的數(shù)據(jù)大約有70TB≈700億條

4. 普通搜索匹配在10秒內(nèi)返回結(jié)果（使用緩存）

5. ES占用內(nèi)存大約為96G

6. ES占用CPU 大約為40個(gè)核心

優(yōu)化后ES的節(jié)點(diǎn)信息

在每一塊硬盤上部署了1個(gè)ES節(jié)點(diǎn)，共計(jì)部署了7個(gè)節(jié)點(diǎn)

前5個(gè)節(jié)點(diǎn) 每個(gè)節(jié)點(diǎn)16G內(nèi)存，作為data節(jié)點(diǎn)（詳見(jiàn)下面配置）

后2個(gè)節(jié)點(diǎn) 每個(gè)節(jié)點(diǎn)8G內(nèi)存，一個(gè)作為master，一個(gè)作為client（詳見(jiàn)下面配置）

優(yōu)化詳情

這里提出來(lái)的只是一種優(yōu)化點(diǎn)，并不是說(shuō)一定要按照這個(gè)配置，畢竟具體場(chǎng)景要具體分析。

a) 硬盤使用SSD，并且調(diào)整I/O調(diào)度算法為RAID0，其實(shí)硬盤可以說(shuō)是ES的一個(gè)瓶頸了，但是由于項(xiàng)目經(jīng)費(fèi)問(wèn)題,所以優(yōu)化的時(shí)候并沒(méi)有考慮上SDD...當(dāng)然土豪請(qǐng)隨意...

b) 每個(gè)節(jié)點(diǎn)ES CPU至少大于8Core

c) 每個(gè)節(jié)點(diǎn)ES分配內(nèi)存至少大于8G

d) 不要使用NAS

a) 調(diào)整ES所用的內(nèi)存大小,建議不超過(guò)32G,內(nèi)存最小設(shè)置成一樣

為什么不超過(guò)32G?

其基本原因是JVM使用所謂的HEAP內(nèi)存來(lái)存儲(chǔ)對(duì)象指針。為了提高效率，Java使用了所謂的壓縮普通對(duì)象指針（OOP）。超過(guò)32 GB的HEAP，Java需要使用常規(guī)的64位指針。這實(shí)際上大大減少了HEAP中可以存儲(chǔ)的對(duì)象數(shù)量，大約50 GB的HEAP與大約30 GB的大約相同。

***此配置在jvm.options設(shè)置

###在此場(chǎng)景中我們的data節(jié)點(diǎn)內(nèi)存每臺(tái)為16G，master和client節(jié)點(diǎn)各為8G

b) 合理配置每個(gè)節(jié)點(diǎn)的角色data/master/client

node.master:true 這個(gè)屬性表示節(jié)點(diǎn)是否具有成為主節(jié)點(diǎn)的資格,主節(jié)點(diǎn)負(fù)責(zé)存儲(chǔ)元數(shù)據(jù)和任務(wù)調(diào)度,以及維護(hù)整個(gè)集群狀態(tài)

node.data:true 這個(gè)屬性表示節(jié)點(diǎn)是否存儲(chǔ)數(shù)據(jù),

如果2個(gè)屬性都為false，則視為client節(jié)點(diǎn),該節(jié)點(diǎn)只負(fù)責(zé)用戶請(qǐng)求,實(shí)現(xiàn)請(qǐng)求轉(zhuǎn)發(fā),負(fù)載均衡等功能

***此配置在elasticsearch.yml設(shè)置

###在此場(chǎng)景中我們的5臺(tái)data節(jié)點(diǎn)配置為:

node.master:false

node.data:true

1臺(tái)master節(jié)點(diǎn)配置為:

node.master:true

node.data:false

1臺(tái)client節(jié)點(diǎn)配置為:

node.master:false

node.data:false

c) 調(diào)高index的緩存indices.memory.index_buffer_size

***此配置在elasticsearch.yml設(shè)置

###在此場(chǎng)景中我們的配置為indices.memory.index_buffer_size:30%

d) 調(diào)高線程數(shù)

thread_pool.search.queue_size(搜索隊(duì)列線程數(shù))

thread_pool.index.queue_size(索引隊(duì)列線程數(shù))

***此配置在elasticsearch.yml設(shè)置

###在此場(chǎng)景中我們的配置為

thread_pool.search.queue_size:1000

thread_pool.index.queue_size:200

e) 調(diào)整索引時(shí)候的配置

1) settings.number_of_replicas 副本數(shù) 默認(rèn)為1

建議寫入時(shí)數(shù)據(jù)量很大的情況下,將副本數(shù)設(shè)置成0,等壓力小后,將其再設(shè)置成1,因?yàn)楦北緮?shù)將直接影響你的磁盤開(kāi)銷.

2) settings.number_of_shards  分片數(shù)量 默認(rèn)為5

參考公式: 分片數(shù)量=總節(jié)點(diǎn)數(shù)/(分片副本數(shù)量+1)

3) settings.index.translog.sync_interval  translog同步到磁盤的時(shí)間間隔

什么是translog?

lucene索引過(guò)程中，數(shù)據(jù)會(huì)首先據(jù)緩存在內(nèi)存中直到達(dá)到一個(gè)量（文檔數(shù)或是占用空間大小）才會(huì)寫入到磁盤。這就會(huì)帶來(lái)一個(gè)風(fēng)險(xiǎn)，如果在寫入磁盤前系統(tǒng)崩潰，那么這些緩存數(shù)據(jù)就會(huì)丟失。es通過(guò)translog解決了這個(gè)問(wèn)題，每次寫操作都會(huì)寫入一個(gè)臨時(shí)文件translog中，這樣如果系統(tǒng)需要恢復(fù)數(shù)據(jù)可以從translog中讀取。

4) settings.index.translog.durability tanslog同步到本地的方式

5) settings.index.translog.flush_threshold_size  滿足translog同步的容量 默認(rèn)為512m

6) settings.index.refresh_interval   索引的刷新時(shí)間間隔 默認(rèn)為:1s,調(diào)大間隔可以很明顯感覺(jué)到es的效率高了不少

7) settings.index.merge.scheduler.max_thread_count 調(diào)高合并的線程

默認(rèn)為:Math.max(1, Math.min(3, Runtime.getRuntime().availableProcessors() / 2))

8) settings.index.merge.policy.max_merged_segment 分段大小 默認(rèn)為5gb

在正常的合并過(guò)程中產(chǎn)生的分段的大小。此設(shè)置是近似值：合并后的段大小的預(yù)估值是由被合并分段的大小計(jì)算出來(lái)的（刪除文檔補(bǔ)償百分比）

9) settings.index.merge.policy.segments_per_tier 每層所允許的分段數(shù) 默認(rèn)為10

較小的值意味著更多

的合并，但是存在較少的分段。默認(rèn)：10。請(qǐng)注意，這個(gè)值必須 >=max_merge_at_once 不然就會(huì)強(qiáng)制執(zhí)行太多的合并。

***此配置是在ES啟動(dòng)后以api的方式發(fā)送給ES

###在此場(chǎng)景中我們的配置為

"number_of_shards": 7,

"index.translog.sync_interval": "120s",

"index.translog.durability": "async",

"index.translog.flush_threshold_size": "5g",

"number_of_replicas": "0",

"index.refresh_interval": "60s",

"index.merge.scheduler.max_thread_count": 20,

"index.merge.policy.max_merged_segment": "2gb",

"index.merge.policy.segments_per_tier": "24"

a) 路由

當(dāng)我們查詢文檔的時(shí)候，Elasticsearch 如何知道一個(gè)文檔應(yīng)該存放到哪個(gè)分片中呢？它其實(shí)是通過(guò)下面這個(gè)公式來(lái)計(jì)算出來(lái)

shard = hash(routing) % number_of_primary_shards

routing 默認(rèn)值是文檔的 id，也可以采用自定義值，比如用戶 id。

不帶 routing 查詢

在查詢的時(shí)候因?yàn)椴恢酪樵兊臄?shù)據(jù)具體在哪個(gè)分片上，所以整個(gè)過(guò)程分為 2 個(gè)步驟

分發(fā)：請(qǐng)求到達(dá)協(xié)調(diào)節(jié)點(diǎn)后，協(xié)調(diào)節(jié)點(diǎn)將查詢請(qǐng)求分發(fā)到每個(gè)分片上。

聚合: 協(xié)調(diào)節(jié)點(diǎn)搜集到每個(gè)分片上查詢結(jié)果，在將查詢的結(jié)果進(jìn)行排序，之后給用戶返回結(jié)果。

帶 routing 查詢

查詢的時(shí)候，可以直接根據(jù) routing 信息定位到某個(gè)分配查詢，不需要查詢所有的分配，經(jīng)過(guò)協(xié)調(diào)節(jié)點(diǎn)排序。

向上面自定義的用戶查詢，如果 routing 設(shè)置為 userid 的話，就可以直接查詢出數(shù)據(jù)來(lái)，效率提升很多。

b) Filter VS Query

盡可能使用filter

Elasticsearch 針對(duì) Filter 查詢只需要回答「是」或者「否」，不需要像 Query 查詢一下計(jì)算相關(guān)性分?jǐn)?shù)，同時(shí) Filter 結(jié)果可以緩存。

c) 對(duì)index做分區(qū)

一個(gè)index能存放的數(shù)據(jù)是有限的,就像數(shù)據(jù)庫(kù)一樣,在數(shù)據(jù)量很大的情況下,我們一般會(huì)將其進(jìn)行分表(分區(qū)),比如用戶的訪問(wèn)日志,我們的index可能以時(shí)間做區(qū)分比如 index-%{yyyy-MM-dd} 這樣每天生成一個(gè)index,保證index不會(huì)因?yàn)閿?shù)據(jù)太多而”爆炸”

d) 深度分頁(yè)

在使用分頁(yè)的時(shí)候盡量使用scroll來(lái)分頁(yè),From+Size會(huì)讓你的CPU占用率像直升機(jī)一樣飆高,然后墜機(jī)(程序奔潰)…

總結(jié)

優(yōu)化前后對(duì)比

架構(gòu)對(duì)比

優(yōu)化思路

1. 調(diào)整ES的索引刷新間隔

2. 調(diào)整ES的translog刷新策略

3. 調(diào)整索引合并策略

4. 調(diào)整shards數(shù)量

5. 調(diào)整副本數(shù)量

6. 調(diào)整緩存策略

7. 調(diào)整搜索，合并，刷新的線程數(shù)

8. 設(shè)置合理的es節(jié)點(diǎn)角色

9. Index合理分區(qū)

10. 盡量使用filter

11. 盡可能使用路由策略

12. 使用SSD