如何進(jìn)行Elasticsearch集群運(yùn)維-創(chuàng)新互聯(lián)

本篇文章給大家分享的是有關(guān)如何進(jìn)行Elasticsearch集群運(yùn)維，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比綿竹網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式綿竹網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋綿竹地區(qū)。費(fèi)用合理售后完善，10余年實體公司更值得信賴。

Meltwater每天要處理數(shù)百萬量級的帖子數(shù)據(jù)，因此需要一種能處理該量級數(shù)據(jù)的存儲和檢索技術(shù)。

從0.11.X 版本開始我們就已經(jīng)是Elasticsearch的忠實用戶了。在經(jīng)歷了一些波折之后，最終我們認(rèn)為做出了正確的技術(shù)選型。

Elasticsearch用于支持我們的主要媒體監(jiān)控應(yīng)用，客戶通過該應(yīng)用可以檢索和分析媒體數(shù)據(jù)，比如新聞文章、（公開的）Facebook帖子、Instagram帖子、博客和微博。我們通過使用一個混合API來收集這些內(nèi)容，并爬取和稍作加工，使得它們可被Elasticsearch檢索到。

小編將分享我們所學(xué)到的經(jīng)驗、如何調(diào)優(yōu)Elasticsearch，以及要繞過的一些陷阱。

數(shù)據(jù)量

---

每天都有數(shù)量相當(dāng)龐大的新聞和微博產(chǎn)生；在高峰期需要索引大約300多萬社論文章，和近1億條社交帖子數(shù)據(jù)。其中社論數(shù)據(jù)長期保存以供檢索（可回溯到2009年），社交帖子數(shù)據(jù)保存近15個月的。當(dāng)前的主分片數(shù)據(jù)使用了大約200 TB的磁盤空間，副本數(shù)據(jù)大約600 TB。

我們的業(yè)務(wù)每分鐘有3千次請求。所有的請求通過一個叫做“search-service”的服務(wù)，該服務(wù)會依次完成所有與Elasticsearch集群的交互。大部分檢索規(guī)則比較復(fù)雜，包括在面板和新聞流中。比如，一個客戶可能對Tesla和Elon Musk感興趣，但希望排除所有關(guān)于SpaceX或PayPal的信息。用戶可以使用一種與Lucene查詢語法類似的靈活語法，如下：

Tesla AND "Elon Musk" NOT (SpaceX OR PayPal)

我們最長的此類查詢有60多頁。重點是：除了每分鐘3千次請求以外，沒有一個查詢是像在Google里查詢“Barack Obama”這么簡單的；這簡直就是可怕的野獸，但ES節(jié)點必須努力找出一個匹配的文檔集。

版本

---

我們運(yùn)行的是一個基于Elasticsearch 1.7.6的定制版本。該版本與1.7.6 主干版本的唯一區(qū)別是，我們向后移植（backport）了roaring bitsets/bitmaps（http://suo.im/5bE6od） 作為緩存。該功能是從Lucene 5移植到Lucene 4的，對應(yīng)移植到了ES 1.X版本。Elasticsearch 1.X中使用默認(rèn)的bitset作為緩存，對于稀疏結(jié)果來說開銷非常大，不過在Elasticsearch 2.X中已經(jīng)做了優(yōu)化。

為何不使用較新版本的Elasticsearch呢？主要原因是升級困難。在主版本間滾動升級只適用于從ES 5到6（從ES 2到5應(yīng)該也支持滾動升級，但沒有試過）。因此，我們只能通過重啟整個集群來升級。宕機(jī)對我們來說幾乎不可接受，但或許可以應(yīng)對一次重啟所帶來的大約30-60分鐘宕機(jī)時間；而真正令人擔(dān)心的，是一旦發(fā)生故障并沒有真正的回滾過程。

截止目前我們選擇了不升級集群。當(dāng)然我們希望可以升級，但目前有更為緊迫的任務(wù)。實際上該如何實施升級尚未有定論，很可能選擇創(chuàng)建另一個新的集群，而不是升級現(xiàn)有的。

節(jié)點配置

---

我們自2017年6月開始在AWS上運(yùn)行主集群，使用i3.2xlarge實例作為數(shù)據(jù)節(jié)點。之前我們在COLO（Co-located Data Center）里運(yùn)行集群，但后續(xù)遷移到了AWS云，以便在新機(jī)器宕機(jī)時能贏得時間，使得我們在擴(kuò)容和縮容時更加彈性。

我們在不同的可用區(qū)運(yùn)行3個候選master節(jié)點，并設(shè)置discovery.zen.minimum_master_nodes為2。這是避免腦裂問題split-brain problem（https://qbox.io/blog/split-brain-problem-elasticsearch）非常通用的策略。

我們的數(shù)據(jù)集在存儲方面，要求80%容量和3個以上的副本，這使得我們運(yùn)行了430個數(shù)據(jù)節(jié)點。起初打算使用不同層級的數(shù)據(jù)，在較慢的磁盤上存儲較舊的數(shù)據(jù)，但是由于我們只有相關(guān)的較低量級舊于15個月的數(shù)據(jù)（只有編輯數(shù)據(jù)，因為我們丟棄了舊的社交數(shù)據(jù)），然而這并未奏效。每個月的硬件開銷遠(yuǎn)大于運(yùn)行在COLO中，但是云服務(wù)支持?jǐn)U容集群到2倍，而幾乎不用花費(fèi)多少時間。

你可能會問，為何選擇自己管理維護(hù)ES集群。其實我們考慮過托管方案，但最后還是選擇自己安裝，理由是：AWS Elasticsearch Service（http://suo.im/4PLuXa）暴露給用戶的可控性太差了，Elastic Cloud（https://www.elastic.co/cn/cloud）的成本比直接在EC2上運(yùn)行集群要高2-3倍。

為了在某個可用區(qū)宕機(jī)時保護(hù)我們自身，節(jié)點分散于eu-west-1的所有3個可用區(qū)。我們使用AWS plugin（http://suo.im/5qFQEP）來完成該項配置。它提供了一個叫做aws_availability_zone的節(jié)點屬性，我們把cluster.routing.allocation.awareness.attributes
設(shè)置為aws_availability_zone。這保證了ES的副本盡可能地存儲在不同的可用區(qū)，而查詢盡可能被路由到相同可用區(qū)的節(jié)點。

這些實例運(yùn)行的是Amazon Linux，臨時掛載為ext4，有約64GB的內(nèi)存。我們分配了26GB用于ES節(jié)點的堆內(nèi)存，剩下的用于磁盤緩存。為何是26GB？因為JVM是在一個黑魔法之上構(gòu)建的（https://www.elastic.co/blog/a-heap-of-trouble）。

我們同時使用Terraform（https://www.terraform.io/）自動擴(kuò)容組來提供實例，并使用Puppet（https://puppet.com/）完成一切安裝配置。

索引結(jié)構(gòu)

---

因為我們的數(shù)據(jù)和查詢都是基于時間序列的，所以使用了
time-based indexing（http://suo.im/547GbE），
類似于ELK (elasticsearch, logstash, kibana) stack（https://www.elastic.co/elk-stack）。同時也讓不同類型的數(shù)據(jù)保存在不同的索引庫中，以便諸如社論文檔和社交文檔類數(shù)據(jù)最終位于不同的每日索引庫中。這樣可以在需要的時候只丟棄社交索引，并增加一些查詢優(yōu)化。每個日索引運(yùn)行在兩個分片中的一個。

該項設(shè)置產(chǎn)生了大量的分片（接近40k）。有了這么多的分片和節(jié)點，集群操作有時變得更特殊。比如，刪除索引似乎成為集群master的能力瓶頸，它需要把集群狀態(tài)信息推送給所有節(jié)點。我們的集群狀態(tài)數(shù)據(jù)約100 MB，但通過TCP壓縮可減少到3 MB
（可以通過curl localhost:9200/_cluster/state/_all 查看你自己集群的狀態(tài)數(shù)據(jù)）。Master節(jié)點仍然需要在每次變更時推送1.3 GB數(shù)據(jù)（430 節(jié)點 x 3 MB 狀態(tài)大小）。除了這1.3 GB數(shù)據(jù)外，還有約860 MB必須在可用區(qū)（比如 最基本的通過公共互聯(lián)網(wǎng)）之間傳輸。這會比較耗時，尤其是在刪除數(shù)百個索引時。我們希望新版本的Elasticsearch能優(yōu)化這一點，首先從ES 2.0支持僅發(fā)送集群狀態(tài)的差分?jǐn)?shù)據(jù)(http://suo.im/547UyM)這一特性開始。

Performance 性能

---

如前所述，我們的ES集群為了滿足客戶的檢索需求，需要處理一些非常復(fù)雜的查詢。

為應(yīng)對查詢負(fù)載，過去幾年我們在性能方面做了大量的工作。我們必須嘗試公平分享ES集群的性能測試，從下列引文就可以看出。

不幸的是，當(dāng)集群宕機(jī)的時候，不到三分之一的查詢能成功完成。我們相信測試本身導(dǎo)致了集群宕機(jī)。 

—— 摘錄自使用真實查詢在新ES集群平臺上的第一次性能測試

為了控制查詢執(zhí)行過程，我們開發(fā)了一個插件，實現(xiàn)了一系列自定義查詢類型。通過使用這些查詢類型來提供Elasticsearch官方版本不支持的功能和性能優(yōu)化。比如，我們實現(xiàn)了phrases中的wildcard查詢，支持在SpanNear查詢中執(zhí)行；另一個優(yōu)化是支持“*”代替match-all-query；還有其他一系列特性。

Elasticsearch和Lucene的性能高度依賴于具體的查詢和數(shù)據(jù)，沒有銀彈。即便如此，仍可給出一些從基礎(chǔ)到進(jìn)階的參考：

• 限制你的檢索范圍，僅涉及相關(guān)數(shù)據(jù)。比如，對于每日索引庫，只按相關(guān)日期范圍檢索。對于檢索范圍中間的索引，避免使用范圍查詢/過濾器。

• 使用wildcards時忽略前綴wildcards - 除非你能對term建立倒排索引。雙端wildcards難以優(yōu)化。

• 關(guān)注資源消耗的相關(guān)跡象 數(shù)據(jù)節(jié)點的CPU占用持續(xù)飆高嗎？IQ等待走高嗎？看看GC統(tǒng)計。這些可以從profilers工具或者通過JMX代理獲得。如果ParNewGC消耗了超過15%的時間，去檢查下內(nèi)存日志。如果有任何的SerialGC停頓，你可能真的遇到問題了。不太了解這些內(nèi)容？

• 沒關(guān)系，這個系列博文很好地介紹了JVM性能（http://suo.im/4AJgps） 。

• 記住，ES和G1垃圾回收器一起并非最佳（http://suo.im/4WBTA5）。

• 如果遇到垃圾回收問題，請不要嘗試調(diào)整GC設(shè)置。這一點經(jīng)常發(fā)生，因為默認(rèn)設(shè)置已經(jīng)很合理了。相反，應(yīng)該聚焦在減少內(nèi)存分配上。具體怎么做？參考下文。

• 如果遇到內(nèi)存問題，但沒有時間解決，可考慮查詢Azul Zing。這是一個很貴的產(chǎn)品，但僅僅使用它們的JVM就可以提升2倍的吞吐量。不過最終我們并沒有使用它，因為我們無法證明物有所值。

• 考慮使用緩存，包括Elasticsearch外緩存和Lucene級別的緩存。在Elasticsearch 1.X中可以通過使用filter來控制緩存。之后的版本中看起來更難一些，但貌似可以實現(xiàn)自己用于緩存的查詢類型。我們在未來升級到2.X的時候可能會做類似的工作。

• 查看是否有熱點數(shù)據(jù)（比如某個節(jié)點承擔(dān)了所有的負(fù)載）。可以嘗試均衡負(fù)載，使用分片分配過濾策略shard allocation filtering
  （http://suo.im/4IfruL），或者嘗試通過集群重新路由
  cluster rerouting（http://suo.im/5ja7cU）

• 來自行遷移分片。我們已經(jīng)使用線性優(yōu)化自動重新路由，但使用簡單的自動化策略也大有幫助。

• 搭建測試環(huán)境（我更喜歡筆記本）可從線上環(huán)境加載一部分代表性的數(shù)據(jù)（建議至少有一個分片）。使用線上的查詢回放加壓（較難）。使用本地設(shè)置來測試請求的資源消耗。
  綜合以上各點，在Elasticsearch進(jìn)程上啟用一個profiler。這是本列表中最重要的一條。

• 我們同時通過Java Mission Control （http://suo.im/4zYEsP）和 VisualVM （http://suo.im/4AJeIM）使用飛行記錄器。在性能問題上嘗試投機(jī)（包括付費(fèi)顧問/技術(shù)支持）的人是在浪費(fèi)他們（以及你自己）的時間。排查下JVM哪部分消耗了時間和內(nèi)存，然后探

  索下Elasticsearch/Lucene源代碼，檢查是哪部分代碼在執(zhí)行或者分配內(nèi)存。

• 一旦搞清楚是請求的哪一部分導(dǎo)致了響應(yīng)變慢，你就可以通過嘗試修改請求來優(yōu)化（比如，修改term聚合的執(zhí)行提示（http://suo.im/4WBUJx），或者切換查詢類型）。修改查詢類型或者查詢順序，可以有較大影響。如果不湊效，還可以嘗試優(yōu)化ES/Lucene代碼。這看起來太夸張，卻可以為我們降低3到4倍的CPU消耗和4到8倍的內(nèi)存使用。某些修改很細(xì)微（比如 indices query （http://suo.im/4WBUR7）），但其他人可能要求我們完全重寫查詢執(zhí)行。最終的代碼嚴(yán)重依賴于我們的查詢模式，所以可能適合也可能不適合他人使用。因此目前為止我們并沒有開源這部分代碼。不過這可能是下一篇博文的好素材。

圖表說明：響應(yīng)時間。有/沒有 重寫Lucene查詢執(zhí)行。同時也表明不再有節(jié)點每天多次發(fā)生內(nèi)存不足。

順便說明下，因為我知道會面臨一個問題：從上一次性能測試我們知道通過升級到ES 2.X能小幅提升性能，但是并不能改變什么。話雖如此，但如果你已經(jīng)從ES 1.X集群遷移到了ES 2.X，我們很樂意聽取關(guān)于你如何完成遷移的實踐經(jīng)驗。

如果讀到了這里，說明你對Elasticsearch是真愛?。ɑ蛘咧辽倌闶钦娴男枰?。我們很樂意學(xué)習(xí)你的經(jīng)驗，以及任何可以分享的內(nèi)容。歡迎在評論區(qū)分享你的反饋和問題。

以上就是如何進(jìn)行Elasticsearch集群運(yùn)維，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。

網(wǎng)站題目：如何進(jìn)行Elasticsearch集群運(yùn)維-創(chuàng)新互聯(lián)
當(dāng)前URL：http://muchs.cn/article42/cochhc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、App開發(fā)、Google、企業(yè)網(wǎng)站制作、做網(wǎng)站、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)