一、產(chǎn)生背景

? 互聯(lián)網(wǎng)發(fā)展早期的時候，對于一般的公司儲存的數(shù)據(jù)量不是那么的大，所以很多公司更傾向于使用數(shù)據(jù)庫去存儲和查詢數(shù)據(jù)，如：現(xiàn)在去MySQL中查詢數(shù)據(jù)，大概的查詢方式就是：select * from table where filed like “%XXX%”或者其他方式，但是，如果我們在查詢的時候沒有用到或命中數(shù)據(jù)庫建立的索引話，則會掃描整張表，即便是MySQL做過單表查詢能力優(yōu)化，但是他的極限也只在400萬左右，且還會經(jīng)常出現(xiàn)超時現(xiàn)象，讓后為了解決這些問題，。很多公司就開始對數(shù)據(jù)庫進行拆分（水平拆分和垂直拆分），這樣雖然是解決查詢效率的問題，但是也引入了新的問題：1、垂直拆分的話會出現(xiàn)數(shù)據(jù)庫單點故障，先天的主從復(fù)制關(guān)系，增加了公司的運維成本；2、對表進行拆分的話，增加維護難度和增加公司運維成本；3、即使做了大量的維護，但在大數(shù)據(jù)的條件下對于數(shù)據(jù)的檢索還是達不到期望的值。隨著在業(yè)務(wù)的不斷擴展，數(shù)據(jù)量的不斷膨脹，顯然，傳統(tǒng)的查詢方式已然不能夠滿足用戶的需求，因此就出現(xiàn)了ES這個強大的分布式的，基于RESTful風格的全文搜索引擎。

1、傳統(tǒng)方式：

2、Es方式：

二、應(yīng)用場景

1、作為數(shù)據(jù)庫（代替MySQL）；

• 前提：沒有頻繁更新（一秒內(nèi)有大量的更改操作），不需要事務(wù)處理，需要對數(shù)據(jù)進行檢索，統(tǒng)計；
• 優(yōu)點：容錯性好；單點故障時，可以通過復(fù)制數(shù)據(jù)到不同的服務(wù)器上達到容錯的目的；

2、在大數(shù)據(jù)條件下做檢索服務(wù)、同義詞處理、相關(guān)度排名、復(fù)雜數(shù)據(jù)分析、海量數(shù)據(jù)的近實時處理；

3、記錄和日志的分析

   * 可以使用ELK對海量的數(shù)據(jù)進行近實時的處理，對復(fù)雜的日志進行收集分析

4、全文檢索

5、關(guān)系型數(shù)據(jù)庫的補充，傳統(tǒng)數(shù)據(jù)庫的替代

6、站內(nèi)搜索、垂直搜索

• 很多電商網(wǎng)站可以說是站內(nèi)搜索

• 垂直搜索：是針對某一行業(yè)的專業(yè)搜索引擎，是搜索的細分和延伸，對網(wǎng)頁庫中的某類專門的信息做一次整合，定向分字段抽取出

  要的數(shù)據(jù)進行處理后再以某種形式返回給用戶。

  • 相較于通用搜索引擎的信息量大，查詢不準確，深度不夠，垂直搜索作為新的搜索引擎服務(wù)模式，通過針對某一特定領(lǐng)域，某一特人群或者是某一特定需求，提供的有一定價值的信息和相關(guān)服務(wù)，更加專注、具體和深入，且具有一定的行業(yè)色彩。

  • 通俗意義上，垂直搜索引擎是網(wǎng)站、APP 里面提供的搜索窗口，讓用戶通過搜索關(guān)鍵詞就能直達目標內(nèi)容。

  • 例如：

    ? 1、淘寶、天貓、京東是電商商品領(lǐng)域的垂直搜索引擎。

  ? 2、知乎是知識問答領(lǐng)域的垂直搜索引擎。

  ? 3、谷歌、百度、必應(yīng)則是面向通用領(lǐng)域、索引海量信息、試圖服務(wù)全網(wǎng)用戶的通用搜索引擎。

三、基礎(chǔ)架構(gòu)/核心流程

1、基本概念：

? elasticsearch設(shè)計的理念就是分布式搜索引擎，底層實現(xiàn)是基于Lucene的，核心思想是在多態(tài)機器上啟動多個es進程實例，組成一個es集群。

• 接近實時
  es是一個接近實時的搜索平臺，這就意味著，從索引一個文檔直到文檔能夠被搜索到有一個輕微的延遲

• 集群（cluster）
  一個集群有多個節(jié)點（服務(wù)器）組成，通過所有的節(jié)點一起保存你的全部數(shù)據(jù)并且通過聯(lián)合索引和搜索功能的節(jié)點的集合，每一個集群有一個唯一的名稱標識

• 節(jié)點（node）
  一個節(jié)點就是一個單一的服務(wù)器，是你的集群的一部分，存儲數(shù)據(jù)，并且參與集群和搜索功能，一個節(jié)點可以通過配置特定的名稱來加入特定的集群，在一個集群中，你想啟動多少個節(jié)點就可以啟動多少個節(jié)點。

• 索引（index）
  一個索引就是還有某些共有特性的文檔的集合，一個索引被一個名稱唯一標識，并且這個名稱被用于索引通過文檔去執(zhí)行搜索，更新和刪除操作。

• 類型（type）
  type 在6.0.0已經(jīng)不贊成使用

• 文檔（document）
  一個文檔是一個基本的搜索單元

總結(jié)：
ES中，存儲數(shù)據(jù)的基本單位就是索引，比如說ES中存儲了一些訂單系統(tǒng)的銷售數(shù)據(jù)，就因該在ES中創(chuàng)建一個索引（order—index），所有的銷售數(shù)據(jù)就會都寫到這個索引里面去，一個索引就像一個數(shù)據(jù)庫，而type就相當于每一張表。一個index里面可以有多個type，而mapping就相當于表的結(jié)構(gòu)定義，定義了什么字段類型等，你往index的一個type里添加一行數(shù)據(jù)就叫做一個document，每一個document有多個filed，每一個filed就代表這個document的一個字段的值。

• 分片（shards）

  ? 在一個搜索里存儲的數(shù)據(jù)，潛在的情況下可能會超過單個節(jié)點的硬件的存儲限制，為了解決這個問題，elasticsearch便提供了分片的功能，它可以將索引劃分為多個分片，當你創(chuàng)建一個索引的時候，你就可以簡單的定義你想要的分片的數(shù)量，每一個分片本身是一個全功能的完全獨立的索引，可以部署到集群中的任何一個節(jié)點。分片的兩個總要原因：
  （1）它允許你水平切分你的內(nèi)容卷
  （2）它允許通過分片來分布和并執(zhí)行操作來應(yīng)對日益增長的執(zhí)行量

• 復(fù)制（replica）
  在一個網(wǎng)絡(luò)情況下，故障可能會隨時發(fā)生，有一個故障恢復(fù)機制是必須的，為了達到這個目的，ES允許你制作一個或多個拷貝放入一個叫做復(fù)制分片或短暫的復(fù)制品中。復(fù)制對于以下兩個主要原因很重要
  （1）高可用。它提供了高可用的以來防止分片或者節(jié)點宕機，為此，一個非常重要的注意點就是絕對不要將一個分片的拷貝放在跟這個分片相同的機器上。
  （2）高并發(fā)。它允許你的分片可以提供超出自身吞吐量的搜索服務(wù)，搜索行為可以在分片所有的拷貝中并行執(zhí)行。

2、ES的核心流程：

（1）ES的寫數(shù)據(jù)的過程：

? ES客戶端將一份數(shù)據(jù)寫入primary shard,它會將分成成對的shard分片，并將數(shù)據(jù)進行復(fù)制；Elasticsearch采用多Shard方式，通過配置routing規(guī)則將數(shù)據(jù)分成多個數(shù)據(jù)子集，每個數(shù)據(jù)子集提供獨立的索引和搜索功能。當寫入文檔的時候，根據(jù)routing規(guī)則，將文檔發(fā)送給特定Shard中建立索引。以這樣的方式來實現(xiàn)分布式系統(tǒng)；

每個Index由多個Shard組成，每個Shard有一個主節(jié)點和多個副本節(jié)點，副本個數(shù)可配。但每次寫入的時候，寫入請求會先根據(jù)_routing規(guī)則選擇發(fā)給哪個Shard，Index Request中可以設(shè)置使用哪個Filed的值作為路由參數(shù)，如果沒有設(shè)置，則使用Mapping中的配置，如果mapping中也沒有配置，則使用_id作為路由參數(shù)，然后通過_routing的Hash值選擇出Shard（在OperationRouting類中），最后從集群的Meta中找出出該Shard的Primary節(jié)點。

? 請求接著會發(fā)送給Primary Shard，在Primary Shard上執(zhí)行成功后，再從Primary Shard上將請求同時發(fā)送給多個Replica Shard，請求在多個Replica Shard上執(zhí)行成功并返回給Primary Shard后，寫入請求執(zhí)行成功，返回結(jié)果給客戶端。

? 這種模式下，寫入操作的延時就等于latency = Latency(Primary Write) + Max(Replicas Write)。只要有副本在，寫入延時最小也是兩次單Shard的寫入時延總和，寫入效率會較低，但是這樣的好處也很明顯，避免寫入后，單機或磁盤故障導(dǎo)致數(shù)據(jù)丟失，在數(shù)據(jù)重要性和性能方面，一般都是優(yōu)先選擇數(shù)據(jù)，除非一些允許丟數(shù)據(jù)的特殊場景。

單獨的每一個節(jié)點中的操作：

? 在每一個Shard分片中，寫入流程分為兩部分，先寫入Lucene，再寫入TransLog。寫入請求到達Shard后，先寫Lucene文件，創(chuàng)建好索引，此時索引還在內(nèi)存里面，接著去寫TransLog，寫完TransLog后，刷新TransLog數(shù)據(jù)到磁盤上，寫磁盤成功后，請求返回給用戶。這里有幾個關(guān)鍵點:

• 一是和數(shù)據(jù)庫不同，數(shù)據(jù)庫是先寫CommitLog，然后再寫內(nèi)存，而Elasticsearch是先寫內(nèi)存，最后才寫TransLog，一種可能的原因是Lucene的內(nèi)存寫入會有很復(fù)雜的邏輯，很容易失敗，比如分詞，字段長度超過限制等，比較重，為了避免TransLog中有大量無效記錄，減少recover的復(fù)雜度和提高速度，所以就把寫Lucene放在了最前面。
• 二是寫Lucene內(nèi)存后，并不是可被搜索的，需要通過Refresh把內(nèi)存的對象轉(zhuǎn)成完整的Segment后，然后再次reopen后才能被搜索，一般這個時間設(shè)置為1秒鐘，導(dǎo)致寫入Elasticsearch的文檔，最快要1秒鐘才可被從搜索到，所以Elasticsearch在搜索方面是NRT（Near Real Time）近實時的系統(tǒng)。
• 三是當Elasticsearch作為NoSQL數(shù)據(jù)庫時，查詢方式是GetById，這種查詢可以直接從TransLog中查詢，這時候就成了RT（Real Time）實時系統(tǒng)。四是每隔一段比較長的時間，比如30分鐘后，Lucene會把內(nèi)存中生成的新Segment刷新到磁盤上，刷新后索引文件已經(jīng)持久化了，歷史的TransLog就沒用了，會清空掉舊的TransLog。
  

擴展：增加transLog的原因：當機器宕機或者掛掉，保證內(nèi)存中的數(shù)據(jù)不會丟失

? 原因：采用多個副本后，避免了單機或磁盤故障發(fā)生時，對已經(jīng)持久化后的數(shù)據(jù)造成損害，但是Elasticsearch里為了減少磁盤IO保證讀寫性能，一般是每隔一段時間（比如5分鐘）才會把Lucene的Segment寫入磁盤持久化，對于寫入內(nèi)存，但還未Flush到磁盤的Lucene數(shù)據(jù)，如果發(fā)生機器宕機或者掉電，那么內(nèi)存中的數(shù)據(jù)也會丟失，這時候如何保證？

（2）ES的讀數(shù)據(jù)的過程

? 查詢，GET某一條的數(shù)據(jù)，寫入某個document，這個document會自動給你分配一個全局的唯一ID，同時跟住這個ID進行hash路由到對應(yīng)的primary shard上面去，當然也可以手動的設(shè)置ID

1. 客戶端發(fā)送任何一個請求到任意一個node，成為coordinate node
2. coordinate node 對document進行路由，將請求轉(zhuǎn)發(fā)到對應(yīng)的node，此時會使用round-robin隨機輪訓(xùn)算法，在primary shard 以及所有的replica中隨機選擇一個，讓讀請求負載均衡，
3. 接受請求的node，返回document給coordinate note
4. coordinate node返回給客戶端

（3）ES的搜索數(shù)據(jù)過程

• 客戶端發(fā)送一個請求給coordinate node

• 協(xié)調(diào)節(jié)點將搜索的請求轉(zhuǎn)發(fā)給所有的shard對應(yīng)的primary shard 或replica shard

• query phase：每一個shard 將自己搜索的結(jié)果（其實也就是一些唯一標識），返回給協(xié)調(diào)節(jié)點，有協(xié)調(diào)節(jié)點進行數(shù)據(jù)的合并，排序，分頁等操作，產(chǎn)出最后的結(jié)果

• fetch phase ，接著由協(xié)調(diào)節(jié)點，根據(jù)唯一標識去各個節(jié)點進行拉去數(shù)據(jù)，最總返回給客戶端

• 底層原理：

查詢過程大體上分為查詢和取回這兩個階段，廣播查詢請求到所有相關(guān)分片，并將它們的響應(yīng)整合成全局排序后的結(jié)果集合，這個結(jié)果集合會返回給客戶端。

• 查詢階段

1. 當一個節(jié)點接收到一個搜索請求，這這個節(jié)點就會變成協(xié)調(diào)節(jié)點，第一步就是將廣播請求到搜索的每一個節(jié)點的分片拷貝，查詢請求可以被某一個主分片或某一個副分片處理，協(xié)調(diào)節(jié)點將在之后的請求中輪訓(xùn)所有的分片拷貝來分攤負載。
2. 每一個分片將會在本地構(gòu)建一個優(yōu)先級隊列，如果客戶端要求返回結(jié)果排序中從from 名開始的數(shù)量為size的結(jié)果集，每一個節(jié)點都會產(chǎn)生一個from+size大小的結(jié)果集，因此優(yōu)先級隊列的大小也就是from+size，分片僅僅是返回一個輕量級的結(jié)果給協(xié)調(diào)節(jié)點，包括結(jié)果級中的每一個文檔的ID和進行排序所需要的信息。
3. 協(xié)調(diào)節(jié)點將會將所有的結(jié)果進行匯總，并進行全局排序，最總得到排序結(jié)果。

• 取值階段

1. 查詢過程得到的排序結(jié)果，標記處哪些文檔是符合要求的，此時仍然需要獲取這些文檔返回給客戶端
2. 協(xié)調(diào)節(jié)點會確定實際需要的返回的文檔，并向含有該文檔的分片發(fā)送get請求，分片獲取的文檔返回給協(xié)調(diào)節(jié)點，協(xié)調(diào)節(jié)點將結(jié)果返回給客戶端。

2、分片設(shè)計與管理

ES 中的文檔存儲在索引中，索引的最小存儲單位是分片，不同的索引存儲在不同的分片中。

當討論分片時，一般是基于某個索引的，不同索引之間的分片互不干擾。

分片分為主分片和副本分片兩種；副本分片是主分片的拷貝，主要用于備份數(shù)據(jù)。

關(guān)于主副分片數(shù)的設(shè)置：

• 主分片數(shù)：主分片數(shù)在索引創(chuàng)建時確定，之后不能修改。
  • 在 ES 7.0 以后，一個索引默認有一個主分片。
  • 一個索引的主分片數(shù)不能超過 1024。
• 副本分片數(shù)：副本分片數(shù)在索引創(chuàng)建之后可以動態(tài)修改。
  • 副本分片數(shù)默認為 1。

關(guān)于每個節(jié)點上的分片數(shù)的設(shè)置，可參考這里。

（1）主分片的設(shè)計

如果某個索引只有一個主分片：

• 優(yōu)點：查詢算分和聚合不精準的問題都可避免。

• 缺點：集群無法實現(xiàn)水平擴展。

  a、因為索引（不管該索引的數(shù)據(jù)量達到了多大）只能存儲在一個主分片上（一個分片不能跨節(jié)點存儲/處理）；

  b、對于單個主分片的索引來說，即使有再多的數(shù)據(jù)節(jié)點，它也無法利用。

如果某個索引有多個主分片：

• 優(yōu)點：集群可以實現(xiàn)水平擴展。

  a、對于擁有多個主分片的索引，該索引的數(shù)據(jù)可以分布在多個主分片上，不同的主分片可以分布在不同的數(shù)據(jù)節(jié)點中；這樣，該索引就可以利用多個節(jié)點的讀寫能力，從而處理更多的數(shù)據(jù)。

  b、如果當前的數(shù)據(jù)節(jié)點數(shù)小于主分片數(shù)，當有新的數(shù)據(jù)節(jié)點加入集群后，這些主分片就會自動被分配到新的數(shù)據(jù)節(jié)點上，從而實現(xiàn)水平擴容。

• 缺點：但是主分片數(shù)也不能過多，因為對于分片的管理也需要額外的資源開銷。主要會帶來以下問題：

  a、每次搜索/聚合數(shù)據(jù)時需要從多個分片上獲取數(shù)據(jù)，并匯總；除了會帶來精準度問題，還會有性能問題。

  b、分片的 Meta 信息由 Master 節(jié)點維護管理，過多的分片，會增加 Master 節(jié)點的負擔。

對于分片的設(shè)計建議：

• 從分片的存儲量考慮：

  a、對于日志類應(yīng)用，單個分片不要大于 50G；

  b、對于搜索類應(yīng)用，單個分片不要大于 20G；

• 從分片數(shù)量考慮：

  a、一個 ES 集群的分片**（包括主分片和副本分片）**總數(shù)不超過 10 W。

（2）副本分片的設(shè)計

副本分片是主分片的備份：

• 優(yōu)點：
  • 可防止數(shù)據(jù)丟失，提高系統(tǒng)的可用性；
  • 可以分擔主分片的查詢壓力，提高系統(tǒng)的查詢性能。
• 缺點：
  • 與主分片一樣，需要占用系統(tǒng)資源，有多少個副本，就會增加多少倍的存儲消耗。
  • 會降低系統(tǒng)的寫入速度。

3、基本架構(gòu)：

• ES是一個具有搜索引擎，NOSQL數(shù)據(jù)庫功能，RESTful風格，基于Java Lucene架構(gòu)構(gòu)建，可用作全文搜索，結(jié)構(gòu)化搜索，近實時分析的開源系統(tǒng);

• ES是面向文檔性的數(shù)據(jù)庫，存儲的是整個文檔或者對象，不但會存儲他們，還會為他們建立索引，提供搜搜功能；

4、怎樣提升檢索效率：

• filesystem cache
  ES的搜索引擎是嚴重的依賴底層的filesystem cache，如果給filesystem cache更多的內(nèi)存，盡量讓內(nèi)存可以容納所有的index segment file 索引數(shù)據(jù)文件

• 數(shù)據(jù)預(yù)熱
  對于那些你覺得比較熱的數(shù)據(jù)，經(jīng)常會有人訪問的數(shù)據(jù)，最好做一個專門的緩存預(yù)熱子系統(tǒng)，就是對熱數(shù)據(jù)，每隔一段時間，你就提前訪問以下，讓數(shù)據(jù)進入filesystem cache里面去，這樣期待下次訪問的時候，性能會更好一些。

• 冷熱分離

5、性能優(yōu)化：

? 關(guān)于ES的性能優(yōu)化，數(shù)據(jù)拆分，將大量的搜索不到的字段，拆分到別的存儲中去，這個類似于MySQL的分庫分表的垂直才分。

• document的模型設(shè)計

? 不要在搜索的時候去執(zhí)行各種復(fù)雜的操作，盡量在document模型設(shè)計的時候，寫入的時候就完成了，另外對于一些復(fù)雜的操作，盡量要避免

• 分頁性能優(yōu)化

? 翻頁的時候，翻得越深，每個shard返回的數(shù)據(jù)越多，而且協(xié)調(diào)節(jié)點處理的時間越長，當然是用scroll，scroll會一次性的生成所有數(shù)據(jù)的一個快照，然后每次翻頁都是通過移動游標完成的。 api 只是在一頁一頁的往后翻

四、競品對比

1、solr簡述：

• Solr是Apache Lucene項目的開源企業(yè)搜索平臺。其主要功能包括全文檢索、命中標示、分面搜索、動態(tài)聚類、數(shù)據(jù)庫集成，以及富文本（如Word、PDF）的處理;
• Solr是高度可擴展的，并提供了分布式搜索和索引復(fù)制。Solr是最流行的企業(yè)級搜索引擎，Solr4 還增加了NoSQL支持;
• Solr是用Java編寫、運行在Servlet容器（如 Apache Tomcat 或Jetty）的一個獨立的全文搜索服務(wù)器。 Solr采用了 Lucene Java 搜索庫為核心的全文索引和搜索，并具有類似REST的HTTP/XML和JSON的API;
• Solr強大的外部配置功能使得無需進行Java編碼，便可對其進行調(diào)整以適應(yīng)多種類型的應(yīng)用程序。Solr有一個插件架構(gòu)，以支持更多的高級定制。

2、Elasticsearch 與 Solr 的比較

五、性能分析

1、對已有數(shù)據(jù)檢索：

單純的對已有的數(shù)據(jù)進行檢索時，solr較好

2、當實時建立索引時：

solr會產(chǎn)生I/O阻塞，查詢效率比較差，ES更具優(yōu)勢

3、大數(shù)據(jù)的條件下檢索：

六、應(yīng)用實踐

項目：ES-jd（仿京東搜索）

地址：

? https://github.com/23-19-zheng/projectDataBase/tree/%E9%A1%B9%E7%9B%AE/es-jd

七、部署運維

1、安裝

? 下載安裝，開箱即用

方法一：

? 下載地址：https://www.elastic.co/cn/downloads/elasticsearch

方法二：使用命令（mac為例）

? 1、安裝：

brew install elasticserach

? 2、產(chǎn)看版本（檢驗安裝是否成功）

elasticsearch --version

3、啟動

? sh ./bin/elasticsearch

其他命令可在bin目錄下面看，見下圖

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-rjuGaVHo-1628491470012)(/Users/zhengchao/Library/Application Support/typora-user-images/image-20210730155101685.png)]

4、檢驗啟動是否成功

? 瀏覽器訪問：http://localhost:9200,出現(xiàn)以下的界面表示成功

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Xv2jd2oe-1628491470013)(/Users/zhengchao/Library/Application Support/typora-user-images/image-20210730155539086.png)]

? 5、關(guān)閉es

方法一：使用插件 elasticsearch——head插件(見擴展)

? 方法二：使用 kill 命令殺死進程

      ###  2、部署運維

• 配置：

  （1）、ES 有以下不同類型的節(jié)點：

  Master

  (eligible)節(jié)點：只有 Master eligible 節(jié)點可以成為 Master 節(jié)點。

  Master 節(jié)點用于維護索引信息和集群狀態(tài)。

  Data 節(jié)點：負責數(shù)據(jù)存儲。

  Ingest 節(jié)點：數(shù)據(jù)預(yù)處理。

  Coordinating 節(jié)點：處理用戶請求。

  ML 節(jié)點：機器學習相關(guān)功能。

  ? 在開發(fā)環(huán)境中，一個節(jié)點可以承擔多種角色。但是在生產(chǎn)環(huán)境，建議一個節(jié)點只負責單一角色，以達到高可用性及高性能。同時根據(jù)業(yè)務(wù)需求和硬件資源來合理分配節(jié)點。

  （2）、節(jié)點配置參數(shù)

  在默認情況下，一個節(jié)點會同時扮演 Master eligible Node，Data Node 和 Ingest Node。

  各類型的節(jié)點配置參數(shù)如下：

  節(jié)點類型	配置參數(shù)	默認值
  Master eligible	node.master	true
  Data Node	node.data	true
  Ingest Node	node.ingest	true
  Coordinating	無	-
  ML	node.ml	true（需要 enable x-pack）

  默認情況下，每個節(jié)點都是一個 Coordinating 節(jié)點，可以將 node.master，node.data 和 node.ingest 同時設(shè)置為 false，讓一個節(jié)點只負責 Coordinating 節(jié)點的角色。

  （3）、配置單一角色

  默認情況下，一個節(jié)點會承擔多個角色，可以通過配置讓一個節(jié)點只負責單一角色。

  單一職責節(jié)點配置：

  • Master節(jié)點：從高可用和避免腦裂的角度考慮，生產(chǎn)環(huán)境可配置 3 個 Master節(jié)點。

    node.master：true

    node.ingest：false

    node.data：false

  • Data 節(jié)點

    node.master：false

    node.ingest：false

    node.data：true

  • Ingest節(jié)點

    node.master：false

    node.ingest：true

    node.data：false

  • Coordinating節(jié)點

    node.master：false

    node.ingest：false

    node.data：false

• 集群架構(gòu)：

  （1）、水平擴展：

  ? a、當需要更多的磁盤容量和讀寫能力的時候，可以增加Date Node的節(jié)點數(shù)量；

  ? b、當系統(tǒng)有大量的復(fù)雜查詢和聚合分析時，可以增加 Coordinating Node 協(xié)調(diào)節(jié)點的數(shù)量；
  

  （2）、讀寫分離：

  ? a、使用Ingest節(jié)點對數(shù)據(jù)預(yù)處理；
  

• 集群的監(jiān)控檢查：

  （1）、集群狀態(tài)為 Green 只能代表分片正常分配，不能代表沒有其它問題。

  ES 提供了很多監(jiān)控相關(guān)的 API：

  • [_cluster/health]：集群健康狀態(tài)。
  • [_cluster/state]：集群狀態(tài)。
  • [_cluster/stats]：集群指標統(tǒng)計。
  • [_cluster/pending_tasks]：集群中正在執(zhí)行的任務(wù)。
  • [_tasks]：集群任務(wù)。
  • [_cluster/allocation/explain]：查看集群分片的分配情況，用于查找原因。
  • [_nodes/stats]：節(jié)點指標統(tǒng)計。
  • [_nodes/info]：節(jié)點信息。
  • [_index/stats]：索引指標統(tǒng)計。
  • 一些 [cat]API。

  （2）Slow log

  ES 的 [Slow log]可以設(shè)置一些閾值，當寫入時間或者查詢時間超過這些閾值后，會將相關(guān)操作記錄日志。

  （3）監(jiān)控工具：

  ? Elasticsearch-support-diagnostics 工具：支持elasticsearch和logstash的診斷實用程序 支持診斷實用程序支持診斷實用程序是一個Java可執(zhí)行文件，它將查詢運行在主機上的node，以獲取正在運行的群集的數(shù)據(jù)和統(tǒng)計信息文章來源地址http://www.zghlxwxcb.cn/news/detail-409385.html

到了這里，關(guān)于詳解最熱門搜索引擎——ES的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！