Elasticsearch 實戰(一) - 簡介

• 官腔

Elasticsearch，分佈式，高性能，高可用，可伸縮的搜索和分析系統

基本等於沒說,我們慢慢看

1 概述

百度：咱們好比說想找尋任何的信息的時候，就會上百度去搜索一下，好比說找一部本身喜歡的電影，或者說找一本喜歡的書，或者找一條感興趣的新聞（提到搜索的第一印象）
百度 != 搜索，這是不對的

垂直搜索（站內搜索）

• 互聯網的搜索：電商網站，招聘網站，新聞網站，各類app
• IT系統的搜索：OA軟件，辦公自動化軟件，會議管理，日程管理，項目管理，員工管理，搜索「張三」，「張三兒」，「張小三」；有個電商網站，賣家，後臺管理系統，搜索「牙膏」，訂單，「牙膏相關的訂單」

搜索，就是在任何場景下，找尋你想要的信息，這個時候，會輸入一段你要搜索的關鍵字，而後就指望找到這個關鍵字相關的有些信息

---

2 數據庫搜索

數據都是存儲在數據庫裏面的
很天然的，若是從技術的角度去考慮，如何實現搜索，電商網站內部的搜索功能的話，就能夠考慮，去使用數據庫去進行搜索。

2.1 案例 - 電商系統的搜索

• 搜索含有牙膏的商品
• 在數據庫中商品名稱字段中存儲有關鍵字

數據庫來處理的話，不考慮數據庫的全文索引什麼的，假如商品有 1000萬 個，那麼基本上就要查找 1000 萬次，且每次都須要加載商品的名稱字段的整段字符串，並挨個尋找。

• 每條記錄的指定字段的文本，可能會很長

好比「商品描述」字段的長度，有長達數千個，甚至數萬個字符，這個時候，每次都要對每條記錄的全部文本進行掃描，懶判斷說，你包不包含我指定的這個關鍵詞（好比說「牙膏」）

• 沒法將搜索詞拆分開來

儘量去搜索更多的符合你的指望的結果，好比輸入「生化機」，就搜索不出來「生化危機」

用數據庫來實現搜索，是不太靠譜的。一般來講，性能會不好的。

---

3 全文檢索 & Lucene

3.1 全文檢索

3.1.1 場景：搜索「生化機」

• 全文檢索

（有多是手抖打錯了，原本是生化危機），可是指望須要出來右側的 4條 記錄

有 4條 數據
將每條數據進行詞條拆分。如「生化危機電影」拆成：生化、危機、電影 關鍵詞（拆分結果與策略算法有關）
每一個關鍵詞將對應包含此關鍵詞的數據 ID
搜索的時候，直接匹配這些關鍵詞，就能拿到包含關鍵詞的數據
這個過程就叫作全文檢索。而詞條拆分和詞條對應的 ID 這個就是倒排索引的的基本原理

對比數據庫的缺陷

數據庫裏的數據，共有100萬條,按照以前的思路,其實就要掃描100萬次，並且每次掃描,都須要匹配那個文本全部的字符，確認是否包含搜索的關鍵詞，並且還不能將搜索詞拆解開來進行檢索

利用倒排索引

進行搜索的話，假設100萬條數據,拆分出來的詞語,假設有1000萬個詞語，那麼在倒排索引中,就有1000萬行,咱們可能並不須要搜索1000萬次。
極可能說,在搜索到第一次的時候,咱們就能夠找到這個搜索詞對應的數據。
也多是第100次,或者第1000次

3.2 lucene

就是一個jar包，裏面包含了封裝好的各類創建倒排索引，以及進行搜索的代碼，包括各類算法

java開發的時候，引入lucene jar，而後基於lucene的API進行去進行開發就能夠了
用lucene，咱們就能夠去將已有的數據創建索引，lucene會在本地磁盤上面，給咱們組織索引的數據結構
另外的話，咱們也能夠用lucene提供的一些功能和API來針對磁盤上額

4 Elasticsearch的意義

咱們可使用 lucene 開發搜索服務，部署在一臺機器上面，可是沒法解決當數據量增大的時候出現的問題（圖上右側）。
那麼 elasticsearch 就是解決這種場景的工具；

• 自動維護數據的分佈到多個節點的索引創建、檢索請求分佈到多個節點的執行
• 自動維護數據的冗餘副本，保證一些機器宕機了，不會丟失任何數據
• 封裝了更多的高級功能
• 給咱們提供更多高級的支持，讓咱們快速的開發應用，開發更加複雜的應用
• 複雜的搜索功能，聚合分析的功能，基於地理位置的搜多（距離我當前位置 1千米 之內的烤肉店）

參考

• 搜索引擎
• [Elasticsearch頂尖高手系列]

本文由博客一文多發平臺 OpenWrite 發佈！