簡介node
Elasticsearch(簡稱ES)是一個分佈式、可擴展、實時的搜索與數據分析引擎。ES不只僅只是全文搜索,還支持結構化搜索、數據分析、複雜的語言處理、地理位置和對象間關聯關係等。mysql
ES的底層依賴Lucene,Lucene能夠說是當下最早進、高性能、全功能的搜索引擎庫。可是Lucene僅僅只是一個庫。爲了充分發揮其功能,你須要使用Java並將Lucene直接集成到應用程序中。更糟糕的是,您可能須要得到信息檢索學位才能瞭解其工做原理,由於Lucene很是複雜——《ElasticSearch官方權威指南》。git
鑑於Lucene如此強大卻難以上手的特色,誕生了ES。ES也是使用Java編寫的,它的內部使用Lucene作索引與搜索,它的目的是隱藏Lucene的複雜性,取而代之的提供一套簡單一致的RESTful API。github
整體來講,ES具備以下特色:web
一個分佈式的實時文檔存儲引擎,每一個字段均可以被索引與搜索
一個分佈式實時分析搜索引擎,支持各類查詢和聚合操做
能勝任上百個服務節點的擴展,並能夠支持PB級別的結構化或者非結構化數據
架構算法
節點類型sql
ES的架構很簡單,集羣的HA不須要依賴任務外部組件(例如Zookeeper、HDFS等),master節點的主備依賴於內部自建的選舉算法,經過副本分片的方式實現了數據的備份的同時,也提升了併發查詢的能力。json
ES集羣的服務器分爲如下四種角色:bootstrap
1.列表項目master節點,負責保存和更新集羣的一些元數據信息,以後同步到全部節點,因此每一個節點都須要保存全量的元數據信息:api
集羣的配置信息
集羣的節點信息
模板template設置
索引以及對應的設置、mapping、分詞器和別名
索引關聯到的分片以及分配到的節點
2.datanode:負責數據存儲和查詢
3.coordinator:
路由索引請求
聚合搜索結果集
分發批量索引請求
4.ingestor:
相似於logstash,對輸入數據進行處理和轉換
如何配置節點類型
一個節點的缺省配置是:主節點+數據節點兩屬性爲一身。對於3-5個節點的小集羣來說,一般讓全部節點存儲數據和具備得到主節點的資格。
專用協調節點(也稱爲client節點或路由節點)從數據節點中消除了聚合/查詢的請求解析和最終階段,隨着集羣寫入以及查詢負載的增大,能夠經過協調節點減輕數據節點的壓力,可讓數據節點更多專一於數據的寫入以及查詢。
master選舉
選舉策略
若是集羣中存在master,承認該master,加入集羣
若是集羣中不存在master,從具備master資格的節點中選id最小的節點做爲master
選舉時機
集羣啓動:後臺啓動線程去ping集羣中的節點,按照上述策略從具備master資格的節點中選舉出master
現有的master離開集羣:後臺一直有一個線程定時ping master節點,超過必定次數沒有ping成功以後,從新進行master的選舉
選舉流程
從原理到應用,Elasticsearch詳解
避免腦裂
腦裂問題是採用master-slave模式的分佈式集羣廣泛須要關注的問題,腦裂一旦出現,會致使集羣的狀態出現不一致,致使數據錯誤甚至丟失。
ES避免腦裂的策略:過半原則,能夠在ES的集羣配置中添加一下配置,避免腦裂的發生
#一個節點多久ping一次,默認1s
discovery.zen.fd.ping_interval: 1s
##等待ping返回時間,默認30s
discovery.zen.fd.ping_timeout: 10s
##ping超時重試次數,默認3次
discovery.zen.fd.ping_retries: 3
##選舉時須要的節點鏈接數,N爲具備master資格的節點數量
discovery.zen.minimum_master_nodes=N/2+1
注意問題
配置文件中加入上述避免腦裂的配置,對於網絡波動比較大的集羣來講,增長ping的時間和ping的次數,必定程度上能夠增長集羣的穩定性
動態的字段field可能致使元數據暴漲,新增字段mapping映射須要更新mater節點上維護的字段映射信息,master修改了映射信息以後再同步到集羣中全部的節點,這個過程當中數據的寫入是阻塞的。因此建議關閉自動mapping,沒有預先定義的字段mapping會寫入失敗
經過定時任務在集羣寫入的低峯期,將索引以及mapping映射提早建立好
負載均衡
ES集羣是分佈式的,數據分佈到集羣的不一樣機器上,對於ES中的一個索引來講,ES經過分片的方式實現數據的分佈式和負載均衡。建立索引的時候,須要指定分片的數量,分片會均勻的分佈到集羣的機器中。分片的數量是須要建立索引的時候就須要設置的,並且設置以後不能更改,雖然ES提供了相應的api來縮減和擴增分片,可是代價是很高的,須要重建整個索引。
考慮到併發響應以及後續擴展節點的能力,分片的數量不能太少,假如你只有一個分片,隨着索引數據量的增大,後續進行了節點的擴充,可是因爲一個分片只能分佈在一臺機器上,因此集羣擴容對於該索引來講沒有意義了。
可是分片數量也不能太多,每一個分片都至關於一個獨立的lucene引擎,太多的分片意味着集羣中須要管理的元數據信息增多,master節點有可能成爲瓶頸;同時集羣中的小文件會增多,內存以及文件句柄的佔用量會增大,查詢速度也會變慢。
數據副本
ES經過副本分片的方式,保證集羣數據的高可用,同時增長集羣併發處理查詢請求的能力,相應的,在數據寫入階段會增大集羣的寫入壓力。
數據寫入的過程當中,首先被路由到主分片,寫入成功以後,將數據發送到副本分片,爲了保證數據不丟失,最好保證至少一個副本分片寫入成功之後才返回客戶端成功。
相關配置
5.0以前經過consistency來設置
consistency參數的值能夠設爲 :
one :只要主分片狀態ok就容許執行寫操做
all:必需要主分片和全部副本分片的狀態沒問題才容許執行寫操做
quorum:默認值爲quorum,即大多數的分片副本狀態沒問題就容許執行寫操做,副本分片數量計算方式爲int( (primary +
number_of_replicas) / 2 ) + 1
5.0以後經過wait_for_active_shards參數設置
索引時增長參數:?wait_for_active_shards=3
給索引增長配置:index.write.wait_for_active_shards=3
數據寫入
寫入過程
幾個概念:
內存buffer
translog
文件系統緩衝區
refresh
segment(段)
commit
flush
從原理到應用,Elasticsearch詳解
translog
寫入ES的數據首先會被寫入translog文件,該文件持久化到磁盤,保證服務器宕機的時候數據不會丟失,因爲順序寫磁盤,速度也會很快。
同步寫入:每次寫入請求執行的時候,translog在fsync到磁盤以後,纔會給客戶端返回成功
異步寫入:寫入請求緩存在內存中,每通過固定時間以後纔會fsync到磁盤,寫入量很大,對於數據的完整性要求又不是很是嚴格的狀況下,能夠開啓異步寫入
refresh
通過固定的時間,或者手動觸發以後,將內存中的數據構建索引生成segment,寫入文件系統緩衝區
commit/flush
超過固定的時間,或者translog文件過大以後,觸發flush操做:
內存的buffer被清空,至關於進行一次refresh
文件系統緩衝區中全部segment刷寫到磁盤
將一個包含全部段列表的新的提交點寫入磁盤
啓動或從新打開一個索引的過程當中使用這個提交點來判斷哪些segment隸屬於當前分片
刪除舊的translog,開啓新的translog
merge
上面提到,每次refresh的時候,都會在文件系統緩衝區中生成一個segment,後續flush觸發的時候持久化到磁盤。因此,隨着數據的寫入,尤爲是refresh的時間設置的很短的時候,磁盤中會生成愈來愈多的segment:
segment數目太多會帶來較大的麻煩。 每個segment都會消耗文件句柄、內存和cpu運行週期。
更重要的是,每一個搜索請求都必須輪流檢查每一個segment,因此segment越多,搜索也就越慢。
merge的過程大體描述以下:
磁盤上兩個小segment:A和B,內存中又生成了一個小segment:C
A,B被讀取到內存中,與內存中的C進行merge,生成了新的更大的segment:D
觸發commit操做,D被fsync到磁盤
建立新的提交點,刪除A和B,新增D
刪除磁盤中的A和B
刪改操做
segment的不可變性的好處
segment的讀寫不須要加鎖
常駐文件系統緩存(堆外內存)
查詢的filter緩存能夠常駐內存(堆內存)
刪除
磁盤上的每一個segment都有一個.del文件與它相關聯。當發送刪除請求時,該文檔未被真正刪除,而是在.del文件中標記爲已刪除。此文檔可能仍然能被搜索到,但會從結果中過濾掉。當segment合併時,在.del文件中標記爲已刪除的文檔不會被包括在新的segment中,也就是說merge的時候會真正刪除被刪除的文檔。
更新
建立新文檔時,Elasticsearch將爲該文檔分配一個版本號。對文檔的每次更改都會產生一個新的版本號。當執行更新時,舊版本在.del文件中被標記爲已刪除,而且新版本在新的segment中寫入索引。舊版本可能仍然與搜索查詢匹配,可是從結果中將其過濾掉。
版本控制
經過添加版本號的樂觀鎖機制保證高併發的時候,數據更新不會出現線程安全的問題,避免數據更新被覆蓋之類的異常出現。
使用內部版本號:刪除或者更新數據的時候,攜帶_version參數,若是文檔的最新版本不是這個版本號,那麼操做會失敗,這個版本號是ES內部自動生成的,每次操做以後都會遞增一。
PUT /website/blog/1?version=1
{
"title": "My first blog entry",
"text": "Starting to get the hang of this..."
}
使用外部版本號:ES默認採用遞增的整數做爲版本號,也能夠經過外部自定義整數(long類型)做爲版本號,例如時間戳。經過添加參數version_type=external,可使用自定義版本號。內部版本號使用的時候,更新或者刪除操做須要攜帶ES索引當前最新的版本號,匹配上了才能成功操做。可是外部版本號使用的時候,能夠將版本號更新爲指定的值。
PUT /website/blog/2?version=5&version_type=external
{
"title": "My first external blog entry",
"text": "Starting to get the hang of this..."
}
原始文檔存儲(行式存儲)
從原理到應用,Elasticsearch詳解
fdt文件
文檔內容的物理存儲文件,由多個chunk組成,Lucene索引文檔時,先緩存文檔,緩存大於16KB時,就會把文檔壓縮存儲。
從原理到應用,Elasticsearch詳解
fdx文件
文檔內容的位置索引,由多個block組成:
1024個chunk歸爲一個block
block記錄chunk的起始文檔ID,以及chunk在fdt中的位置
從原理到應用,Elasticsearch詳解
fnm文件
文檔元數據信息,包括文檔字段的名稱、類型、數量等。
原始文檔的查詢
從原理到應用,Elasticsearch詳解
注意問題:lucene對原始文件的存放是行式存儲,而且爲了提升空間利用率,是多文檔一塊兒壓縮,所以取文檔時須要讀入和解壓額外文檔,所以取文檔過程很是依賴CPU以及隨機IO。
相關設置
壓縮方式的設置
原始文檔的存儲對應_source字段,是默認開啓的,會佔用大量的磁盤空間,上面提到的chunk中的文檔壓縮,ES默認採用的是LZ4,若是想要提升壓縮率,能夠將設置改爲best_compression。
index.codec: best_compression
特定字段的內容存儲
查詢的時候,若是想要獲取原始字段,須要在_source中獲取,由於全部的字段存儲在一塊兒,因此獲取完整的文檔內容與獲取其中某個字段,在資源消耗上幾乎相同,只是返回給客戶端的時候,減小了必定量的網絡IO。
ES提供了特定字段內容存儲的設置,在設置mappings的時候能夠開啓,默認是false。若是你的文檔內容很大,而其中某個字段的內容有須要常常獲取,能夠設置開啓,將該字段的內容單獨存儲。
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"title": {
"type": "text",
"store": true
}
}
}
}
}
倒排索引
從原理到應用,Elasticsearch詳解
倒排索引中記錄的信息主要有:
文檔編號:segment內部文檔編號從0開始,最大值爲int最大值,文檔寫入以後會分配這樣一個順序號
字典:字段內容通過分詞、歸一化、還原詞根等操做以後,獲得的全部單詞
單詞出現位置:分詞字段默認開啓,提供對於短語查詢的支持;對於很是常見的詞,例如the,位置信息可能佔用很大空間,短語查詢須要讀取的數據量很大,查詢速度慢
單詞出現次數:單詞在文檔中出現的次數,做爲評分的依據
單詞結束字符到開始字符的偏移量:記錄在文檔中開始與結束字符的偏移量,提供高亮使用,默認是禁用的
規範因子:對字段長度進行規範化的因子,給予較短字段更多權重
倒排索引的查找過程本質上是經過單詞找對應的文檔列表的過程,所以倒排索引中字典的設計決定了倒排索引的查詢速度,字典主要包括前綴索引(.tip文件)和後綴索引(.tim)文件。
字典前綴索引(.tip文件)
一個合格的詞典結構通常有如下特色:
-查詢速度快 -內存佔用小 -內存+磁盤相結合
從原理到應用,Elasticsearch詳解
Lucene採用的前綴索引數據結構爲FST,它的優勢有:
詞查找複雜度爲O(len(str))
共享前綴、節省空間、內存佔用率低,壓縮率高,模糊查詢支持好
內存存放前綴索引,磁盤存放後綴詞塊
缺點:結構複雜、輸入要求有序、更新不易
字典後綴(.tim文件)
後綴詞塊主要保存了單詞後綴,以及對應的文檔列表的位置。
文檔列表(.doc文件)
從原理到應用,Elasticsearch詳解
lucene對文檔列表存儲進行了很好的壓縮,來保證緩存友好:
差分壓縮:每一個ID只記錄跟前面的ID的差值
每256個ID放入一個block中
block的頭信息存放block中每一個ID佔用的bit位數,由於通過上面的差分壓縮以後,文檔列表中的文檔ID都變得不大,佔用的bit位數變少
上圖通過壓縮以後將6個數字從原先的24bytes壓縮到7bytes。
文檔列表的合併
從原理到應用,Elasticsearch詳解
ES的一個重要的查詢場景是bool查詢,相似於mysql中的and操做,須要將兩個條件對應的文檔列表進行合併。爲了加快文檔列表的合併,lucene底層採用了跳錶的數據結構,合併過程當中,優先遍歷較短的鏈表,去較長的列表中進行查詢,若是存在,則該文檔符合條件。
從原理到應用,Elasticsearch詳解
倒排索引的查詢過程
從原理到應用,Elasticsearch詳解
內存加載tip文件,經過FST匹配前綴找到後綴詞塊位置
根據詞塊位置,讀取磁盤中tim文件中後綴塊並找到後綴和相應的倒排表位置信息
根據倒排表位置去doc文件中加載倒排表
藉助跳錶結構,對多個文檔列表進行合併
filter查詢的緩存
對於filter過濾查詢的結果,ES會進行緩存,緩存採用的數據結構是RoaringBitmap,在match查詢中配合filter能有效加快查詢速度。
普通bitset的缺點:內存佔用大,RoaringBitmap有很好的壓縮特性
分桶:解決文檔列表稀疏的狀況下,過多的0佔用內存,每65536個docid分到一個桶,桶內只記錄docid%65536
桶內壓縮:4096做爲分界點,小余這個值用short數組,大於這個值用bitset,每一個short佔兩字節,4096個short佔用65536bit,因此超過4096個文檔id以後,是bitset更節省空間。
從原理到應用,Elasticsearch詳解
DocValues(正排索引&列式存儲)
從原理到應用,Elasticsearch詳解
倒排索引保存的是詞項到文檔的映射,也就是詞項存在於哪些文檔中,DocValues保存的是文檔到詞項的映射,也就是文檔中有哪些詞項。
相關設置
keyword字段默認開啓
ES6.0(lucene7.0)以前
DocValues採用的數據結構是bitset,bitset對於稀疏數據的支持很差:
對於稀疏的字段來講,絕大部分的空間都被0填充,浪費空間
因爲字段的值之間插入了0,可能原本連續的值被0間隔開來了,不利於數據的壓縮
空間被一堆0佔用了,緩存中緩存的有效數據減小,查詢效率也會下降
查詢邏輯很簡單,相似於數組經過下標進行索引,由於每一個value都是固定長度,因此讀取文檔id爲N的value直接從N*固定長度位置開始讀取固定長度便可。
從原理到應用,Elasticsearch詳解
ES6.0(lucene7.0)
docid的存儲的經過分片加快映射到value的查詢速度
value存儲的時候再也不給空的值分配空間
由於value存儲的時候,空值再也不分配空間,因此查詢的時候不能經過上述經過文檔id直接映射到在bitset中的偏移量來獲取對應的value,須要經過獲取docid的位置來找到對應的value的位置。
因此對於DocValues的查找,關鍵在於DocIDSet中ID的查找,若是按照簡單的鏈表的查找邏輯,那麼DocID的查找速度將會很慢。lucene7借用了RoaringBitmap的分片的思想來加快DocIDSet的查找速度:
從原理到應用,Elasticsearch詳解
分片容量爲2的16次方,最多能夠存儲65536個docid
分片包含的信息:分片ID;存儲的docid的個數(值不爲空的DocIDSet);DocIDSet明細,或者標記分片類型(ALL或者NONE)
根據分片的容量,將分片分爲四種不一樣的類型,不一樣類型的查找邏輯不通:ALL:該分片內沒有不存在值的DocID;NONE:該分片內全部的DocID都不存在值;SPARSE:該分片內存在值的DocID的個數不超過4096,DocIDSet以short數組的形式存儲,查找的時候,遍歷數組,找到對應的ID的位置;DENSE:該分片內存在值的DocID的個數超過4096,DocIDSet以bitset的形式存儲,ID的偏移量也就是在該分片中的位置
最終DocIDSet的查找邏輯爲:
計算DocID/65536,獲得所在的分片N
計算前面N-1個分片的DocID的總數
找到DocID在分片N內部的位置,從而找到所在位置以前的DocID個數M
找到N+M位置的value即爲該DocID對應的value
數據查詢
查詢過程(query then fetch)
協調節點將請求發送給對應分片
分片查詢,返回from+size數量的文檔對應的id以及每一個id的得分
彙總全部節點的結果,按照得分獲取指定區間的文檔id
根據查詢需求,像對應分片發送多個get請求,獲取文檔的信息
返回給客戶端
get查詢更快
默認根據id對文檔進行路由,因此指定id的查詢能夠定位到文檔所在的分片,只對某個分片進行查詢便可。固然非get查詢,只要寫入和查詢的時候指定routing,一樣能夠達到該效果。
主分片與副本分片
ES的分片有主備之分,可是對於查詢來講,主備分片的地位徹底相同,平等的接收查詢請求。這裏涉及到一個請求的負載均衡策略,6.0以前採用的是輪詢的策略,可是這種策略存在不足,輪詢方案只能保證查詢數據量在主備分片是均衡的,可是不能保證查詢壓力在主備分片上是均衡的,可能出現慢查詢都路由到了主分片上,致使主分片所在的機器壓力過大,影響了整個集羣對外提供服務的能力。
新版本中優化了該策略,採用了基於負載的請求路由,基於隊列的耗費時間自動調節隊列長度,負載高的節點的隊列長度將減小,讓其餘節點分攤更多的壓力,搜索和索引都將基於這種機制。
get查詢的實時性
ES數據寫入以後,要通過一個refresh操做以後,纔可以建立索引,進行查詢。可是get查詢很特殊,數據實時可查。
ES5.0以前translog能夠提供實時的CRUD,get查詢會首先檢查translog中有沒有最新的修改,而後再嘗試去segment中對id進行查找。5.0以後,爲了減小translog設計的負責性以便於再其餘更重要的方面對translog進行優化,因此取消了translog的實時查詢功能。
get查詢的實時性,經過每次get查詢的時候,若是發現該id還在內存中沒有建立索引,那麼首先會觸發refresh操做,來讓id可查。
查詢方式
兩種查詢上下文:
query:例如全文檢索,返回的是文檔匹配搜索條件的相關性,經常使用api:match
filter:例如時間區間的限定,回答的是是否,要麼是,要麼不是,不存在類似程度的概念,經常使用api:term、range
過濾(filter)的目標是減小那些須要進行評分查詢(scoring queries)的文檔數量。
分析器(analyzer)
當索引一個文檔時,它的全文域被分析成詞條以用來建立倒排索引。當進行分詞字段的搜索的時候,一樣須要將查詢字符串經過相同的分析過程,以保證搜索的詞條格式與索引中的詞條格式一致。當查詢一個不分詞字段時,不會分析查詢字符串,而是搜索指定的精確值。
能夠經過下面的命令查看分詞結果:
GET /_analyze
{
"analyzer": "standard",
"text": "Text to analyze"
}
相關性
默認狀況下,返回結果是按相關性倒序排列的。每一個文檔都有相關性評分,用一個正浮點數字段score來表示。score的評分越高,相關性越高。
ES的類似度算法被定義爲檢索詞頻率/反向文檔頻率(TF/IDF),包括如下內容:
檢索詞頻率:檢索詞在該字段出現的頻率,出現頻率越高,相關性也越高。字段中出現過5次要比只出現過1次的相關性高。
反向文檔頻率:每一個檢索詞在索引中出現的頻率,頻率越高,相關性越低。檢索詞出如今多數文檔中會比出如今少數文檔中的權重更低。
字段長度準則:字段的長度是多少,長度越長,相關性越低。
檢索詞出如今一個短的title要比一樣的詞出如今一個長的content字段權重更大。
查詢的時候能夠經過添加?explain參數,查看上述各個算法的評分結果。
ES在Ad Tracking的應用
日誌查詢工具
TalkingData 移動廣告監測產品Ad Tracking(簡稱ADT)的系統會接收媒體發過來的點擊數據以及SDK發過來的激活和各類效果點數據,這些數據的處理過程正確與否相當重要。例如,設備的一條激活數據爲啥沒有歸因到點擊,這類問題的排查在Ad Tracking中很常見,經過將數據流中的各個處理環節的重要日誌統一發送到ES,能夠很方便的進行查詢,技術支持的同事能夠經過拼寫簡單的查詢條件排查客戶的問題。
索引按天建立:定時關閉歷史索引,釋放集羣資源
別名查詢:數據量增大以後,能夠經過拆分索引減輕寫入壓力,拆分以後的索引採用相同的別名,查詢服務不須要修改代碼
索引重要的設置:
{
"settings": {
"index": {
"refresh_interval": "120s",
"number_of_shards": "12",
"translog": {
"flush_threshold_size": "2048mb"
},
"merge": {
"scheduler": {
"max_thread_count": "1"
}
},
"unassigned": {
"node_left": {
"delayed_timeout": "180m"
}
}
}
}
}
索引mapping的設置
{
"properties": {
"action_content": {
"type": "string",
"analyzer": "standard"
},
"time": {
"type": "long"
},
"trackid": {
"type": "string",
"index": "not_analyzed"
}
}
}
sql插件,經過拼sql的方式,比起拼json更簡單
點擊數據存儲(kv存儲場景)
Ad Tracking收集的點擊數據是與廣告投放直接相關的數據,應用安裝以後,SDK會上報激活事件,系統會去查找這個激活事件是否來自於以前用戶點擊的某個廣告,若是是,那麼該激活就是一個推廣量,也就是投放的廣告帶來的激活。激活後續的效果點數據也都會去查找點擊,從點擊中獲取廣告投放的一些信息,因此點擊查詢在Ad Tracking的業務中相當重要。
業務的前期,點擊數據是存儲在Mysql中的,隨着後續點擊量的暴增,因爲Mysql不能橫向擴展,因此須要更換爲新的存儲。因爲ES擁有橫向擴展和強悍的搜索能力,而且以前日誌查詢工具中也一直使用ES,因此決定使用ES來進行點擊的存儲。
重要的設置
"refresh_interval": "1s"
"translog.flush_threshold_size": "2048mb"
"merge.scheduler.max_thread_count": 1
"unassigned.node_left.delayed_timeout": "180m"
結合業務進行系統優化
結合業務按期關閉索引釋放資源:Ad Tracking的點擊數據具備有效期的概念,超過有效期的點擊,激活不會去歸因。點擊有效期最長一個月,因此理論上天天建立的索引在一個月以後才能關閉。可是用戶配置的點擊有效期大部分都是一天,這大部分點擊在集羣中保存30天是沒有意義的,並且會佔用大部分的系統資源。因此根據點擊的這個業務特色,將天天建立的索引拆分紅兩個,一個是有效期是一天的點擊,一個是超過一天的點擊,有效期一天的點擊的索引在一天以後就能夠關閉,從而保證集羣中打開的索引的數據量維持在一個較少的水平。
結合業務將熱點數據單獨索引:激活和效果點數據都須要去ES中查詢點擊,可是二者對於點擊的查詢場景是有差別的,由於效果點事件(例如登陸、註冊等)歸因的時候不是去直接查找點擊,而是查找激活進而找到點擊,效果點要找的點擊必定是以前激活歸因到的,因此激活歸因到的這部分點擊也就是熱點數據。激活歸因到點擊以後,將這部分點擊單獨存儲到單獨的索引中,因爲這部分點擊量少不少,因此效果點查詢的時候很快。
索引拆分:Ad Tracking的點擊數據按天進行存儲,可是隨着點擊量的增大,單天的索引大小持續增大,尤爲是晚上的時候,merge須要合併的segment數量以及大小都很大,形成了很高的IO壓力,致使集羣的寫入受限。後續採用了拆分索引的方案,天天的索引按照上午9點和下午5點兩個時間點將索引拆分紅三個,因爲索引之間的segment合併是相互獨立的,只會在一個索引內部進行segment的合併,因此在每一個小索引內部,segment合併的壓力就會減小。
其餘調優
分片的數量
經驗值:
每一個節點的分片數量保持在低於每1GB堆內存對應集羣的分片在20-25之間。
分片大小爲50GB一般被界定爲適用於各類用例的限制。
JVM設置
堆內存設置:不要超過32G,在Java中,對象實例都分配在堆上,並經過一個指針進行引用。對於64位操做系統而言,默認使用64位指針,指針自己對於空間的佔用很大,Java使用一個叫做內存指針壓縮(compressed
oops)的技術來解決這個問題,簡單理解,使用32位指針也能夠對對象進行引用,可是一旦堆內存超過32G,這個壓縮技術再也不生效,實際上失去了更多的內存。
預留一半內存空間給lucene用,lucene會使用大量的堆外內存空間。
若是你有一臺128G的機器,一半內存也是64G,超過了32G,能夠經過一臺機器上啓動多個ES實例來保證ES的堆內存小於32G。
ES的配置文件中加入bootstrap.mlockall: true,關閉內存交換。
經過_cat api獲取任務執行狀況
GET http://localhost:9201/_cat/thread_pool?v&h=host,search.active,search.rejected,search.completed
完成(completed)
進行中(active)
被拒絕(rejected):須要特別注意,說明已經出現查詢請求被拒絕的狀況,多是線程池大小配置的過小,也多是集羣性能瓶頸,須要擴容。
小技巧
重建索引或者批量想ES寫歷史數據的時候,寫以前先關閉副本,寫入完成以後,再開啓副本。
ES默認用文檔id進行路由,因此經過文檔id進行查詢會更快,由於能直接定位到文檔所在的分片,不然須要查詢全部的分片。
使用ES本身生成的文檔id寫入更快,由於ES不須要驗證一次自定義的文檔id是否存在。
參考資料
https://www.elastic.co/guide/...
https://github.com/Neway6655/...
https://www.elastic.co/blog/f...
https://blog.csdn.net/zteny/a...
https://www.elastic.co/blog/m...