溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“2021有哪些最新版的Elasticsearch面試題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“2021有哪些最新版的Elasticsearch面試題”吧！
面試官：想了解應聘者之前公司接觸的 ES 使用場景、規模，有沒有做過比較大規模的索引設計、規劃、調優。
解答：如實結合自己的實踐場景回答即可。
比如：ES 集群架構 13 個節點，索引根據通道不同共 20+索引，根據日期，每日遞增 20+，索引：10分片，每日遞增 1 億+數據，每個通道每天索引大小控制：150GB 之內。
僅索引層面調優手段：
（1）根據業務增量需求，采取基于日期模板創建索引，通過 roll over API 滾動索引；
（2）使用別名進行索引管理；
（3）每天凌晨定時對索引做 force_merge 操作，以釋放空間；
（4）采取冷熱分離機制，熱數據存儲到 SSD，提高檢索效率；冷數據定期進行 shrink操作，以縮減存儲；
（5）采取 curator 進行索引的生命周期管理；
（6）僅針對需要分詞的字段，合理的設置分詞器；
（7）Mapping 階段充分結合各個字段的屬性，是否需要檢索、是否需要存儲等。
（1）寫入前副本數設置為 0；
（2）寫入前關閉 refresh_interval 設置為-1，禁用刷新機制；
（3）寫入過程中：采取 bulk 批量寫入；
（4）寫入后恢復副本數和刷新間隔；
（5）盡量使用自動生成的 id。
（1）禁用 wildcard；
（2）禁用批量 terms（成百上千的場景）；
（3）充分利用倒排索引機制，能 keyword 類型盡量 keyword；
（4）數據量大時候，可以先基于時間敲定索引再檢索；
（5）設置合理的路由機制。
部署調優，業務調優等。
上面的提及一部分，面試者就基本對你之前的實踐或者運維經驗有所評估了。
lucene 從 4+版本后開始大量使用的數據結構是 FST。FST 有兩個優點：
（1）空間占用小。通過對詞典中單詞前綴和后綴的重復利用，壓縮了存儲空間；
（2）查詢速度快。O(len(str))的查詢時間復雜度。
面試官：想了解大數據量的運維能力。
解答：索引數據的規劃，應在前期做好規劃，正所謂“設計先行，編碼在后”，這樣才能有效的避免突如其來的數據激增導致集群處理能力不足引發的線上客戶檢索或者其他業務受到影響。
如何調優，正如問題 1 所說，這里細化一下：
基于模板+時間+rollover api 滾動創建索引，舉例：設計階段定義：blog 索引的模板格式為： blog_index_時間戳的形式，每天遞增數據。這樣做的好處：不至于數據量激增導致單個索引數據量非 常大，接近于上線 2 的32 次冪-1，索引存儲達到了 TB+甚至更大。
一旦單個索引很大，存儲等各種風險也隨之而來，所以要提前考慮+及早避免。
冷熱數據分離存儲，熱數據（比如最近 3 天或者一周的數據），其余為冷數據。
對于冷數據不會再寫入新數據，可以考慮定期 force_merge 加 shrink 壓縮操作，節省存儲空間和檢索效率。
一旦之前沒有規劃，這里就屬于應急策略。
結合 ES 自身的支持動態擴展的特點，動態新增機器的方式可以緩解集群壓力，注意：如果之前主節點等規劃合理，不需要重啟集群也能完成動態新增的。
1GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name 2ip port heapPercent heapMax id name復制代碼
面試官：想了解 ES 搜索的底層原理，不再只關注業務層面了。
解答：
搜索拆解為“query then fetch” 兩個階段。
query 階段的目的：定位到位置，但不取。
步驟拆解如下：
（1）假設一個索引數據有 5 主+1 副本 共 10 分片，一次請求會命中（主或者副本分片中）的一個。
（2）每個分片在本地進行查詢，結果返回到本地有序的優先隊列中。
（3）第 2）步驟的結果發送到協調節點，協調節點產生一個全局的排序列表。
fetch 階段的目的：取數據。
路由節點獲取所有文檔，返回給客戶端。
面試官：想了解對 ES 集群的運維能力。
解答：
（1）關閉緩存 swap;
（2）堆內存設置為：Min（節點內存/2, 32GB）;
（3）設置最大文件句柄數；
（4）線程池+隊列大小根據業務需要做調整；
（5）磁盤存儲 raid 方式——存儲有條件使用 RAID10，增加單節點性能以及避免單節點存儲故障。
面試官：想了解你的知識面的廣度和深度。
解答：
Lucene 是有索引和搜索的兩個過程，包含索引創建，索引，搜索三個要點。可以基于這個脈絡展開一些。
（1）Elasticsearch 的選主是 ZenDiscovery 模塊負責的，主要包含 Ping（節點之間通過這個 RPC 來發 現彼此）和 Unicast（單播模塊包含一個主機列表以控制哪些節點需要 ping 通）這兩部分；
（2）對所有可以成為 master 的節點（node.master: true）根據 nodeId 字典排序，每次選舉每個節 點都把自己所知道節點排一次序，然后選出第一個（第 0 位）節點，暫且認為它是 master 節點。
（3）如果對某個節點的投票數達到一定的值（可以成為 master 節點數 n/2+1）并且該節點自己也選 舉自己，那這個節點就是 master。否則重新選舉一直到滿足上述條件。
（4）補充：master 節點的職責主要包括集群、節點和索引的管理，不負責文檔級別的管理；data 節點可以關閉 http 功能*。
選了一個 master，另外 10 個選了另一個 master，怎么辦？
（1）當集群 master 候選數量不小于 3 個時，可以通過設置最少投票通過數量（discovery.zen.minimum_master_nodes）超過所有候選節點一半以上來解決腦裂問題；
（3）當候選數量為兩個時，只能修改為唯一的一個 master 候選，其他作為 data節點，避免腦裂問題。
TransportClient 利用 transport 模塊遠程連接一個 elasticsearch 集群。它并不加入到集群中，只是簡單的獲得一個或者多個初始化的 transport 地址，并以 輪詢 的方式與這些地址進行通信。
協調節點默認使用文檔 ID 參與計算（也支持通過 routing），以便為路由提供合適的分片
shard = hash(document_id) % (num_of_primary_shards)復制代碼
（1）當分片所在的節點接收到來自協調節點的請求后，會將請求寫入到 MemoryBuffffer，然后定時（默認是每隔 1 秒）寫入到 Filesystem Cache，這個從 MomeryBuffffer 到 Filesystem Cache 的過程就叫做 refresh；
（2）當然在某些情況下，存在 Momery Buffffer 和 Filesystem Cache 的數據可能會丟失，ES 是通過translog 的機制來保證數據的可靠性的。其實現機制是接收到請求后，同時也會寫入到 translog 中 ， 當 Filesystem cache 中的數據寫入到磁盤中時，才會清除掉，這個過程叫做 flflush；
（3）在 flflush 過程中，內存中的緩沖將被清除，內容被寫入一個新段，段的 fsync將創建一個新的提交點，并將內容刷新到磁盤，舊的 translog 將被刪除并開始一個新的 translog。
（4）flflush 觸發的時機是定時觸發（默認 30 分鐘）或者 translog 變得太大（默認為 512M）時；補充：關于 Lucene 的 Segement：
（1）Lucene 索引是由多個段組成，段本身是一個功能齊全的倒排索引。
（2）段是不可變的，允許 Lucene 將新的文檔增量地添加到索引中，而不用從頭重建索引。
（3）對于每一個搜索請求而言，索引中的所有段都會被搜索，并且每個段會消耗CPU 的時鐘周、文件句柄和內存。這意味著段的數量越多，搜索性能會越低。
（4）為了解決這個問題，Elasticsearch 會合并小段到一個較大的段，提交新的合并段到磁盤，并刪除那些舊的小段。
（1）查詢 ： Elasticsearch 允許執行和合并多種類型的搜索 — 結構化、非結構化、地理位置、度量指標 — 搜索方式隨心而變。
（2）分析 ： 找到與查詢最匹配的十個文檔是一回事。但是如果面對的是十億行日志，又該如何解讀呢？Elasticsearch 聚合讓您能夠從大處著眼，探索數據的趨勢和模式。
（3）速度 ： Elasticsearch 很快。真的，真的很快。
（4）可擴展性 ： 可以在筆記本電腦上運行。 也可以在承載了 PB 級數據的成百上千臺服務器上運行。
（5）彈性 ： Elasticsearch 運行在一個分布式的環境中，從設計之初就考慮到了這一點。
（6）靈活性 ： 具備多個案例場景。數字、文本、地理位置、結構化、非結構化。所有的數據類型都歡迎。
（7）HADOOP & SPARK ： Elasticsearch + Hadoop
這里有一些使用Elasticsearch的用例：
（1）你經營一個網上商店，你允許你的顧客搜索你賣的產品。在這種情況下，您可以使用Elasticsearch來存儲整個產品目錄和庫存，并為它們提供搜索和自動完成建議。
（2）你希望收集日志或事務數據，并希望分析和挖掘這些數據，以查找趨勢、統計、匯總或異常。在這種情況下，你可以使用loghide (Elasticsearch/ loghide /Kibana堆棧的一部分)來收集、聚合和解析數據，然后讓loghide將這些數據輸入到Elasticsearch中。一旦數據在Elasticsearch中，你就可以運行搜索和聚合來挖掘你感興趣的任何信息。
（3）你運行一個價格警報平臺，允許精通價格的客戶指定如下規則:“我有興趣購買特定的電子設備，如果下個月任何供應商的產品價格低于X美元，我希望得到通知”。在這種情況下，你可以抓取供應商的價格，將它們推入到Elasticsearch中，并使用其反向搜索(Percolator)功能來匹配價格走勢與客戶查詢，并最終在找到匹配后將警報推送給客戶。
（4）你有分析/業務智能需求，并希望快速調查、分析、可視化，并對大量數據提出特別問題(想想數百萬或數十億的記錄)。在這種情況下，你可以使用Elasticsearch來存儲數據，然后使用Kibana (Elasticsearch/ loghide /Kibana堆棧的一部分)來構建自定義儀表板，以可視化對您來說很重要的數據的各個方面。此外，還可以使用Elasticsearch聚合功能對數據執行復雜的業務智能查詢。
（1）刪除和更新也都是寫操作，但是 Elasticsearch 中的文檔是不可變的，因此不能被刪除或者改動以展示其變更；
（2）磁盤上的每個段都有一個相應的.del 文件。當刪除請求發送后，文檔并沒有真的被刪除，而是在.del 文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結果中被過濾掉。當段合并時，在.del 文件中被標記為刪除的文檔將不會被寫入新段。
（3）在新的文檔被創建時，Elasticsearch 會為該文檔指定一個版本號，當執行更新時，舊版本的文檔在.del 文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結果中被過濾掉
（1）Lucene的索引過程，就是按照全文檢索的基本過程，將倒排表寫成此文件格式的過程。
（2）Lucene的搜索過程，就是按照此文件格式將索引進去的信息讀出來，然后計算每篇文檔打分(score)的過程。
（1）64 GB 內存的機器是非常理想的， 但是 32 GB 和 16 GB 機器也是很常見的。少于 8 GB 會適得其反。
（2）如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內核提供的額外并發遠勝過稍微快一點點的時鐘頻率。
（3）如果你負擔得起 SSD，它將遠遠超出任何旋轉介質。 基于 SSD 的節點，查詢和索引性能都有提升。如果你負擔得起，SSD 是一個好的選擇。
（4）即使數據中心們近在咫尺，也要避免集群跨越多個數據中心。絕對要避免集群跨越大的地理距離。
（5）請確保運行你應用程序的 JVM 和服務器的 JVM 是完全一樣的。 在Elasticsearch 的幾個地方，使用 Java 的本地序列化。
（6）通過設置 gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time 可以在集群重啟的時候避免過多的分片交換，這可能會讓數據恢復從數個
小時縮短為幾秒鐘。
（7）Elasticsearch 默認被配置為使用單播發現，以防止節點無意中加入集群。只有在同一臺機器上運行的節點才會自動組成集群。最好使用單播代替組播。
（8）不要隨意修改垃圾回收器（CMS）和各個線程池的大小。
（9）把你的內存的（少于）一半給 Lucene（但不要超過 32 GB！），通過ES_HEAP_SIZE 環境變量設置。
（10）內存交換到磁盤對服務器性能來說是致命的。如果內存交換到磁盤上，一個100 微秒的操作可能變成 10 毫秒。 再想想那么多 10 微秒的操作時延累加起來。 不難看出 swapping 對于性能是多么可怕。
（11）Lucene 使用了大 量 的文件。同時，Elasticsearch 在節點和 HTTP 客戶端之間進行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應該增加你的文件描述符，設置一個很大的值，如 64,000。
（1）倒排詞典的索引需要常駐內存，無法 GC，需要監控 data node 上 segmentmemory 增長趨勢。
（2）各類緩存，fifield cache, fifilter cache, indexing cache, bulk queue 等等，要設置合理的大小，并且要應該根據最壞的情況來看 heap 是否夠用，也就是各類緩存全部占滿的時候，還有 heap 空間可以分配給其他任務嗎？避免采用 clear cache等“自欺欺人”的方式來釋放內存。
（3）避免返回大量結果集的搜索與聚合。確實需要大量拉取數據的場景，可以采用scan & scroll api來實現。
（4）cluster stats 駐留內存并無法水平擴展，超大規模集群可以考慮分拆成多個集群通過 tribe node連接。
（5）想知道 heap 夠不夠，必須結合實際應用場景，并對集群的 heap 使用情況做持續的監控。
（6）根據監控數據理解內存需求，合理配置各類circuit breaker，將內存溢出風險降低到最低
Elasticsearch 提供的首個近似聚合是 cardinality 度量。它提供一個字段的基數，即該字段的 distinct或者 unique 值的數目。它是基于 HLL 算法的。HLL 會先對我們的輸入作哈希運算，然后根據哈希運算 的結果中的 bits 做概率估算從而得到基數。其特點是：可配置的精度，用來控制內存的使用（更精確 ＝ 更多內存）；小的數據集精度是非常高的；我們可以通過配置參數，來設置去重需要的固定內存使用量。無論數千還是數十億的唯一值，內存使用量只與你配置的精確度相關。
（1）可以通過版本號使用樂觀并發控制，以確保新版本不會被舊版本覆蓋，由應用層來處理具體的沖突；
（2）另外對于寫操作，一致性級別支持 quorum/one/all，默認為 quorum，即只有當大多數分片可用時才允許寫操作。但即使大多數可用，也可能存在因為網絡等原因導致寫入副本失敗，這樣該副本被認為故障，分片將會在一個不同的節點上重建。
（3）對于讀操作，可以設置 replication 為 sync(默認)，這使得操作在主分片和副本分片都完成后才會返回；如果設置 replication 為 async 時，也可以通過設置搜索請求參數_preference 為 primary 來查
詢主分片，確保文檔是最新版本。
Marvel 讓你可以很簡單的通過 Kibana 監控 Elasticsearch。你可以實時查看你的集群健康狀態和性 能，也可以分析過去的集群、索引和節點指標。
23、介紹下你們電商搜索的整體技術架構。
基于word2vec和Elasticsearch實現個性化搜索
（1）基于word2vec、Elasticsearch和自定義的腳本插件，我們就實現了一個個性化的搜索服務，相對于原有的實現，新版的點擊率和轉化率都有大幅的提升；
（2）基于word2vec的商品向量還有一個可用之處，就是可以用來實現相似商品的推薦；
（3）使用word2vec來實現個性化搜索或個性化推薦是有一定局限性的，因為它只能處理用戶點擊歷史這樣的時序數據，而無法全面的去考慮用戶偏好，這個還是有很大的改進和提升的空間；
常用字典數據結構如下所示：
Trie 的核心思想是空間換時間，利用字符串的公共前綴來降低查詢時間的開銷以達到提高效率的目的。
它有 3 個基本性質：
1）根節點不包含字符，除根節點外每一個節點都只包含一個字符。
2）從根節點到某一節點，路徑上經過的字符連接起來，為該節點對應的字符串。
3）每個節點的所有子節點包含的字符都不相同。
或者用數組來模擬動態。而空間的花費，不會超過單詞數×單詞長度。
（2）實現：對每個結點開一個字母集大小的數組，每個結點掛一個鏈表，使用左兒子右兄弟表示法記
錄這棵樹；
（3）對于中文的字典樹，每個節點的子節點用一個哈希表存儲，這樣就不用浪費太大的空間，而且查
詢速度上可以保留哈希的復雜度 O(1)
（1）拼寫糾錯是基于編輯距離來實現；編輯距離是一種標準的方法，它用來表示經過插入、刪除和替換操作從一個字符串轉換到另外一個字符串的最小操作步數；
（2）編輯距離的計算過程：比如要計算 batyu 和 beauty 的編輯距離，先創建一個7×8 的表（batyu長度為 5，coffffee 長度為 6，各加 2），接著，在如下位置填入黑色數字。其他格的計算過程是取以下
三個值的最小值：
如果最上方的字符等于最左方的字符，則為左上方的數字。否則為左上方的數字+1。（對于 3,3 來說為0）
左方數字+1（對于 3,3 格來說為 2）
上方數字+1（對于 3,3 格來說為 2）
最終取右下角的值即為編輯距離的值 3。
感謝各位的閱讀，以上就是“2021有哪些最新版的Elasticsearch面試題”的內容了，經過本文的學習后，相信大家對2021有哪些最新版的Elasticsearch面試題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
