本文章會整理關于ES的最新面試熱門問題，并免費持續(xù)更新。。。

1. ES中索引優(yōu)化思路？

   ES索引優(yōu)化主要從兩個方面解決問題：

   一、索引數(shù)據(jù)過程 大家可能會遇到索引數(shù)據(jù)比較慢的過程。其實明白索引的原理就可以有針對性的進行優(yōu)化。ES索引的過程到相對Lucene的索引過程多了分布式數(shù)據(jù)的擴展，而這ES主要是用tranlog進行各節(jié)點之間的數(shù)據(jù)平衡。所以從上我可以通過索引的settings進行第一優(yōu)化：

   這兩個參數(shù)第一是到tranlog數(shù)據(jù)達到多少條進行平衡，默認為5000，而這個過程相對而言是比較浪費時間和資源的。所以我們可以將這個值調(diào)大一些還是設為-1關閉，進而手動進行tranlog平衡。

   第二參數(shù)是刷新頻率，默認為120s是指索引在生命周期內(nèi)定時刷新，一但有數(shù)據(jù)進來能refresh像lucene里面commit,我們知道當數(shù)據(jù)addDoucment后，還不能檢索到要commit之后才能行數(shù)據(jù)的檢索，所以可以將其關閉，在最初索引完后手動refresh一之，然后將索引setting里面的index.refresh_interval參數(shù)按需求進行修改，從而可以提高索引過程效率。

   另外的知道ES索引過程中如果有副本存在，數(shù)據(jù)也會馬上同步到副本中去。我個人建議在索引過程中將副本數(shù)設為0，待索引完成后將副本數(shù)按需量改回來，這樣也可以提高索引效率。 "number_of_replicas": 0;

   再有一些優(yōu)化 查看外鏈：

   ES索引優(yōu)化方案_es索引數(shù)據(jù)太多如何調(diào)優(yōu)_大齡打工的博客-CSDN博客
   ?

? ? ? ??

? ? ?3.es 為什么搜索快？? ? ? ? ??

• 磁盤東西盡量搬內(nèi)存
• 各種奇技淫巧算法
• 苛刻態(tài)度使用內(nèi)存

? ? 4. es 深翻頁問題

先查后取的過程支持用?from?和?size?參數(shù)分頁，但是這是?有限制的?。 要記住需要傳遞信息給協(xié)調(diào)節(jié)點的每個分片必須先創(chuàng)建一個?from + size?長度的隊列，協(xié)調(diào)節(jié)點需要根據(jù)?number_of_shards * (from + size)?排序文檔，來找到被包含在?size?里的文檔。

取決于你的文檔的大小，分片的數(shù)量和你使用的硬件，給 10,000 到 50,000 的結(jié)果文檔深分頁（ 1,000 到 5,000 頁）是完全可行的。但是使用足夠大的?from?值，排序過程可能會變得非常沉重，使用大量的CPU、內(nèi)存和帶寬。因為這個原因，我們強烈建議你不要使用深分頁。

實際上， “深分頁” 很少符合人的行為。當2到3頁過去以后，人會停止翻頁，并且改變搜索標準。會不知疲倦地一頁一頁的獲取網(wǎng)頁直到你的服務崩潰的罪魁禍首一般是機器人或者web spider。

再有，使用scroll?查詢 可以用來對 Elasticsearch 有效地執(zhí)行大批量的文檔查詢，而又不用付出深度分頁那種代價。

游標查詢允許我們 先做查詢初始化，然后再批量地拉取結(jié)果。 這有點兒像傳統(tǒng)數(shù)據(jù)庫中的?cursor?。

游標查詢會取某個時間點的快照數(shù)據(jù)。 查詢初始化之后索引上的任何變化會被它忽略。 它通過保存舊的數(shù)據(jù)文件來實現(xiàn)這個特性，結(jié)果就像保留初始化時的索引?視圖?一樣。

深度分頁的代價根源是結(jié)果集全局排序，如果去掉全局排序的特性的話查詢結(jié)果的成本就會很低。 游標查詢用字段?_doc?來排序。 這個指令讓 Elasticsearch 僅僅從還有結(jié)果的分片返回下一批結(jié)果。

啟用游標查詢可以通過在查詢的時候設置參數(shù)?scroll?的值為我們期望的游標查詢的過期時間。 游標查詢的過期時間會在每次做查詢的時候刷新，所以這個時間只需要足夠處理當前批的結(jié)果就可以了，而不是處理查詢結(jié)果的所有文檔的所需時間。 這個過期時間的參數(shù)很重要，因為保持這個游標查詢窗口需要消耗資源，所以我們期望如果不再需要維護這種資源就該早點兒釋放掉。 設置這個超時能夠讓 Elasticsearch 在稍后空閑的時候自動釋放這部分資源。

5.為什么說 ES 搜索是近實時的？

因為文檔索引在從內(nèi)存緩存被寫入到文件緩存系統(tǒng)時，雖然還沒有進行提交未被 flush 到磁盤，但是緩沖區(qū)的內(nèi)容已經(jīng)被寫入一個段（segment6）中且新段可被搜索。這就是為什么我們說 Elasticsearch 是近實時搜索: 文檔的變化并不是立即對搜索可見，但會在一秒之內(nèi)變?yōu)榭梢姟?/p>

6.Elasticsearch 是怎樣保證更新被持久化在斷電時也不丟失數(shù)據(jù)?

新索引文檔被寫入到內(nèi)存緩存時，同時會記錄一份到事務日志（translog）中，translog 提供所有還沒有被刷到磁盤的操作的一個持久化紀錄。當 Elasticsearch 啟動的時候， 它會從磁盤中使用最后一個提交點去恢復已知的段，并且會重放 translog 中所有在最后一次提交后發(fā)生的變更操作。

translog 也被用來提供實時 CRUD 。當你試著通過ID查詢、更新、刪除一個文檔，它會在嘗試從相應的段中檢索之前， 首先檢查 translog 任何最近的變更。這意味著它總是能夠?qū)崟r地獲取到文檔的最新版本。文章來源地址http://www.zghlxwxcb.cn/news/detail-496591.html

到了這里，關于【Elasticsearch】面試題匯總（2023.6）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！