文章來源于作者:餓了么物流技術(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 實例巩割。
啟動所有節(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ù):
各種場景的數(shù)據(jù)查詢氯窍、統(tǒng)計饲常,導(dǎo)致數(shù)據(jù)庫必須加入各種字段的索引,大大增加了核心鏈路插入數(shù)據(jù)所需要的成本狼讨,嚴(yán)重影響了核心鏈路的并發(fā)度贝淤;大量的索引同時占用了很大的磁盤空間,也給線上 ddl 帶來的更大的風(fēng)險政供;
很多場景沒有辦法或者很難實現(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ù)如何存儲
考慮在不影響已有的業(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 集群
我們解決這個問題主要有兩點:
- 慢查詢需要有監(jiān)控措施捣炬;
- 提供給 ES 的查詢接口限流熊昌、降級措施需要做好。
前期設(shè)計工作一定要做好
尤其是對于 mapping 的設(shè)計湿酸,一旦設(shè)計的不合理婿屹,后期再想修改會很費勁,需要重新再長出一套同樣的東西供調(diào)用方使用推溃,然后才能徹底下掉老邏輯昂利,周期會很長。
做好 ES 集群的監(jiān)控很重要铁坎,否則出現(xiàn)問題蜂奸,就跟瞎子一樣,很難定位問題硬萍。
小結(jié)
以上扩所,便是本篇的全部內(nèi)容,Elasticsearch 里面可以講的有太多太多了襟铭,每個小點拿出來可能都能說上一番碌奉。本篇文章較淺,如果有您不滿意的的地方寒砖,希望可以多多指點赐劣,同時也希望本篇文章能夠?qū)δ兴斋@。
本文首發(fā)于 GitChat魁兼,未經(jīng)授權(quán)不得轉(zhuǎn)載,轉(zhuǎn)載需與 GitChat 聯(lián)系漠嵌。