1、為什么要使用 Elasticsearch?

系統(tǒng)中的數(shù)據(jù)， 隨著業(yè)務(wù)的發(fā)展， 時(shí)間的推移， 將會(huì)非常多，而業(yè)務(wù)中往往采用模糊查詢(xún)進(jìn)行數(shù)據(jù)的 搜索，而模糊查詢(xún)會(huì)導(dǎo)致查詢(xún)引擎放棄索引， 導(dǎo)致系統(tǒng)查詢(xún)數(shù)據(jù)時(shí)都是全表掃描，在百萬(wàn)級(jí)別的數(shù)據(jù)庫(kù)中， 查詢(xún)效率是非常低下的，而我們使用 ES 做一個(gè)全文索引， 將經(jīng)常查詢(xún)的系統(tǒng)功能的某些字段，比如說(shuō)電 商系統(tǒng)的商品表中商品名，描述、價(jià)格還有 id 這些字段我們放入 ES 索引庫(kù)里，可以提高查詢(xún)速度。

2、Elasticsearch 的 master 選舉流程？

• Elasticsearch 的選主是 ZenDiscovery 模塊負(fù)責(zé)的， 主要包含 Ping(節(jié)點(diǎn)之間通過(guò)這個(gè) RPC 來(lái)發(fā)現(xiàn)彼此)和 Unicast (單播模塊包含一個(gè)主機(jī)列表以控制哪些節(jié)點(diǎn)需要 ping 通)這兩部分
• 對(duì)所有可以成為 master 的節(jié)點(diǎn)(node.master: true)根據(jù) nodeId 字典排序，每次選舉每個(gè)節(jié)點(diǎn)都把自己所知道節(jié)點(diǎn)排一次序，然后選出第一個(gè)(第 0 位)節(jié)點(diǎn)， 暫且認(rèn)為它是 master 節(jié)點(diǎn)
• 如果對(duì)某個(gè)節(jié)點(diǎn)的投票數(shù)達(dá)到一定的值(可以成為 master 節(jié)點(diǎn)數(shù) n/2+1) 并且該節(jié)點(diǎn)自己也選舉自己，那這個(gè)節(jié)點(diǎn)就是 master 。否則重新選舉一直到滿(mǎn)足上述條件
• master 節(jié)點(diǎn)的職責(zé)主要包括集群、節(jié)點(diǎn)和索引的管理， 不負(fù)責(zé)文檔級(jí)別的管理； data 節(jié)點(diǎn)可以關(guān)閉 http功能

3、Elasticsearch 集群腦裂問(wèn)題？

所謂腦裂問(wèn)題（類(lèi)似于精神分裂），就是同一個(gè)集群中的不同節(jié)點(diǎn)，對(duì)于集群的狀態(tài)有了不一樣的理解。

由于某些節(jié)點(diǎn)的失效，部分節(jié)點(diǎn)的網(wǎng)絡(luò)連接會(huì)斷開(kāi)，并形成一個(gè)與原集群一樣名字的集群，這種情況成為集群腦裂（split-brain）現(xiàn)象。這個(gè)問(wèn)題非常危險(xiǎn)，因?yàn)閮蓚€(gè)新形成的集群會(huì)同時(shí)索引和修改集群的數(shù)據(jù)。

“腦裂”問(wèn)題可能的成因：

• 網(wǎng)絡(luò)問(wèn)題：集群間的網(wǎng)絡(luò)延遲導(dǎo)致一些節(jié)點(diǎn)訪問(wèn)不到 master，認(rèn)為 master 掛掉了從而選舉出新的master，并對(duì) master 上的分片和副本標(biāo)紅，分配新的主分片
• 節(jié)點(diǎn)負(fù)載：主節(jié)點(diǎn)的角色既為 master 又為 data，訪問(wèn)量較大時(shí)可能會(huì)導(dǎo)致 ES 停止響應(yīng)造成大面積延遲，此時(shí)其他節(jié)點(diǎn)得不到主節(jié)點(diǎn)的響應(yīng)認(rèn)為主節(jié)點(diǎn)掛掉了，會(huì)重新選取主節(jié)點(diǎn)。
• 內(nèi)存回收：data 節(jié)點(diǎn)上的 ES 進(jìn)程占用的內(nèi)存較大，引發(fā) JVM 的大規(guī)模內(nèi)存回收，造成 ES 進(jìn)程失去響應(yīng)

腦裂問(wèn)題解決方案：

• 減少誤判： discovery.zen.ping_timeout 節(jié)點(diǎn)狀態(tài)的響應(yīng)時(shí)間， 默認(rèn)為 3s，可以適當(dāng)調(diào)大，如果 master在該響應(yīng)時(shí)間的范圍內(nèi)沒(méi)有做出響應(yīng)應(yīng)答，判斷該節(jié)點(diǎn)已經(jīng)掛掉了。調(diào)大參數(shù)(如 6s ， discovery.zen.ping_timeout:6 ) ，可適當(dāng)減少誤判。
• 選舉觸發(fā): discovery.zen.minimum_master_nodes:1，該參數(shù)是用于控制選舉行為發(fā)生的最小集群主節(jié)點(diǎn)數(shù)量。當(dāng)備選主節(jié)點(diǎn)的個(gè)數(shù)大于等于該參數(shù)的值， 且備選主節(jié)點(diǎn)中有該參數(shù)個(gè)節(jié)點(diǎn)認(rèn)為主節(jié)點(diǎn)掛了， 進(jìn)行選舉。官方建議為(n/2) +1，n 為主節(jié)點(diǎn)個(gè)數(shù) (即有資格成為主節(jié)點(diǎn)的節(jié)點(diǎn)個(gè)數(shù))
• 角色分離：即 master 節(jié)點(diǎn)與data 節(jié)點(diǎn)分離，限制角色
  • 主節(jié)點(diǎn)配置為： node.master: true node.data: false
  • 從節(jié)點(diǎn)配置為： node.master: false node.data: true

4、文檔索引步驟順序是什么？

新建單個(gè)文檔所需要的步驟順序：

客戶(hù)端向 Node 1 發(fā)送新建、索引或者刪除請(qǐng)求。

節(jié)點(diǎn)使用文檔的 _id 確定文檔屬于分片 0 。請(qǐng)求會(huì)被轉(zhuǎn)發(fā)到 Node 3，因?yàn)榉制?0 的主分片目前被分配在 Node 3 上。

Node 3 在主分片上面執(zhí)行請(qǐng)求。如果成功了，它將請(qǐng)求并行轉(zhuǎn)發(fā)到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都報(bào)告成功, Node 3 將向協(xié)調(diào)節(jié)點(diǎn)報(bào)告成功，協(xié)調(diào)節(jié)點(diǎn)向客戶(hù)端報(bào)告成功。

5、Elasticsearch 索引文檔的流程？

• 協(xié)調(diào)節(jié)點(diǎn)默認(rèn)使用文檔ID參與計(jì)算（也支持通過(guò)routing），以便為路由提供合適的分片。

shard = hash(document_id) % (num_of_primary_shards)

• 當(dāng)分片所在的節(jié)點(diǎn)接收到來(lái)自協(xié)調(diào)節(jié)點(diǎn)的請(qǐng)求后，會(huì)將請(qǐng)求寫(xiě)入到Memory Buffer，然后定時(shí)（默認(rèn)是每隔1秒）寫(xiě)入到Filesystem Cache，這個(gè)從Momery Buffer到Filesystem Cache的過(guò)程就叫做refresh；
• 當(dāng)然在某些情況下，存在Momery Buffer和Filesystem Cache的數(shù)據(jù)可能會(huì)丟失，ES是通過(guò)translog的機(jī)制來(lái)保證數(shù)據(jù)的可靠性的。其實(shí)現(xiàn)機(jī)制是接收到請(qǐng)求后，同時(shí)也會(huì)寫(xiě)入到translog中，當(dāng)Filesystem cache中的數(shù)據(jù)寫(xiě)入到磁盤(pán)中時(shí)，才會(huì)清除掉，這個(gè)過(guò)程叫做flush。
• 在flush過(guò)程中，內(nèi)存中的緩沖將被清除，內(nèi)容被寫(xiě)入一個(gè)新段，段的fsync將創(chuàng)建一個(gè)新的提交點(diǎn)，并將內(nèi)容刷新到磁盤(pán)，舊的translog將被刪除并開(kāi)始一個(gè)新的translog。 flush觸發(fā)的時(shí)機(jī)是定時(shí)觸發(fā)（默認(rèn)30分鐘）或者translog變得太大（默認(rèn)為512M）時(shí)。

6、 Elasticsearch 更新和刪除文檔的流程？

• 刪除和更新也都是寫(xiě)操作，但是 Elasticsearch 中的文檔是不可變的，因此不能被刪除或者改動(dòng)以展示其變更；
• 磁盤(pán)上的每個(gè)段都有一個(gè)相應(yīng)的.del 文件。當(dāng)刪除請(qǐng)求發(fā)送后，文檔并沒(méi)有真的被刪除，而是在.del文件中被標(biāo)記為刪除。該文檔依然能匹配查詢(xún)，但是會(huì)在結(jié)果中被過(guò)濾掉。當(dāng)段合并時(shí)，在.del 文件中被標(biāo)記為刪除的文檔將不會(huì)被寫(xiě)入新段。
• 在新的文檔被創(chuàng)建時(shí)， Elasticsearch 會(huì)為該文檔指定一個(gè)版本號(hào)， 當(dāng)執(zhí)行更新時(shí)， 舊版本的文檔在.del文件中被標(biāo)記為刪除， 新版本的文檔被索引到一個(gè)新段。舊版本的文檔依然能匹配查詢(xún)， 但是會(huì)在結(jié) 果中被過(guò)濾掉。

7、Elasticsearch 搜索的流程？

• 搜索被執(zhí)行成一個(gè)兩階段過(guò)程，我們稱(chēng)之為 Query Then Fetch；
• 在初始查詢(xún)階段時(shí)，查詢(xún)會(huì)廣播到索引中每一個(gè)分片拷貝(主分片或者副本分片) 。 每個(gè)分片在本地執(zhí)行搜索并構(gòu)建一個(gè)匹配文檔的大小為 from + size 的優(yōu)先隊(duì)列。PS：在搜索的時(shí)候是會(huì)查詢(xún) Filesystem Cache 的，但是有部分?jǐn)?shù)據(jù)還在 Memory Buffer，所以搜索是近實(shí)時(shí)的。
• 每個(gè)分片返回各自?xún)?yōu)先隊(duì)列中 所有文檔的 ID 和排序值 給協(xié)調(diào)節(jié)點(diǎn)， 它合并這些值到自己的優(yōu)先隊(duì)列中來(lái)產(chǎn)生一個(gè)全局排序后的結(jié)果列表。
• 接下來(lái)就是取回階段， 協(xié)調(diào)節(jié)點(diǎn)辨別出哪些文檔需要被取回并向相關(guān)的分片提交多個(gè) GET 請(qǐng)求。每個(gè)分片加載并豐富文檔，如果有需要的話(huà)，接著返回文檔給協(xié)調(diào)節(jié)點(diǎn)。一旦所有的文檔都被取回了， 協(xié)調(diào)節(jié)點(diǎn)返回結(jié)果給客戶(hù)端。
• Query Then Fetch 的搜索類(lèi)型在文檔相關(guān)性打分的時(shí)候參考的是本分片的數(shù)據(jù)，這樣在文檔數(shù)量較少的時(shí)候可能不夠準(zhǔn)確， DFS Query Then Fetch 增加了一個(gè)預(yù)查詢(xún)的處理，詢(xún)問(wèn) Term 和 Document frequency，這個(gè)評(píng)分更準(zhǔn)確， 但是性能會(huì)變差。

8、GC 方面，在使用 Elasticsearch 時(shí)要注意什么？

• 倒排詞典的索引需要常駐內(nèi)存，無(wú)法 GC，需要監(jiān)控 data node 上 segment memory 增長(zhǎng)趨勢(shì)。
• 各類(lèi)緩存， field cache, filter cache, indexing cache, bulk queue 等等， 要設(shè)置合理的大小， 并且要應(yīng)該根據(jù)最壞的情況來(lái)看 heap 是否夠用，也就是各類(lèi)緩存全部占滿(mǎn)的時(shí)候，還有 heap 空間可以分配給其他 任務(wù)嗎？避免采用 clear cache 等“自欺欺人”的方式來(lái)釋放內(nèi)存。
• 避免返回大量結(jié)果集的搜索與聚合。確實(shí)需要大量拉取數(shù)據(jù)的場(chǎng)景， 可以采用 scan & scroll api 來(lái)實(shí)現(xiàn)。
• cluster stats 駐留內(nèi)存并無(wú)法水平擴(kuò)展，超大規(guī)模集群可以考慮分拆成多個(gè)集群通過(guò) tribe node 連接。
• 想知道 heap 夠不夠，必須結(jié)合實(shí)際應(yīng)用場(chǎng)景，并對(duì)集群的 heap 使用情況做持續(xù)的監(jiān)控。

9、Elasticsearch 在部署時(shí)，對(duì) Linux 的設(shè)置有哪些優(yōu)化方法？

• 64 GB 內(nèi)存的機(jī)器是非常理想的， 但是 32 GB 和 16 GB 機(jī)器也是很常見(jiàn)的。少于 8 GB 會(huì)適得其反。
• 如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個(gè)內(nèi)核提供的額外并發(fā)遠(yuǎn)勝過(guò)稍微快一點(diǎn)點(diǎn)的時(shí)鐘頻率。
• 如果你負(fù)擔(dān)得起 SSD，它將遠(yuǎn)遠(yuǎn)超出任何旋轉(zhuǎn)介質(zhì)。 基于 SSD 的節(jié)點(diǎn)， 查詢(xún)和索引性能都有提升。如果你負(fù)擔(dān)得起， SSD 是一個(gè)好的選擇。
• 即使數(shù)據(jù)中心們近在咫尺，也要避免集群跨越多個(gè)數(shù)據(jù)中心。絕對(duì)要避免集群跨越大的地理距離。
• 請(qǐng)確保運(yùn)行你應(yīng)用程序的 JVM 和服務(wù)器的 JVM 是完全一樣的。 在 Elasticsearch 的幾個(gè)地方，使用 Java 的本地序列化。
• 通過(guò)設(shè)置 gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time 可以在集群重啟的時(shí)候避免過(guò)多的分片交換，這可能會(huì)讓數(shù)據(jù)恢復(fù)從數(shù)個(gè)小時(shí)縮短為幾秒鐘。
• Elasticsearch 默認(rèn)被配置為使用單播發(fā)現(xiàn)，以防止節(jié)點(diǎn)無(wú)意中加入集群。只有在同一臺(tái)機(jī)器上運(yùn)行的節(jié)點(diǎn)才會(huì)自動(dòng)組成集群。最好使用單播代替組播。
• 不要隨意修改垃圾回收器(CMS)和各個(gè)線程池的大小。
• 你的內(nèi)存的(少于) 一半給 Lucene (但不要超過(guò) 32 GB！) ，通過(guò) ES_HEAP_SIZE 環(huán)境變量設(shè)置。
• 內(nèi)存交換到磁盤(pán)對(duì)服務(wù)器性能來(lái)說(shuō)是致命的。如果內(nèi)存交換到磁盤(pán)上，一個(gè) 100 微秒的操作可能變成 10 毫秒。 再想想那么多 10 微秒的操作時(shí)延累加起來(lái)。 不難看出 swapping 對(duì)于性能是多么可怕。
• Lucene 使用了大量的文件。同時(shí)， Elasticsearch 在節(jié)點(diǎn)和 HTTP 客戶(hù)端之間進(jìn)行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應(yīng)該增加你的文件描述符， 設(shè)置一個(gè)很大的值，如 64,000。

10、索引階段性能提升方法有哪些？

• 使用批量請(qǐng)求并調(diào)整其大?。好看闻繑?shù)據(jù) 5 – 15 MB 大是個(gè)不錯(cuò)的起始點(diǎn)。
• 存儲(chǔ)：使用 SSD
• 段和合并： Elasticsearch 默認(rèn)值是 20 MB/s，對(duì)機(jī)械磁盤(pán)應(yīng)該是個(gè)不錯(cuò)的設(shè)置。如果你用的是 SSD，可以考慮提高到 100 –200 MB/s。如果你在做批量導(dǎo)入， 完全不在意搜索， 你可以徹底關(guān)掉合并限流。 另外還可以增加 index.translog.flush_threshold_size 設(shè)置，從默認(rèn)的 512 MB 到更大一些的值，比如 1 GB ，這可以在一次清空觸發(fā)的時(shí)候在事務(wù)日志里積累出更大的段。
• 如果你的搜索結(jié)果不需要近實(shí)時(shí)的準(zhǔn)確度，考慮把每個(gè)索引的 index.refresh_interval 改到 30s。
• 如果你在做大批量導(dǎo)入，考慮通過(guò)設(shè)置 index.number_of_replicas: 0 關(guān)閉副本。

11、elasticsearch 了解多少，說(shuō)說(shuō)你們公司 es 的集群架構(gòu)，索引數(shù)據(jù)大小，分片有多少，以及一些調(diào)優(yōu)手段 。

面試官：想了解應(yīng)聘者之前公司接觸的 ES 使用場(chǎng)景、規(guī)模，有沒(méi)有做過(guò)比較大規(guī)模的索引設(shè)計(jì)、規(guī)劃、調(diào)優(yōu)。

解答：如實(shí)結(jié)合自己的實(shí)踐場(chǎng)景回答即可。

比如：ES 集群架構(gòu) 13 個(gè)節(jié)點(diǎn)，索引根據(jù)通道不同共 20+索引，根據(jù)日期，每日遞增 20+，索引：10分片，每日遞增 1 億+數(shù)據(jù)，每個(gè)通道每天索引大小控制：150GB 之內(nèi)。

僅索引層面調(diào)優(yōu)手段：

設(shè)計(jì)階段調(diào)優(yōu)

1. 根據(jù)業(yè)務(wù)增量需求，采取基于日期模板創(chuàng)建索引，通過(guò) roll over API 滾動(dòng)索引；
2. 使用別名進(jìn)行索引管理；
3. 每天凌晨定時(shí)對(duì)索引做 force_merge 操作，以釋放空間；
4. 采取冷熱分離機(jī)制，熱數(shù)據(jù)存儲(chǔ)到 SSD，提高檢索效率；冷數(shù)據(jù)定期進(jìn)行 shrink操作，以縮減存儲(chǔ)；
5. 采取 curator 進(jìn)行索引的生命周期管理；
6. 僅針對(duì)需要分詞的字段，合理的設(shè)置分詞器；
7. Mapping 階段充分結(jié)合各個(gè)字段的屬性，是否需要檢索、是否需要存儲(chǔ)等?！?/li>

寫(xiě)入調(diào)優(yōu)

1. 寫(xiě)入前副本數(shù)設(shè)置為 0；
2. 寫(xiě)入前關(guān)閉 refresh_interval 設(shè)置為-1，禁用刷新機(jī)制；
3. 寫(xiě)入過(guò)程中：采取 bulk 批量寫(xiě)入；
4. 寫(xiě)入后恢復(fù)副本數(shù)和刷新間隔；
5. 盡量使用自動(dòng)生成的 id。

查詢(xún)調(diào)優(yōu)

1. 禁用 wildcard；
2. 禁用批量 terms（成百上千的場(chǎng)景）；
3. 充分利用倒排索引機(jī)制，能 keyword 類(lèi)型盡量 keyword；
4. 數(shù)據(jù)量大時(shí)候，可以先基于時(shí)間敲定索引再檢索；
5. 設(shè)置合理的路由機(jī)制

12、Elasticsearch 對(duì)于大數(shù)據(jù)量(上億量級(jí)) 的聚合如何實(shí)現(xiàn)？

Elasticsearch 提供的首個(gè)近似聚合是 cardinality 度量。它提供一個(gè)字段的基數(shù)，即該字段的 distinct 或者 unique 值的數(shù)目。它是基于 HLL 算法的。 HLL 會(huì)先對(duì)我們的輸入作哈希運(yùn)算，然后根據(jù)哈希運(yùn)算的 結(jié)果中的 bits 做概率估算從而得到基數(shù)。其特點(diǎn)是： 可配置的精度， 用來(lái)控制內(nèi)存的使用(更精確 ＝ 更 多內(nèi)存)；小的數(shù)據(jù)集精度是非常高的；我們可以通過(guò)配置參數(shù)，來(lái)設(shè)置去重需要的固定內(nèi)存使用量。無(wú) 論數(shù)千還是數(shù)十億的唯一值，內(nèi)存使用量只與你配置的精確度相關(guān)

13、在并發(fā)情況下，Elasticsearch 如果保證讀寫(xiě)一致？

• 可以通過(guò)版本號(hào)使用樂(lè)觀并發(fā)控制，以確保新版本不會(huì)被舊版本覆蓋，由應(yīng)用層來(lái)處理具體的沖突；
• 對(duì)于寫(xiě)操作，一致性級(jí)別支持 quorum/one/all，默認(rèn)為 quorum，即只有當(dāng)大多數(shù)分片可用時(shí)才允許寫(xiě)操作。但即使大多數(shù)可用， 也可能存在因?yàn)榫W(wǎng)絡(luò)等原因?qū)е聦?xiě)入副本失敗， 這樣該副本被認(rèn)為故 障，分片將會(huì)在一個(gè)不同的節(jié)點(diǎn)上重建。
• 對(duì)于讀操作， 可以設(shè)置 replication 為 sync(默認(rèn))，這使得操作在主分片和副本分片都完成后才會(huì)返回；如果設(shè)置 replication 為 async 時(shí)，也可以通過(guò)設(shè)置搜索請(qǐng)求參數(shù)_preference 為 primary 來(lái)查詢(xún)主分片， 確保文檔是最新版本。

14、如何監(jiān)控 Elasticsearch 集群狀態(tài)？

elasticsearch-head 插件
通過(guò) Kibana 監(jiān)控 Elasticsearch。你可以實(shí)時(shí)查看你的集群健康狀態(tài)和性能， 也可以分析過(guò)去的集群、 索引和節(jié)點(diǎn)指標(biāo)

15、是否了解字典樹(shù)？

常用字典數(shù)據(jù)結(jié)構(gòu)如下所示:

字典樹(shù)又稱(chēng)單詞查找樹(shù)， Trie 樹(shù)，是一種樹(shù)形結(jié)構(gòu)，是一種哈希樹(shù)的變種。典型應(yīng)用是用于統(tǒng)計(jì)， 排序和保存大量的字符串 (但不僅限于字符串) ，所以經(jīng)常被搜索引擎系統(tǒng)用于文本詞頻統(tǒng)計(jì)。

它的優(yōu)點(diǎn)是：利用字符串的公共前綴來(lái)減少查詢(xún)時(shí)間，最大限度地減少無(wú)謂的字符串比較，查詢(xún)效率比哈希樹(shù)高。

Trie 的核心思想是空間換時(shí)間，利用字符串的公共前綴來(lái)降低查詢(xún)時(shí)間的開(kāi)銷(xiāo)以達(dá)到提高效率的目的。

它有 3 個(gè)基本性質(zhì):

• 根節(jié)點(diǎn)不包含字符，除根節(jié)點(diǎn)外每一個(gè)節(jié)點(diǎn)都只包含一個(gè)字符
• 從根節(jié)點(diǎn)到某一節(jié)點(diǎn)，路徑上經(jīng)過(guò)的字符連接起來(lái)，為該節(jié)點(diǎn)對(duì)應(yīng)的字符串
• 每個(gè)節(jié)點(diǎn)的所有子節(jié)點(diǎn)包含的字符都不相同。

對(duì)于中文的字典樹(shù)，每個(gè)節(jié)點(diǎn)的子節(jié)點(diǎn)用一個(gè)哈希表存儲(chǔ)， 這樣就不用浪費(fèi)太大的空間， 而且查詢(xún)速度上 可以保留哈希的復(fù)雜度 O(1)。

16、 Elasticsearch 中的集群、節(jié)點(diǎn)、索引、文檔、類(lèi)型是什么？

• 集群是一個(gè)或多個(gè)節(jié)點(diǎn)(服務(wù)器) 的集合， 它們共同保存您的整個(gè)數(shù)據(jù)， 并提供跨所有節(jié)點(diǎn)的聯(lián)合索引和搜索功能。群集由唯一名稱(chēng)標(biāo)識(shí)， 默認(rèn)情況下為“elasticsearch”。此名稱(chēng)很重要， 因?yàn)槿绻?jié)點(diǎn)設(shè) 置為按名稱(chēng)加入群集，則該節(jié)點(diǎn)只能是群集的一部分。
• 節(jié)點(diǎn)是屬于集群一部分的單個(gè)服務(wù)器。它存儲(chǔ)數(shù)據(jù)并參與群集索引和搜索功能。
• 索引就像關(guān)系數(shù)據(jù)庫(kù)中的“數(shù)據(jù)庫(kù)”。它有一個(gè)定義多種類(lèi)型的映射。索引是邏輯名稱(chēng)空間， 映射到一個(gè)或多個(gè)主分片，并且可以有零個(gè)或多個(gè)副本分片。 MySQL =>數(shù)據(jù)庫(kù) Elasticsearch =>索引
• 文檔類(lèi)似于關(guān)系數(shù)據(jù)庫(kù)中的一行。不同之處在于索引中的每個(gè)文檔可以具有不同的結(jié)構(gòu)(字段) ，但是對(duì)于通用字段應(yīng)該具有相同的數(shù)據(jù)類(lèi)型。 MySQL => Databases => Tables => Columns / Rows Elasticsearch => Indices => Types =>具有屬性的文檔.
• 類(lèi)型是索引的邏輯類(lèi)別/分區(qū)，其語(yǔ)義完全取決于用戶(hù)。

17、Elasticsearch 中的倒排索引是什么？

倒排索引是搜索引擎的核心。搜索引擎的主要目標(biāo)是在查找發(fā)生搜索條件的文檔時(shí)提供快速搜索。 ES 中的倒排索引其實(shí)就是 lucene 的倒排索引，區(qū)別于傳統(tǒng)的正向索引， 倒排索引會(huì)再存儲(chǔ)數(shù)據(jù)時(shí)將關(guān)鍵詞和數(shù)據(jù)進(jìn)行關(guān)聯(lián)，保存到倒排表中，然后查詢(xún)時(shí)，將查詢(xún)內(nèi)容進(jìn)行分詞后在倒排表中進(jìn)行查詢(xún)，最后匹配數(shù) 據(jù)即可。

18、Elasticsearch與數(shù)據(jù)庫(kù)之間的對(duì)應(yīng)關(guān)系是什么？

Elasticsearch	數(shù)據(jù)庫(kù)
索引index	數(shù)據(jù)庫(kù)
文檔	表數(shù)據(jù)
索引庫(kù)(index)中的映射	數(shù)據(jù)庫(kù)(database)中的表結(jié)構(gòu)(table)
字段(Field)	數(shù)據(jù)表的字段，對(duì)文檔數(shù)據(jù)根據(jù)不同屬性進(jìn)行的分類(lèi)標(biāo)識(shí)
反向索引	索引
查詢(xún)DSL	SQL
get http://	select * from table
put http://	update table set
delete http://	delete

19、數(shù)據(jù)庫(kù)修改信息如何同步ElasticSearch？

1. 同步調(diào)用：直接在代碼里寫(xiě)邏輯，數(shù)據(jù)在增刪改查進(jìn)數(shù)據(jù)庫(kù)的同時(shí)，也往es里同步一份
2. 使用官方的logstash，定時(shí)查詢(xún)數(shù)據(jù)庫(kù)，查詢(xún)到數(shù)據(jù)有變化就發(fā)送到es中
3. 利用數(shù)據(jù)庫(kù)的binlog同步變化數(shù)據(jù)，然后將數(shù)據(jù)發(fā)送給es,當(dāng)然也可以通過(guò)java代碼監(jiān)聽(tīng)拿到數(shù)據(jù)，再發(fā)送到es或做其他處理。
4. MQ中間件，有數(shù)據(jù)變化的時(shí)候，就通知mq，然后監(jiān)聽(tīng)mq實(shí)現(xiàn)數(shù)據(jù)同步到mq

20、如何在保留不變性的前提下實(shí)現(xiàn)倒排索引的更新？

用更多的索引。通過(guò)增加新的補(bǔ)充索引來(lái)反映新近的修改， 而不是直接重寫(xiě)整 個(gè)倒排索引。每一個(gè)倒排索引都會(huì)被輪流查詢(xún)到，從最早的開(kāi)始查詢(xún)完后再對(duì)結(jié)果進(jìn)行合并。

21、ElasticSearch的主要功能及應(yīng)用場(chǎng)景？

• 主要功能：

1）海量數(shù)據(jù)的分布式存儲(chǔ)以及集群管理，達(dá)到了服務(wù)與數(shù)據(jù)的高可用以及水平擴(kuò)展；

2）近實(shí)時(shí)搜索，性能卓越。對(duì)結(jié)構(gòu)化、全文、地理位置等類(lèi)型數(shù)據(jù)的處理；

3）海量數(shù)據(jù)的近實(shí)時(shí)分析（聚合功能）

• 應(yīng)用場(chǎng)景：

1）網(wǎng)站搜索、垂直搜索、代碼搜索；

2）日志管理與分析、安全指標(biāo)監(jiān)控、應(yīng)用性能監(jiān)控、Web抓取輿情分析

好了，本文就到這里了！如果覺(jué)得內(nèi)容不錯(cuò)的話(huà)，希望大家可以幫忙點(diǎn)贊轉(zhuǎn)發(fā)一波，這是對(duì)我最大的鼓勵(lì)，感謝????

本篇服務(wù)資料：【imooc-490】笑傲Java面試 剖析大廠…頻面試真題 秒變offer收割機(jī)：https://www.aliyundrive.com/s/y3W6uHvqPGT

資料獲取?? 最后面就是領(lǐng)取暗號(hào)，公眾號(hào)回復(fù)即可！

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-723428.html

到了這里，關(guān)于2023最新整理的 Elasticsearch 21道面試題的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！