ElasticSearch常見經典面試題

1.為什么要使用Elasticsearch?

​ 　　因為在我們商城中的數據，將來會非常多，所以采用以往的模糊查詢，模糊查詢前置配置，會放棄索引，導致商品查詢是全表掃面，在百萬級別的數據庫中，效率非常低下，而我們使用ES做一個全文索引，我們將經常查詢的商品的某些字段，比如說商品名，描述、價格還有id這些字段我們放入我們索引庫里，可以提高查詢速度。

2.Elasticsearch是如何實現Master選舉的？

　　Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分；
　　對所有可以成為master的節點（node.master: true）根據nodeId字典排序，每次選舉每個節點都把自己所知道節點排一次序，然后選出第一個（第0位）節點，暫且認為它是master節點。
　　如果對某個節點的投票數達到一定的值（可以成為master節點數n/2+1）並且該節點自己也選舉自己，那這個節點就是master。否則重新選舉一直到滿足上述條件。
補充：master節點的職責主要包括集群、節點和索引的管理，不負責文檔級別的管理；data節點可以關閉http功能。

3.Elasticsearch中的節點（比如共20個），其中的10個選了一個master，另外10個選了另一個master，怎么辦？

　　當集群master候選數量不小於3個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；
當候選數量為兩個時，只能修改為唯一的一個master候選，其他作為data節點，避免腦裂問題。

4.詳細描述一下Elasticsearch索引文檔的過程。

　　協調節點默認使用文檔ID參與計算（也支持通過routing），以便為路由提供合適的分片。
　　shard = hash(document_id) % (num_of_primary_shards)
　　當分片所在的節點接收到來自協調節點的請求后，會將請求寫入到Memory Buffer，然后定時（默認是每隔1秒）寫入到Filesystem Cache，這個從Momery Buffer到Filesystem 　　Cache的過程就叫做refresh；
　　當然在某些情況下，存在Momery Buffer和Filesystem Cache的數據可能會丟失，ES是通過translog的機制來保證數據的可靠性的。其實現機制是接收到請求后，同時也會寫入到translog中，當Filesystem cache中的數據寫入到磁盤中時，才會清除掉，這個過程叫做flush；
　　在flush過程中，內存中的緩沖將被清除，內容被寫入一個新段，段的fsync將創建一個新的提交點，並將內容刷新到磁盤，舊的translog將被刪除並開始一個新的translog。
　　flush觸發的時機是定時觸發（默認30分鍾）或者translog變得太大（默認為512M）時；

5.詳細描述一下Elasticsearch更新和刪除文檔的過程

　　刪除和更新也都是寫操作，但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
　　磁盤上的每個段都有一個相應的.del文件。當刪除請求發送后，文檔並沒有真的被刪除，而是在.del文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合並時，在.del文件中被標記為刪除的文檔將不會被寫入新段。
　　在新的文檔被創建時，Elasticsearch會為該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉。

6.詳細描述一下Elasticsearch搜索的過程

　　搜索被執行成一個兩階段過程，我們稱之為 Query Then Fetch；
　　在初始查詢階段時，查詢會廣播到索引中每一個分片拷貝（主分片或者副本分片）。 每個分片在本地執行搜索並構建一個匹配文檔的大小為 from + size 的優先隊列。PS：在搜索的時候是會查詢Filesystem Cache的，但是有部分數據還在Memory Buffer，所以搜索是近實時的。
　　每個分片返回各自優先隊列中 所有文檔的 ID 和排序值 給協調節點，它合並這些值到自己的優先隊列中來產生一個全局排序后的結果列表。
　　接下來就是 取回階段，協調節點辨別出哪些文檔需要被取回並向相關的分片提交多個 GET 請求。每個分片加載並 豐富 文檔，如果有需要的話，接着返回文檔給協調節點。一旦所有的文檔都被取回了，協調節點返回結果給客戶端。
　　補充：Query Then Fetch的搜索類型在文檔相關性打分的時候參考的是本分片的數據，這樣在文檔數量較少的時候可能不夠准確，DFS Query Then Fetch增加了一個預查詢的處理，詢問Term和Document frequency，這個評分更准確，但是性能會變差。

9.Elasticsearch對於大數據量（上億量級）的聚合如何實現？

​ 　　Elasticsearch 提供的首個近似聚合是cardinality 度量。它提供一個字段的基數，即該字段的distinct或者unique值的數目。它是基於HLL算法的。HLL 會先對我們的輸入作哈希運算，然后根據哈希運算的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制內存的使用（更精確 ＝ 更多內存）；小的數據集精度是非常高的；我們可以通過配置參數，來設置去重需要的固定內存使用量。無論數千還是數十億的唯一值，內存使用量只與你配置的精確度相關 .

10.在並發情況下，Elasticsearch如果保證讀寫一致？

　　可以通過版本號使用樂觀並發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的沖突；
　　另外對於寫操作，一致性級別支持quorum/one/all，默認為quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因為網絡等原因導致寫入副本失敗，這樣該副本被認為故障，分片將會在一個不同的節點上重建。
　　對於讀操作，可以設置replication為sync(默認)，這使得操作在主分片和副本分片都完成后才會返回；如果設置replication為async時，也可以通過設置搜索請求參數_preference為primary來查詢主分片，確保文檔是最新版本。

14.ElasticSearch中的集群、節點、索引、文檔、類型是什么？

　　群集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，並提供跨所有節點的聯合索引和搜索功能。群集由唯一名稱標識，默認情況下為“elasticsearch”。此名稱很重要，因為如果節點設置為按名稱加入群集，則該節點只能是群集的一部分。
　　節點是屬於集群一部分的單個服務器。它存儲數據並參與群集索引和搜索功能。
　　索引就像關系數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，並且可以有零個或多個副本分片。 MySQL =>數據庫 　　         ElasticSearch =>索引
　　文檔類似於關系數據庫中的一行。不同之處在於索引中的每個文檔可以具有不同的結構（字段），但是對於通用字段應該具有相同的數據類型。 MySQL => Databases => 　             Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔
　　類型是索引的邏輯類別/分區，其語義完全取決於用戶。

15.ElasticSearch中的分片是什么?

　　在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。

　　索引 - 在Elasticsearch中，索引是文檔的集合。
　　分片 -因為Elasticsearch是一個分布式搜索引擎，所以索引通常被分割成分布在多個節點上的被稱為分片的元素。

 

 

問題一：

什么是ElasticSearch？ 

Elasticsearch是一個基於Lucene的搜索引擎。它提供了具有HTTP Web界面和無架構JSON文檔的分布式，多租戶能力的全文搜索引擎。Elasticsearch是用Java開發的，根據Apache許可條款作為開源發布。

 

問題三：

Elasticsearch中的倒排索引是什么？ 

倒排索引是搜索引擎的核心。搜索引擎的主要目標是在查找發生搜索條件的文檔時提供快速搜索。倒排索引是一種像數據結構一樣的散列圖，可將用戶從單詞導向文檔或網頁。它是搜索引擎的核心。其主要目標是快速搜索從數百萬文件中查找數據。 

 

問題四：

ElasticSearch中的集群、節點、索引、文檔、類型是什么？

• 群集是一個或多個節點（服務器）的集合，它們共同保存您的整個數據，並提供跨所有節點的聯合索引和搜索功能。群集由唯一名稱標識，默認情況下為“elasticsearch”。此名稱很重要，因為如果節點設置為按名稱加入群集，則該節點只能是群集的一部分。

• 節點是屬於集群一部分的單個服務器。它存儲數據並參與群集索引和搜索功能。

• 索引就像關系數據庫中的“數據庫”。它有一個定義多種類型的映射。索引是邏輯名稱空間，映射到一個或多個主分片，並且可以有零個或多個副本分片。 MySQL =>數據庫 ElasticSearch =>索引

• 文檔類似於關系數據庫中的一行。不同之處在於索引中的每個文檔可以具有不同的結構（字段），但是對於通用字段應該具有相同的數據類型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有屬性的文檔

• 類型是索引的邏輯類別/分區，其語義完全取決於用戶。

 

問題五：

ElasticSearch是否有架構？

ElasticSearch可以有一個架構。架構是描述文檔類型以及如何處理文檔的不同字段的一個或多個字段的描述。Elasticsearch中的架構是一種映射，它描述了JSON文檔中的字段及其數據類型，以及它們應該如何在Lucene索引中進行索引。因此，在Elasticsearch術語中，我們通常將此模式稱為“映射”。 

Elasticsearch具有架構靈活的能力，這意味着可以在不明確提供架構的情況下索引文檔。如果未指定映射，則默認情況下，Elasticsearch會在索引期間檢測文檔中的新字段時動態生成一個映射。

 

問題六：

ElasticSearch中的分片是什么？ 

在大多數環境中，每個節點都在單獨的盒子或虛擬機上運行。 

• 索引 - 在Elasticsearch中，索引是文檔的集合。 

• 分片 -因為Elasticsearch是一個分布式搜索引擎，所以索引通常被分割成分布在多個節點上的被稱為分片的元素。

 

問題七：

ElasticSearch中的副本是什么？

一個索引被分解成碎片以便於分發和擴展。副本是分片的副本。一個節點是一個屬於一個集群的ElasticSearch的運行實例。一個集群由一個或多個共享相同集群名稱的節點組成。

 

問題八：

ElasticSearch中的分析器是什么？

在ElasticSearch中索引數據時，數據由為索引定義的Analyzer在內部進行轉換。 分析器由一個Tokenizer和零個或多個TokenFilter組成。編譯器可以在一個或多個CharFilter之前。分析模塊允許您在邏輯名稱下注冊分析器，然后可以在映射定義或某些API中引用它們。

Elasticsearch附帶了許多可以隨時使用的預建分析器。或者，您可以組合內置的字符過濾器，編譯器和過濾器器來創建自定義分析器。

 

問題九：

什么是ElasticSearch中的編譯器？

編譯器用於將字符串分解為術語或標記流。一個簡單的編譯器可能會將字符串拆分為任何遇到空格或標點的地方。Elasticsearch有許多內置標記器，可用於構建自定義分析器。

 

問題十一：

啟用屬性，索引和存儲的用途是什么？

enabled屬性適用於各類ElasticSearch特定/創建領域，如index和size。用戶提供的字段沒有“已啟用”屬性。 存儲意味着數據由Lucene存儲，如果詢問，將返回這些數據。

存儲字段不一定是可搜索的。默認情況下，字段不存儲，但源文件是完整的。因為您希望使用默認值(這是有意義的)，所以不要設置store屬性 該指數屬性用於搜索。

索引屬性只能用於搜索。只有索引域可以進行搜索。差異的原因是在分析期間對索引字段進行了轉換，因此如果需要的話，您不能檢索原始數據。