1 基本概念

1.1 檢索概念

Es 索引、類型、文檔、Field 分別怎麼理解？這些概念背後的物理含義。

名稱	概念	對應關係型數據庫概念	說明	備註
Cluster	集羣		一個或多個節點的集合，通過啓動時指定名字作爲唯一標識，默認cluster-state
node	節點		啓動的ES的單個實例，保存數據並具有索引和搜索的能力，通過名字唯一標識，默認node-n
index	索引	Database	具有相似特點的文檔的集合，可以對應爲關係型數據庫中的數據庫，通過名字在集羣內唯一標識
type	文檔類別	Table	索引內部的邏輯分類，可以對應爲Mysql中的表，ES 6.x 版本中，一個索引只允許一個type，不再支持多個type。7.x版本中，type將廢棄。
document	文檔	Row	構成索引的最小單元，屬於一個索引的某個類別，從屬關係爲： Index -> Type -> Document，通過id 在Type 內唯一標識。也是構建索引和查詢的最小單位
field	字段	Column	構成文檔的單元	比如對於一篇，論文，作者、標題、正文、發表時間
mapping	索引映射（約束）	Schema	用來約束文檔字段的類型，可以理解爲索引內部結構。類似數據庫中的表定義。核心數據類型：字符串 text, 字符串：keyword 數值型、布爾型、日期型、範圍型	http://laijianfeng.org/2018/08/Elasticsearch-6-x-Mapping%E8%AE%BE%E7%BD%AE/
shard	分片		將索引分爲多個塊，每塊叫做一個分片。索引定義時需要指定分片數且不能更改，默認一個索引有5個分片，每個分片都是一個功能完整的Index，分片帶來規模上（數據水平切分）和性能上（並行執行）的提升，是ES數據存儲的最小單位
replicas	分片的備份		每個分片默認一個備份分片，它可以提升節點的可用性，同時能夠提升搜索時的併發性能（搜索可以在全部分片上並行執行）

2 Lucene

2.1 簡介

2.1.1 Lucene基本流程

2.1.2 Lucene特性說明

非實時，從建索引到可以搜索中間有一個時間延遲，而當前的“近實時”(Lucene Near Real Time search)搜索方案的可擴展性有待進一步完善

非實時，從建索引到可以搜索中間有一個時間延遲？？？這個時間間隔具體在幹什麼？爲什麼Lucene不實時？

Es採用了近實時方案，Es怎麼解決Lucene的那個時間間隔的問題？

Es的解決方式是引入了一個FileSystemCache，在內存中生成索引之後，如果寫到磁盤比較慢，但是如果先寫到FileSystemCache中，速度非常快，生成到FileSystemCahce就可以使用索引了，後續的問題再交由FileSystemCache中。

[Lucene版本變遷] https://blog.csdn.net/jiangchao858/article/details/78897818

2.2 基本概念及操作

2.2.1 檢索建模

文檔、Filed、term

類關係圖

從上述類關係圖就可以看出來，Document只是一個Field的容器，並沒有格式化的scheme，即不同的Document可以有不同名稱的Field。

構建和查詢的最小單元：文檔是構建索引的最小單元，Field是索引查詢的最小單元。

構建索引的時候

indexWriter.addDocument(doc);

從上述代碼可以看出doc是構建索引的單元；查詢的時候是指定一個索引目錄，查詢的過程就是在這個查詢目錄下進行，查詢的時候可以指定在某個Field下查詢，所以查詢的最小單元是Field。

不同Filed之間的區別：

Field StringField和TextField的區別,是否tokenized。簡而言之，是否作爲一個整體去索引。

2.2.2 創建索引

示意圖：

創建方式：

創建有三種，通過IndexWriterConfig.OpenMode進行指定，分別是

CREATE：創建一個新的索引或者覆寫已經存在的索引
APPEND：打開一個已經存在的索引
CREATE_OR_APPEND：如果不存在則創建新的索引，如果存在則追加索引

2.2.3 更新索引

先刪除再新建；注意：只可根據索引的字段進行更新。

2.3 Lucene底層數據結構及原理

DocId的編碼、term的存儲

2.3.1 term存儲

原始數據怎麼高效存儲？

倒排表怎麼高效存儲？ FST (從Lucene4開始，從Lucene3開始，在3及其以前是使用跳錶，但是跳錶對模糊查詢支持不好，故改成了跳錶)

倒排表的形式決定了key大部分的前綴或者後綴是可以高效利用的。

採用這種是爲了加載到內存中，如果不能加載到內存中，怎麼辦？

2.2.3

通過FST找對對應的docIds(docId都是有序集合)之後，如何並集、交集、差集。

交集：

[有序數組求交集方法] http://www.6aiq.com/article/1559927141249?p=1&m=0

Lucene5開始使用了bitMap來求交集；bitMap的使用得先判定使用場景。

2.4 Lucene的評分機制

3 ElasticSearch

3.1 定位及競品對比

對比項	優點	缺點
Es	Elasticsearch是分佈式的。不需要其他組件，分發是實時的，被叫做”Push replication”。 Elasticsearch 完全支持 Apache Lucene 的接近實時的搜索。處理多租戶（multitenancy）不需要特殊配置，而Solr則需要更多的高級設置。 Elasticsearch 採用 Gateway 的概念，使得完備份更加簡單。各節點組成對等的網絡結構，某些節點出現故障時會自動分配其他節點代替其進行工作。	Elasticsearch 是計算密集型的。官方建議運行 ES 的機器最好有 64 GB 的內存，強烈反對在低於 8 GB 內存的機器上運行它。Elasticsearch 是一個內存中數據庫，這樣使它的查詢速度非常快，但這也非常佔用系統內存。在生產系統中使用時，他們強烈建議在一個集羣中運行多個 Elasticsearch 節點，以實現高可用、自動分區和一個節點失敗時的數據冗餘。
Solr	Solr有一個更大、更成熟的用戶、開發和貢獻者社區。支持添加多種格式的索引，如：HTML、PDF、微軟 Office 系列軟件格式以及 JSON、XML、CSV 等純文本格式。 solr比較成熟、穩定。不考慮建索引的同時進行搜索，速度更快。	建立索引時，搜索效率下降，實時索引搜索效率不高。
總結	Solr 利用 Zookeeper 進行分佈式管理，而 Elasticsearch 自身帶有分佈式協調管理功能; Solr 在傳統的搜索應用中表現好於 Elasticsearch，但在處理實時搜索應用時效率明顯低於 Elasticsearch。總之，Solr 是傳統搜索應用的有力解決方案，但 Elasticsearch 更適用於新興的實時搜索應用。 Es耗資源其實不算一種缺點，其實更應該算是一個特性。

對比項

優點

缺點

Elasticsearch是分佈式的。不需要其他組件，分發是實時的，被叫做”Push replication”。
Elasticsearch 完全支持 Apache Lucene 的接近實時的搜索。
處理多租戶（multitenancy）不需要特殊配置，而Solr則需要更多的高級設置。
Elasticsearch 採用 Gateway 的概念，使得完備份更加簡單。
各節點組成對等的網絡結構，某些節點出現故障時會自動分配其他節點代替其進行工作。

Elasticsearch 是計算密集型的。官方建議運行 ES 的機器最好有 64 GB 的內存，強烈反對在低於 8 GB 內存的機器上運行它。Elasticsearch 是一個 內存中 數據庫，這樣使它的查詢速度非常快，但這也非常佔用系統內存。在生產系統中使用時，他們強烈建議在一個集羣中運行多個 Elasticsearch 節點，以實現高可用、自動分區和一個節點失敗時的數據冗餘。

Solr

Solr有一個更大、更成熟的用戶、開發和貢獻者社區。
支持添加多種格式的索引，如：HTML、PDF、微軟 Office 系列軟件格式以及 JSON、XML、CSV 等純文本格式。
solr比較成熟、穩定。
不考慮建索引的同時進行搜索，速度更快。

建立索引時，搜索效率下降，實時索引搜索效率不高。

總結

Solr 利用 Zookeeper 進行分佈式管理，而 Elasticsearch 自身帶有分佈式協調管理功能;

Solr 在傳統的搜索應用中表現好於 Elasticsearch，但在處理實時搜索應用時效率明顯低於 Elasticsearch。總之，Solr 是傳統搜索應用的有力解決方案，但 Elasticsearch 更適用於新興的實時搜索應用。

Es耗資源其實不算一種缺點，其實更應該算是一個特性。

3.2 分佈式架構設計

在3.1節中，我們也提到Es是自己實現了分佈式框架。具體來說，分爲兩塊

節點發現 --> Zen Discovery(基於gossip協議)
一致性算法 --> 自行實現了Raft協議

這兩塊其實和Consul非常類似，可以參考

3.2.1 Zen Discovery 模塊

Es基於Gossip協議來實現了節點發現功能，該模塊稱之爲Zen Discovery模塊。

https://cloud.tencent.com/developer/article/1421861

3.2.2 分佈式架構

主從架構 or p2p架構

經常遇到說Es是p2p的對等架構，也有不少說Es是主從架構的。那麼Es到底是主從架構還是P2P架構了？其實這兩種說法都對，只是分別是從不同的角度來描述Es的架構。

架構圖：

詳細說明：

從分佈式系統的角度來說，Es與其他分佈式不一樣的是Es是p2p架構。一般的分佈式系統，都是採用主從架構，master用來接受請求，並做請求的解析、任務的劃分，子任務結果的收集及聚合彙總操作(worker一般僅僅完成計算任務)。

當然主從架構不一定是分佈式計算系統，在普通的集羣中，也是廣泛使用主從架構

但是Es的任一節點都可以做請求解析，任務劃分及調度、彙總聚合這些主節點的操作。從這個角度來說，Es是P2P架構。

什麼使用p2p架構，爲了解決單點故障問題？幾臺Master組成一個集羣，也能解決單點故障。

在Es的語境中也有master的概念，諸多Es節點會選出一個Master(等同於Leader)，當一個節點被選舉成爲主節點時，它將負責管理集羣範圍內的所有變更，例如增加、刪除索引，或者增加、刪除節點等。而主節點並不需要涉及到文檔級別的變更和搜索等操作(不承載所有的請求)，所以當集羣只擁有一個主節點的情況下，即使流量的增加它也不會成爲瓶頸。任何節點都可以成爲主節點。

這個Master的職責是維護集羣元數據(集羣節點信息)，維護索引元數據(創建索引、修改索引、刪除索引)，

而worker節點則可以接受查詢任務(分佈式完成)。

作爲用戶，我們可以將請求發送到 集羣中的任何節點 ，包括主節點。每個節點都知道任意文檔所處的位置，並且能夠將我們的請求直接轉發到存儲我們所需文檔的節點。無論我們將請求發送到哪個節點，它都能負責從各個包含我們所需文檔的節點收集回數據，並將最終結果返回給客戶端。 Elasticsearch 對這一切的管理都是透明的。

所以單純從架構角度來說，Es其實也是主從架構的，採用了類似raft的協議，至於爲啥不用raft協議，說法很多。