Elasticsearch 入門及在大數(shù)據(jù)場景下的應(yīng)用

文章來源于作者:餓了么物流技術(shù)團隊 GitChat 上的分享。

開篇

Elasticsearch吩谦,簡稱 ES鸳谜,目前最火的搜索引擎,底層使用開源庫 Lucene式廷,擁有豐富的 REST API咐扭,開箱即用。分布式的數(shù)據(jù)存儲滑废、倒排索引等設(shè)計蝗肪,使其可以快速存儲、搜索蠕趁、分析海量數(shù)據(jù)薛闪。

當(dāng)你開始接觸 Elasticsearch 并開始使用到業(yè)務(wù)中時,你會發(fā)現(xiàn)對于 Elasticsearch 我們有太多的東西需要去學(xué)習(xí)俺陋,其入門較為簡單豁延,想要深入?yún)s是挺難的昙篙。好在 Elasticsearch 本身迭代更新還是挺快的,官網(wǎng)資料也挺詳細诱咏,各種玩法也趨于成熟苔可,所以對于初學(xué)者來說項目接入 Elasticsearch,也不需要過多的擔(dān)心實現(xiàn)難度問題袋狞。

本次分享將會從以下幾點來講解 ES:

  • ES 安裝

  • ES 的基本操作

  • ES 的核心機制

  • ES 在傳統(tǒng)數(shù)據(jù)庫無法滿足多種條件花式查詢情況下的大數(shù)據(jù)場景應(yīng)用

  • 一些踩坑經(jīng)歷

本篇文章從 ES 的安裝焚辅、操作到 ES 的應(yīng)用,由淺及深苟鸯,適用于初學(xué) ES 的用戶同蜻。由于篇幅原因,本篇文章會盡量講清楚文章的核心知識點早处,對于文章中有不懂的地方可以隨時交流湾蔓,希望可以幫助到大家。

ES 安裝

環(huán)境準(zhǔn)備

ES 的安裝環(huán)境很簡單陕赃,只需要提前準(zhǔn)備好 Java 環(huán)境(jdk1.8)卵蛉,和 ES 的安裝包即可,jdk1.8 的安裝在此省略么库,我們直接進入 ES 的安裝過程。

下載 ES 安裝包

curl -O -L https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.3.2.tar.gz

解壓文件

tar -zxvf elasticsearch-5.3.2.tar.gz 

修改配置文件

#es集群名稱
cluster.name: cluster-es-test 
#節(jié)點名稱甘有,另外兩個可以為node-1,node-2
node.name: master-1   
#索引數(shù)據(jù)存儲位置诉儒,注意給es賬戶授權(quán)        
path.data: /usr/local/es/data 
#日志文件存儲位置,注意給es賬戶授權(quán)
path.logs: /var/log/es  
#綁定的ip地址     
network.host: 0.0.0.0
#設(shè)置對外服務(wù)的http端口亏掀,默認(rèn)為9200       
http.port: 9200  
#設(shè)置節(jié)點間交互的tcp端口,默認(rèn)是9300             
transport.tcp.port: 9300    
#靜態(tài)設(shè)置設(shè)置主機列表忱反,每個值應(yīng)采用host:port或host的形式(其中port默認(rèn)為設(shè)置transport.profiles.default.port,如果未設(shè)置則返回transport.tcp.port)  
discovery.zen.ping.unicast.hosts: ["host1", "host2", "host3:9300"] 
#指定該節(jié)點是否有資格被選舉成為master節(jié)點(這里的true滤愕,不代表是master節(jié)點温算,只是有master節(jié)點的選舉資格)       
node.master: true
#允許該節(jié)點存儲數(shù)據(jù)(默認(rèn)開啟)             
node.data: false  
#注意如果需要裝head插件,需要解決跨域問題           
http.cors.allow-origin: "*"   

創(chuàng)建 ES 用戶

groupadd esg   
useradd esu -g esg 
chown -R esu:esg /home/es/elasticsearch-5.3.2

調(diào)整 jvm 參數(shù)

vim /home/es/elasticsearch-5.3.2/config/jvm.options 
-Xms1g
-Xmx1g

官方建議內(nèi)存設(shè)置低于系統(tǒng)內(nèi)存的一半间影,不要超過 32G(為什么不要超過 32G 可以翻閱一下資料注竿,這里就不展開了),假如物理機器有 128G魂贬,可以在機器上面運行兩個 ES 實例巩割。

資料:Heap:Sizing and Swapping

啟動所有節(jié)點

/home/es/elasticsearch-5.3.2/bin/elasticsearch -d

驗證

http://master1:9200

本章小結(jié)

本章主要以 master 節(jié)點來介紹 ES 的安裝過程,數(shù)據(jù)節(jié)點的安裝主要在于配置的不同付燥,啟動的時候可能會有一些失敗情況宣谈,注意觀察配置文件目錄里面的日志,在此不做展開键科,有關(guān)這方面的問題也可以隨時交流闻丑。

ES 的基本操作

本篇主要講述 ES 相對于傳統(tǒng)數(shù)據(jù)庫的增刪改查操作漩怎。

基本概念介紹及與傳統(tǒng)關(guān)系型數(shù)據(jù)庫類比

拿 MySQL 數(shù)據(jù)庫進行對比,數(shù)據(jù)庫相當(dāng)于 ES 中的索引(Indices)嗦嗡,數(shù)據(jù)庫中的表相當(dāng)于 ES 中的類型(types)勋锤,而表中的每一行相當(dāng)于一個類型里面文檔(Documents),而表中的每一列相當(dāng)于文檔中的每個字段(Fields)

Relational DB -> Databases     -> Tables   -> Rows        -> Columns
Elasticsearch -> Indices(數(shù)據(jù)庫)-> Types(表)-> Documents(行)-> Fields(字段)

創(chuàng)建索引

PUT /company?pretty
返回值
{
     "acknowledged": true,
     "shards_acknowledged": true
}

插入一條數(shù)據(jù)

PUT /company/user/1?pretty   #“1” 為es中索引中的_id,在索引中唯一表示一條數(shù)據(jù)
{
    "name": "張三",
    "age": 12,
    "sex": 1
}
返回值
{
    "_index": "company",
    "_type": "user",
    "_id": "1",
    "_version": 1,
    "result": "created",
    "_shards":{
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "created": true
}

修改數(shù)據(jù)

PUT /company/user/1?pretty 
{
    "name": "李四", #名稱做修改
    "age": 12,
    "sex": 1
}
返回值
{
    "_index": "company",
    "_type": "user",
    "_id": "1",
    "_version": 2,      #版本號變更為2
    "result": "updated",
    "_shards":{
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "created": false
}

可以看到的是文檔的版本號變更為 2酸钦, ES 中更新數(shù)據(jù)只能根據(jù)索引中的 _id 來更新數(shù)據(jù)怪得,在其內(nèi)部,其實是先刪除舊的文檔卑硫,再添加新的文檔徒恋。

刪除文檔

DELETE /company/user/1?pretty 
返回值
{
    "found": true,
    "_index": "company",
    "_type": "user",
    "_id": "1",
    "_version": 3,      #版本號變更為3
    "result": "deleted",
    "_shards":{
        "total": 2,
        "successful": 1,
        "failed": 0
    }
}

查詢數(shù)據(jù)

GET /company/user/1?pretty 
返回值
{
    "_index": "company",
    "_type": "user",
    "_id": "1",
    "_version": 4,      #再次寫入該數(shù)據(jù)后查詢版本號已變更為4
     "found": true,
    "_source":{
        "name": "李四",
        "age": 12,
        "sex": 1
    }
}

Query DSL

DSL:Domain Specified Language,特定領(lǐng)域的語言

http request body:請求體欢伏,可以用 json 的格式來構(gòu)建查詢語法入挣,比較方便,可以構(gòu)建各種復(fù)雜的語法硝拧,在此不做擴展了径筏。

本章小結(jié)

本章主要對于 ES 的增刪改查舉列說明了一下,主要是幫助大家理解 ES 的一些操作障陶,實際應(yīng)用中滋恬,會根據(jù)實際情況做響應(yīng)的優(yōu)化,每種操作可能不僅僅這樣的簡單抱究,在后面的實際應(yīng)用中恢氯,會有響應(yīng)的例子。

ES 的核心機制

ES 在面向用戶的時候鼓寺,操作起來非常簡單勋拟,這是因為 ES 內(nèi)部極力的影藏了其分布式系統(tǒng)復(fù)雜性,下面簡單的介紹 ES 的一些核心機制妈候。

  • 主備機制:和其他的分布式系統(tǒng)一樣敢靡,ES 也會采取主備機制來保證一些意外情況下數(shù)據(jù)的完整性,即es中索引的每個分片都會存在主索引和副本索引苦银。當(dāng)然副本索引也能夠提供查詢啸胧,也極大的提高了 ES 的吞吐量。

  • 容錯機制:當(dāng) ES 的 master 節(jié)點丟失的時候(此時集群會變?yōu)榧t色)墓毒,會從有資格成為主節(jié)點的機器中選取一個節(jié)點作為新的主節(jié)點(此時集群內(nèi)丟失部分 shard 分片吓揪,集群變?yōu)辄S色),之后將丟失主分片的副本分片升級為主分片所计,再將這些分片 copy 一份到其他的數(shù)據(jù)節(jié)點上(其中可能會因為數(shù)據(jù)的不平衡發(fā)生數(shù)據(jù)偏移)柠辞,之后集群會變?yōu)檎顟B(tài)(綠色)。

  • 并發(fā)控制:通過 version 版本號來做樂觀鎖并發(fā)控制主胧。系統(tǒng)會檢查傳遞給索引請求的版本號是否大于當(dāng)前存儲的文檔的版本叭首,如果大于則重建索引并使用傳入的版本號作為新的 version 值习勤,如果提供的值小于或等于存儲文檔的版本號,則會發(fā)生版本沖突焙格,索引操作將失敗图毕。在類似的問題處理中,最簡單的方法就是使用每次更新數(shù)據(jù)的時間戳來做版本號眷唉。

  • 路由機制:ES 通過路由算法( shard = hash(routing) % number_of_primary_shards)來確定 document 當(dāng)前屬于哪個分片予颤,默認(rèn)的 routing 值為 document 的 _id,通常我們也會指定別的 Field 來作為 ES 的 routing 值冬阳,來提高 ES 查詢的性能蛤虐,但是可能會引起數(shù)據(jù)的偏移,出現(xiàn)熱節(jié)點現(xiàn)象肝陪。所以 routing 值在選取時需要做充分的評估驳庭。

ES 在傳統(tǒng)數(shù)據(jù)庫無法滿足多種條件花式查詢情況下的大數(shù)據(jù)場景應(yīng)用

背景

隨著數(shù)據(jù)的增長,傳統(tǒng)的數(shù)據(jù)庫很難支撐現(xiàn)有的業(yè)務(wù):

  1. 各種場景的數(shù)據(jù)查詢氯窍、統(tǒng)計饲常,導(dǎo)致數(shù)據(jù)庫必須加入各種字段的索引,大大增加了核心鏈路插入數(shù)據(jù)所需要的成本狼讨,嚴(yán)重影響了核心鏈路的并發(fā)度贝淤;大量的索引同時占用了很大的磁盤空間,也給線上 ddl 帶來的更大的風(fēng)險政供;

  2. 很多場景沒有辦法或者很難實現(xiàn)霹娄,如:分頁、排序鲫骗、分組查詢。大體量數(shù)據(jù)的關(guān)系型數(shù)據(jù)庫設(shè)計者必然要考慮水平分庫踩晶,此時數(shù)據(jù)在這些操作上面將會異常麻煩执泰。此時我們引入了 ES,來處理允許一定延遲的數(shù)據(jù)查詢渡蜻、統(tǒng)計的業(yè)務(wù)术吝。

當(dāng)傳統(tǒng)數(shù)據(jù)庫面對這種大體量數(shù)據(jù)查詢而感到無力的時候,我們可以使用 ES 來處理這種業(yè)務(wù)

數(shù)據(jù)存儲

在聊數(shù)據(jù)存儲的時候茸苇,我先拋出幾個問題:

如大家所知的那樣排苍,ES 不支持事務(wù),其會利用 _version (版本號)的方式來確保應(yīng)用中相互沖突的變更不會導(dǎo)致數(shù)據(jù)丟失学密,那么我們是如何存儲我們的數(shù)據(jù)淘衙,數(shù)據(jù)結(jié)構(gòu)是什么樣子,如何保證數(shù)據(jù)的時效性腻暮、完整性和一致性的呢彤守?

數(shù)據(jù)結(jié)構(gòu)

首先需要合適的分片數(shù)和副本數(shù)毯侦。目前官方推薦的分片的大小為 20-40G,一般個人會控制在 30G 以內(nèi)具垫,主副本分片數(shù)條件允許的話建議等于節(jié)點數(shù)侈离。

網(wǎng)上有很多關(guān)于如何規(guī)劃分片數(shù)的文章,本人感覺可以作為參考筝蚕,在機器性能卦碾、數(shù)據(jù)量的大小、使用場景等等的不同起宽,分片數(shù)量最好可以通過壓測或者線上實際流量來做調(diào)整洲胖。

我們會盡量減少我們所需要的字段,做到夠用就好燎含,mapping 設(shè)置方面:設(shè)置"_all"為 false宾濒,String 類型"index"盡量設(shè)置為不分詞("not_analyzed",根據(jù)需要設(shè)置 analyzed)屏箍,如商家名稱這類 String 類型字段只存儲索引結(jié)構(gòu)绘梦,不存儲原始文檔(后面會聊到如何拿到原始文檔)。

起初我們在建索引的時候赴魁,我們是盡量冗余數(shù)據(jù)庫中的所有字段整合成一張寬表卸奉,導(dǎo)致每天的索引數(shù)據(jù)量很大,而上面大部分的字段都是不需要的颖御,磁盤利用率很低榄棵,而用于該集群的都是 ssd 盤,整體的磁盤容量并不高潘拱,常常由于磁盤存不下疹鳄,而需要添加機器,導(dǎo)致大量的資源浪費芦岂。另一方面瘪弓,盡量的減少我們所需要的字段,這也需要我們支持一個額外的能力禽最,萬一需要添加某個字段的時候腺怯,我們需要在需求上線之前迅速將歷史數(shù)據(jù)補齊這個字段,同時不影響線上川无。(我們現(xiàn)在可以一個晚上重刷我們需要周期內(nèi)的歷史數(shù)據(jù))呛占。

"mappings": {
    "index_type_name": {
    "_all": {
      "enabled": false
    },
    "_source": {
      "excludes": ["shop_name"]   #部分字段只存儲其索引部分,不存儲原始文檔(
    },
    "properties": {
      "order_id": {
        "type": "long"
      },
      "shop_name": {
        "type": "string",
        "index": "not_analyzed"   #提供該字段和關(guān)系型數(shù)據(jù)庫like關(guān)鍵字一樣功能的查詢不需要分詞
      }
     ...
    }
  }
}

以一天為一個索引(根據(jù)業(yè)務(wù)場景懦趋,因為我們的業(yè)務(wù)場景大部分要的都是某天的數(shù)據(jù))晾虑,這也為我們根據(jù)實際線上流量調(diào)整我們分片、副本數(shù)量提供了方便,修改完索引的模板("_template")之后走贪,第二天會自動生效佛猛,而查詢多天不同數(shù)量分片的索引的聯(lián)合查詢不會影響查詢結(jié)果。

注意:分片數(shù)一旦固定坠狡,那么一個已存在的索引是沒有辦法直接修改分片數(shù)继找,一般會采取 reindex 的方式重建索引.

盡量避免 Nested 數(shù)據(jù)類型。每一個 nested 將會作為一個隱藏的單獨文本建立索引逃沿,雖然官網(wǎng)上說在查詢的時候?qū)⒏谋竞?nested 文檔拼接是很快的婴渡,就跟把他們當(dāng)成一個單獨的文本一樣的快。但是其實還是有一部分的額外的消耗凯亮,尤其是在用 Nested 中的某個字段作為 aggs 聚合的時候边臼。如果真的需要放入數(shù)組類型的數(shù)據(jù),可以根據(jù)實際需求假消,轉(zhuǎn)化為一個字段柠并,直接建在主數(shù)據(jù)上面。

如:我們現(xiàn)在有一個索引富拗,里面有某個學(xué)校每天每個學(xué)生的學(xué)習(xí)臼予、生活情況,每個學(xué)生每天會產(chǎn)生一條數(shù)據(jù)】谢Γ現(xiàn)在我們想統(tǒng)計每個班級某天 中午吃飯時間小于 10 分鐘的人數(shù)粘拾、以及一天在校的用餐次數(shù),我們可以設(shè)計一個 nested Objects 數(shù)據(jù)結(jié)構(gòu)來存儲一天三餐的用餐情況创千,也可以在主數(shù)據(jù)上添加四個字段:早上吃飯所花時間缰雇,中午所花時間、晚上吃飯所花時間追驴,三餐在校用餐次數(shù)械哟,這樣就可以直接對著這四個字段進行數(shù)據(jù)統(tǒng)計。

盡量減少 script line 的使用殿雪。同樣的道理戒良,我們可以預(yù)先將需要用 script line 的中間值先存到主數(shù)據(jù)上面。避免查詢冠摄、統(tǒng)計時候的額外消耗。

數(shù)據(jù)如何存儲
image

考慮在不影響已有的業(yè)務(wù)情況下几缭,我們采取解析數(shù)據(jù)落庫產(chǎn)生的 binlog 日志來建索引(binlog 日志公司有一套解決方案河泳,不一定非要使用 binlog 日志,業(yè)務(wù)狀態(tài)變更發(fā)送的mq消息也是可以的年栓,另外阿里有開源的 Canal拆挥,用來做 binlog 日志解析的),使其與正常業(yè)務(wù)解耦

此時我們不會直接拿這條數(shù)據(jù)插入 ES纸兔,因為數(shù)據(jù)的狀態(tài)變化在同一個時刻可能會發(fā)生多次惰瓜,每次的數(shù)據(jù)插入不一定是數(shù)據(jù)庫當(dāng)前的最新狀態(tài),而且無論是 binlog 日志汉矿、還是狀態(tài)變化 MQ 消息都只是涵蓋了部分?jǐn)?shù)據(jù)崎坊,如果要數(shù)據(jù)在發(fā)送 MQ 消息的時候,把建索引所需要的數(shù)據(jù)補齊之后發(fā)送給你洲拇,對于的原有業(yè)務(wù)來說奈揍,會面臨經(jīng)常修改 MQ 消息結(jié)構(gòu)的問題,這已經(jīng)違背了我們要使其與正常業(yè)務(wù)解耦的初衷赋续,所以我們在收到這條數(shù)據(jù)變更的時候男翰,會通過 soa 接口的方式反查當(dāng)前寬表數(shù)據(jù),這樣補齊寬表數(shù)據(jù)之后再寫索引纽乱,這樣我們就可以拿到我們想要的任何最新數(shù)據(jù)蛾绎。

通過 ES 建索引的 **bulk api **減少與 ES 集群的交互次數(shù),提高數(shù)據(jù)寫入的吞吐量鸦列。

同一條數(shù)據(jù)租冠,在同一個時刻可能會在機器 A 和機器 B 中同時發(fā)生寫索引操作,機器 A 查詢到的是舊數(shù)據(jù)敛熬,機器 B 查詢到了新數(shù)據(jù)肺稀,但是寫入索引的時候機器 B 先寫入 ES 集群,機器 A 后寫入集群应民,導(dǎo)致數(shù)據(jù)錯誤话原。解決方案:每條數(shù)據(jù)寫入的時候,添加一個分布式鎖诲锹,相同唯一建的數(shù)據(jù)在同一個時刻只能有一條發(fā)生寫索引的動作繁仁,沒有獲得分布式鎖消息,丟入延遲隊列归园,下次再消費(由于存在 soa 接口重新反查當(dāng)前寬表數(shù)據(jù)黄虱,所以也不需要擔(dān)心消息亂序消費的問題)。

數(shù)據(jù)的補償(此處就不展開了)庸诱。

數(shù)據(jù)的查詢和統(tǒng)計

數(shù)據(jù)查詢

前面我們講述了我們 ES 中的索引結(jié)構(gòu)遵循的一些原則捻浦,其中有一條是,我們只存儲字段的索引部分來提供查詢桥爽,不會在 ES 中存儲原始文檔來提供輸出朱灿,那么當(dāng)查詢方需要該字段的信息的時候,我們需要怎么做钠四?其實這是一個 ES 集群的定位問題盗扒,我們的 ES 集群僅僅是用來豐富數(shù)據(jù)查詢、支持?jǐn)?shù)據(jù)統(tǒng)計的功能,我們并不支持?jǐn)?shù)據(jù)的實際存儲侣灶,我們存儲的僅僅只是每個字段的索引而已甸祭,通過每個字段的索引支持各種各樣的數(shù)據(jù)查詢、數(shù)據(jù)統(tǒng)計褥影,如果需要查詢數(shù)據(jù)的詳細信息池户,我們可以通過 ES 查詢得到數(shù)據(jù)的唯一鍵后,再通過 soa 接口來反查該數(shù)據(jù)伪阶,之后吐給需求方煞檩,我們會將這個步驟包掉昏兆,需求方無感知雌续,且返回的數(shù)據(jù)只是將原有的 soa 查詢接口的返回數(shù)據(jù)包了一層,讓其他方感知到的是原 soa 接口的升級版接口辑甜,盡可能減少其他方的接入成本檐薯。

[圖片上傳失敗...(image-e47026-1561369954378)]

基于 ES 的數(shù)據(jù)的統(tǒng)計

ES 在做數(shù)據(jù)統(tǒng)計的時候往往會很消耗 ES 集群的資源凝赛,所以我們通常不允許需求方直接通過接口訪問 ES,我們會將各個維度的數(shù)據(jù)提前算好放入其他類型的數(shù)據(jù)庫中坛缕,供業(yè)務(wù)方使用墓猎,此處也不進行展開了。

一些踩坑經(jīng)歷

同樣的查詢條件赚楚,前后連續(xù)兩次查詢出來的數(shù)據(jù)結(jié)果不一樣毙沾。

這是因為副本分片和主分片數(shù)據(jù)不一致(ES 只保證最終一致性),ES 在寫操作的時候有個 consistency 的參數(shù)來控制寫入的一致性宠页,具體值為one(primary shard)左胞,all(all shard),quorum(default)举户。

one:要求我們這個寫操作烤宙,只要有一個 primary shard 是 active 活躍可用的,就可以執(zhí)行俭嘁。

all:要求我們這個寫操作躺枕,必須所有的 primary shard 和 replica shard 都是活躍的,才可以執(zhí)行這個寫操作供填。

quorum:默認(rèn)的值拐云,要求所有的 shard 中,必須是大部分的 shard 都是活躍的近她,可用的慨丐,才可以執(zhí)行這個寫操作。

但是就算設(shè)置成了 all 之后泄私,查詢還是有不一致的情況,這是使用 lucene 索引機制帶來的 refresh 問題。

解決該問題需要將 write consistency 設(shè)置成為 all晌端,replication 是 sync 模式(默認(rèn))捅暴,每次寫入數(shù)據(jù)時候需要手工 refresh。如果是寫入很大的應(yīng)用不建議這樣去做咧纠。我們選取了另一種方式:對于會短時間內(nèi)出現(xiàn)前后兩次查詢蓬痒,且需要保證兩次查詢出來的數(shù)據(jù)強一致性的需求指定從 primary shard 讀。

ES 查詢成功漆羔,部分 shard 失敗

這個問題很尷尬梧奢,因為我在前期很長時間都沒注意到這個問題,發(fā)現(xiàn)查詢返回成功后演痒,就直接把結(jié)果丟出去了亲轨,并沒有注意到下面還有失敗 shards 數(shù)量,后來一次 ES 集群異常鸟顺,發(fā)現(xiàn)查詢出來的數(shù)據(jù)要比正常值普遍要小很多惦蚊,不可能是 ES 主、副本分片數(shù)據(jù)不一致的問題讯嫂,才發(fā)現(xiàn)是該問題蹦锋。

新增字段

新增字段的時候,一定要先更新所有已存在的索引的 Mapping欧芽,再更新 template莉掂,最后才能發(fā)布更新后的程序。

由于 ES 集群寫操作在默認(rèn)情況下千扔,Mapping 中沒有的字段憎妙,會被自動識別,而自動識別的字段可能不是我們想要的字段類型昏鹃,而這個時候想要不斷服務(wù)的修改尚氛,會很復(fù)雜。所以一定要在發(fā)新的程序之前修改好Mapping洞渤、template阅嘶。

定期進行段合并,導(dǎo)致線上大量報錯

有時候為了提高 ES 集群的性能载迄,我們會定期的手工做一些段合并讯柔,但是段合并的計算量龐大,而且會吃掉大量的磁盤 IO护昧,此時要注意設(shè)置段合并的線程數(shù)魂迄,避開業(yè)務(wù)高峰期,防止影響到正常業(yè)務(wù)惋耙。

慢查詢拖垮 ES 集群

我們解決這個問題主要有兩點:

  1. 慢查詢需要有監(jiān)控措施捣炬;
  2. 提供給 ES 的查詢接口限流熊昌、降級措施需要做好。

前期設(shè)計工作一定要做好

尤其是對于 mapping 的設(shè)計湿酸,一旦設(shè)計的不合理婿屹,后期再想修改會很費勁,需要重新再長出一套同樣的東西供調(diào)用方使用推溃,然后才能徹底下掉老邏輯昂利,周期會很長。

做好 ES 集群的監(jiān)控很重要铁坎,否則出現(xiàn)問題蜂奸,就跟瞎子一樣,很難定位問題硬萍。

小結(jié)

以上扩所,便是本篇的全部內(nèi)容,Elasticsearch 里面可以講的有太多太多了襟铭,每個小點拿出來可能都能說上一番碌奉。本篇文章較淺,如果有您不滿意的的地方寒砖,希望可以多多指點赐劣,同時也希望本篇文章能夠?qū)δ兴斋@。


拓展閱讀:《高可用 Elasticsearch 集群 21 講》哩都。

本文首發(fā)于 GitChat魁兼,未經(jīng)授權(quán)不得轉(zhuǎn)載,轉(zhuǎn)載需與 GitChat 聯(lián)系漠嵌。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末咐汞,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子儒鹿,更是在濱河造成了極大的恐慌化撕,老刑警劉巖,帶你破解...
    沈念sama閱讀 212,718評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件约炎,死亡現(xiàn)場離奇詭異植阴,居然都是意外死亡,警方通過查閱死者的電腦和手機圾浅,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,683評論 3 385
  • 文/潘曉璐 我一進店門掠手,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人狸捕,你說我怎么就攤上這事喷鸽。” “怎么了灸拍?”我有些...
    開封第一講書人閱讀 158,207評論 0 348
  • 文/不壞的土叔 我叫張陵做祝,是天一觀的道長砾省。 經(jīng)常有香客問我,道長混槐,這世上最難降的妖魔是什么纯蛾? 我笑而不...
    開封第一講書人閱讀 56,755評論 1 284
  • 正文 為了忘掉前任,我火速辦了婚禮纵隔,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘炮姨。我一直安慰自己捌刮,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 65,862評論 6 386
  • 文/花漫 我一把揭開白布舒岸。 她就那樣靜靜地躺著绅作,像睡著了一般。 火紅的嫁衣襯著肌膚如雪蛾派。 梳的紋絲不亂的頭發(fā)上俄认,一...
    開封第一講書人閱讀 50,050評論 1 291
  • 那天,我揣著相機與錄音洪乍,去河邊找鬼眯杏。 笑死,一個胖子當(dāng)著我的面吹牛壳澳,可吹牛的內(nèi)容都是我干的岂贩。 我是一名探鬼主播,決...
    沈念sama閱讀 39,136評論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼巷波,長吁一口氣:“原來是場噩夢啊……” “哼萎津!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起抹镊,我...
    開封第一講書人閱讀 37,882評論 0 268
  • 序言:老撾萬榮一對情侶失蹤锉屈,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后垮耳,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體颈渊,經(jīng)...
    沈念sama閱讀 44,330評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,651評論 2 327
  • 正文 我和宋清朗相戀三年氨菇,在試婚紗的時候發(fā)現(xiàn)自己被綠了儡炼。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,789評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡查蓉,死狀恐怖乌询,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情豌研,我是刑警寧澤妹田,帶...
    沈念sama閱讀 34,477評論 4 333
  • 正文 年R本政府宣布唬党,位于F島的核電站,受9級特大地震影響鬼佣,放射性物質(zhì)發(fā)生泄漏驶拱。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 40,135評論 3 317
  • 文/蒙蒙 一晶衷、第九天 我趴在偏房一處隱蔽的房頂上張望蓝纲。 院中可真熱鬧,春花似錦晌纫、人聲如沸税迷。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,864評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽箭养。三九已至,卻和暖如春哥牍,著一層夾襖步出監(jiān)牢的瞬間毕泌,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,099評論 1 267
  • 我被黑心中介騙來泰國打工嗅辣, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留撼泛,地道東北人。 一個月前我還...
    沈念sama閱讀 46,598評論 2 362
  • 正文 我出身青樓辩诞,卻偏偏與公主長得像坎弯,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子译暂,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,697評論 2 351

推薦閱讀更多精彩內(nèi)容