ElasticSearch簡介

目錄

• 1. 定義
• 2. 與 Lucene 的關係
• 3. 優勢
• 4. 缺點
• 5. 解決的問題
• 6. 應用場景
• 7. 倒排索引(摘自Elasticsearch權威指南)

---

1. 定義

Elasticsearch 是一個高度可擴展的開源全文搜索和分析引擎。它容許您快速，近實時地存儲，搜索和分析大量數據。它一般用做底層引擎、技術，爲具備複雜搜索功能和要求的應用程序提供支持。

Elasticsearch 也使用 Java 開發並使用 Lucene 做爲其核心來實現全部索引和搜索的功能，可是它的目的是經過簡單的 RESTful API 來隱藏 Lucene 的複雜性，從而讓全文搜索變得簡單。

ES 是基於Lucene這個很是成熟的索引方案，另加上一些分佈式的實現：集羣，分片，複製等。

2. 與 Lucene 的關係

Lucene 是一套用於全文檢索和搜尋的開源程式庫，由 Apache 軟件基金會支持和提供。Lucene 提供了一個簡單卻強大的應用程式接口，可以作全文索引和搜尋。可是 Lucene 操做複雜，通常不直接利用 Lucene 做爲搜索引擎，ElasticSearch 就是利用 Java 簡化了 Lucene 的使用。

3. 優勢

1. 具有橫向可擴展性：只須要增長一臺服務器，作些配置，啓動 ES 進程就能夠快速併入集羣。'
2. 分片機制：同一個索引分紅多個分片(sharding)，相似於 redis 中的分片，採起分而治之的思想來更好地解決問題。
3. 高可用：提供複製機制，一個分片能夠設置多個複製，使得某臺服務器宕機的話，集羣依舊能夠正常運行，並會把丟失的複製恢復到其它可用節點上'

4. 缺點

1. 節點數據的一致性問題：其默認的機制是經過多播機制，同步元數據信息，可是在比較繁忙的集羣中，可能會因爲網絡的阻塞，或者節點處理能力達到飽和致使各節點元數據不一致——也就是所謂的腦裂問題，這樣會使集羣處於不一致狀態。目前並無一個完全的解決方案來解決這個問題，可是能夠經過將工做節點與元數據節點分開的部署方案來緩解這種狀況。
2. 沒有細粒度的權限管理，沒有像MySQL那樣的分各類用戶，每一個用戶又有不一樣的權限。

5. 解決的問題

• 更快的在大量數據中檢索相關數據，性能遠優於傳統數據庫
• 結合分詞器，根據關鍵詞返回統計結果

6. 應用場景

• 全文檢索：例如淘寶 app 搜索 17寸電腦關鍵詞，搜索系統將依據關鍵詞分詞查詢，按照指定的匹配度返回對應的商品。這是 ES 最核心也是最經常使用的功能。
• 記錄和日誌分析：圍繞Elasticsearch構建的生態系統使其成爲最容易實施和擴展日誌記錄解決方案之一。結合Logstash，ElasticSearch 和Kibana 三個組件，能夠搭建一套高效的日誌收集和分析系統，也就是咱們常見的ELK系統。
• 數據可視化：Kibana 是一款功能強大且易於使用的可視化工具，能夠結合 ES 對大量數據提供圖表選項、地理數據等可視化組件。

7. 倒排索引(摘自Elasticsearch權威指南)

Elasticsearch 是經過 Lucene 的倒排索引技術實現比關係型數據庫更快的過濾。特別是它對多條件的過濾支持很是好。

Elasticsearch 使用一種稱爲 倒排索引 的結構，它適用於快速的全文搜索。一個倒排索引由文檔中全部不重複詞的列表構成，對於其中每一個詞，有一個包含它的文檔列表。

例如，假設咱們有兩個文檔，每一個文檔的 content 域包含以下內容：

1. The quick brown fox jumped over the lazy dog
2. Quick brown foxes leap over lazy dogs in summer

爲了建立倒排索引，咱們首先將每一個文檔的 content 域拆分紅單獨的 詞（咱們稱它爲 詞條 或 tokens），建立一個包含全部不重複詞條的排序列表，而後列出每一個詞條出如今哪一個文檔。結果以下所示：

Term      Doc_1  Doc_2
-------------------------
Quick   |       |  X
The     |   X   |
brown   |   X   |  X
dog     |   X   |
dogs    |       |  X
fox     |   X   |
foxes   |       |  X
in      |       |  X
jumped  |   X   |
lazy    |   X   |  X
leap    |       |  X
over    |   X   |  X
quick   |   X   |
summer  |       |  X
the     |   X   |
------------------------

如今，若是咱們想搜索 quick brown ，咱們只須要查找包含每一個詞條的文檔：

Term      Doc_1  Doc_2
-------------------------
brown   |   X   |  X
quick   |   X   |
------------------------
Total   |   2   |  1

兩個文檔都匹配，可是第一個文檔比第二個匹配度更高。若是咱們使用僅計算匹配詞條數量的簡單 類似性算法 ，那麼，咱們能夠說，對於咱們查詢的相關性來說，第一個文檔比第二個文檔更佳。

可是，咱們目前的倒排索引有一些問題：

• Quick 和 quick 以獨立的詞條出現，然而用戶可能認爲它們是相同的詞。
• fox 和 foxes 很是類似, 就像 dog 和 dogs ；他們有相同的詞根。
• jumped 和 leap, 儘管沒有相同的詞根，但他們的意思很相近。他們是同義詞。

使用前面的索引搜索 +Quick +fox 不會獲得任何匹配文檔。（記住，+ 前綴代表這個詞必須存在。）只有同時出現 Quick 和 fox 的文檔才知足這個查詢條件，可是第一個文檔包含 quick fox ，第二個文檔包含 Quick foxes 。

咱們的用戶能夠合理的指望兩個文檔與查詢匹配。咱們能夠作的更好。

若是咱們將詞條規範爲標準模式，那麼咱們能夠找到與用戶搜索的詞條不徹底一致，但具備足夠相關性的文檔。例如：

• Quick 能夠小寫化爲 quick 。
• foxes 能夠 詞幹提取 --變爲詞根的格式-- 爲 fox 。相似的， dogs 能夠爲提取爲 dog 。
• jumped 和 leap 是同義詞，能夠索引爲相同的單詞 jump 。

如今索引看上去像這樣：

Term      Doc_1  Doc_2
-------------------------
brown   |   X   |  X
dog     |   X   |  X
fox     |   X   |  X
in      |       |  X
jump    |   X   |  X
lazy    |   X   |  X
over    |   X   |  X
quick   |   X   |  X
summer  |       |  X
the     |   X   |  X
------------------------

這還遠遠不夠。咱們搜索 +Quick +fox 仍然 會失敗，由於在咱們的索引中，已經沒有 Quick 了。可是，若是咱們對搜索的字符串使用與 content 域相同的標準化規則，會變成查詢 +quick +fox ，這樣兩個文檔都會匹配！

github地址