ElasticSearch 筆記（一）
一、Elasticsearch 印象
分散式、全文檢索、資料分析。
二、為什麼不用傳統關係型資料庫，如 MySQL，做搜尋
舉個反例。假設有以下資料庫表 t_game：
| id | name |
|---|---|
| 1 | 唐僧取經 |
| 2 | 西天取經 |
| 3 | 唐僧不取經 |
需求：你在搜尋輸入框中輸入 “唐僧取經”，希望找出相關的遊戲。
轉化成 SQL 就是：SELECT * FROM t_game where name LIKE '%唐僧取經%';
LIKE 前後模糊匹配，不走索引，只能全表掃描，資料量很大的話，比如有個 1 千萬條記錄，就需要掃描 1 千萬次，效能肯定很差。
還有一個問題，當你搜索 “唐僧取經” 的時候，也許 “唐僧不取經” 也是你想要的結果，
但是 SQL 查詢無法匹配這條記錄。
所以，用關係型資料庫做搜尋，有兩大問題：① 全表掃描，效能不好 ② 只能把輸入關鍵字作為一個整體，也就是不能全文檢索。
三、全文搜尋 和 倒排索引
利用一種叫做 “倒排索引” 的東東，大致原理：
把 t_game 表的 name 欄位進行分詞，然後記錄分出來的詞對應的 id
| 分詞 | ids |
|---|---|
| 取經 | 1、2、3 |
| 唐僧 | 1、3 |
| 西天 | 2 |
| 不 | 3 |
然後，對搜尋關鍵字 “唐僧取經” 也進行分詞：唐僧、取經。
第一次拿 “唐僧” 去查倒排索引，可以查到遊戲 id 為：1、3 的記錄；接著用 “取經” 再去查倒排索引，
可以查到遊戲 id 為：1、2、3 的記錄，合併結果就是返回 1、2、3 的記錄。
在本例中，即使資料有千千萬，只需要 2 次查詢，就可以查到所有結。
所以，利用 倒排索引，可以解決兩個問題：全文搜尋、效能問題。
四、lucene
簡單來說就是一個 jar 包，封裝了建立 倒排索引 的演算法，已經各種 搜尋 演算法，可以用來做全文檢索。
五、Elasticsearch
lucene 雖然可以做全文檢索，
但是隻能單機，不能叢集，當資料量太大以致單機無法容納，需要分散式處理時，處理起來很麻煩；
也不能做複雜的資料分析。
於是順其自然的就有了 Elasticsearch，Elasticsearch 可以分散式叢集，並且可以做一些複雜的資料分析，而且高可用，
當一些節點掛掉後，還能正常對外服務。