0x00 什麼是Elasticsearch
Elasticsearch （ES）是一個基於 Lucene 的開源搜索引擎，它不但穩定、可靠、快速，而且也具有良好的水平擴展能力，是專門爲分佈式環境設計的,Elasticsearch是面向文檔型數據庫，這意味着它存儲的
整個對象或者文檔，它不但會存儲它們，還會爲他們建立索引，這樣你就可以搜索他們了。你可以在 Elasticsearch 中索引、搜索、排序和過濾這些文檔，不需要成行成列的數據，ElasticSearch 提供了一套基
於restful風格的全文檢索服務組件。前身是compass，直到2010被一家公司接管進行維護，開始商業化，並提供了ElasticSearch 一些相關的產品，包括大家比較熟悉的 kibana、logstash 以及 ElasticSearch的
一些組件，比如安全組件shield 。當前最新的ElasticSearch 版本爲 5.5.1 ，比較應用廣泛的爲2.X，直到 2016-12 推出了5.x 版本 ，將版本號調爲 5.X 。這是爲了和 kibana 和 logstash 等產品版本號進行統一ElasticSearch 。
0x01 Elasticsearch特性
1.安裝方便：沒有其他依賴，下載後安裝非常方便；只用修改幾個參數就可以搭建起來一個集羣
2.JSON：輸入/輸出格式爲 JSON，不需要定義 Schema，快捷方便
3.RESTful：基本所有操作（索引、查詢、甚至是配置）都可以通過 HTTP 接口進行(REST風格架構設計)
4.分佈式：節點對外表現對等（每個節點都可以用來做入口），加入節點自動均衡
5.多租戶：可根據不同的用途分索引；可以同時操作多個索引
6.準實時：從文檔索引到可以被檢索只有輕微延時，約1s
7.支持插件機制，分詞插件、同步插件、Hadoop插件、可視化插件等。
Elasticsearch使用Lucene作爲內部引擎，但是在使用它做全文搜索時，只需要使用統一開發好的API即可，而不需要了解其背後複雜的Lucene的運行原理。當然Elasticsearch並不僅僅是Lucene這麼簡單，它不但包括了全文搜索功能，還可以進行以下工作:
1.分佈式實時文件存儲，並將每一個字段都編入索引，使其可以被搜索。
2.實時分析的分佈式搜索引擎。
3.可以擴展到上百臺服務器，處理PB級別的結構化或非結構化數據。
4.這麼多的功能被集成到一臺服務器上，你可以輕鬆地通過客戶端或者任何你喜歡的程序語言與ES的RESTful API進行交流。
0x02 ElasticSearch相關概念
下圖是 Elasticsearch 插件 head 的一個截圖
● node：即一個 Elasticsearch 的運行實例，使用多播或單播方式發現 cluster 並加入。
● cluster：包含一個或多個擁有相同集羣名稱的 node，其中包含一個master node。
● index：類比關係型數據庫裏的DB，是一個邏輯命名空間。
● alias：可以給 index 添加零個或多個alias，通過 alias 使用index 和根據index name 訪問index一樣，但是，alias給我們提供了一種切換index的能力，比如重建了index，取名● customer_online_v2，這時，有了alias，我要訪問新 index，只需要把 alias 添加到新 index 即可，並把alias從舊的 index 刪除。不用修改代碼。
● type：類比關係數據庫裏的Table。其中，一個index可以定義多個type，但一般使用習慣僅配一個type。
● mapping：類比關係型數據庫中的 schema 概念，mapping 定義了 index 中的 type。mapping 可以顯示的定義，也可以在 document 被索引時自動生成，如果有新的 field，Elasticsearch 會自動推測出 field 的type並加到mapping中。
● document：類比關係數據庫裏的一行記錄(record)，document 是 Elasticsearch 裏的一個 JSON 對象，包括零個或多個field。
● field：類比關係數據庫裏的field，每個field 都有自己的字段類型。
● shard：是一個Lucene 實例。Elasticsearch 基於 Lucene，shard 是一個 Lucene 實例，被 Elasticsearch 自動管理。之前提到，index 是一個邏輯命名空間，shard 是具體的物理概念，建索引、查詢等都是
體的shard在工作。shard 包括primary shard 和 replica shard，寫數據時，先寫到primary shard，然後，同步到replica shard，查詢時，primary 和 replica 充當相同的作用。replica shard 可以有多份，也可
沒有，replica shard的存在有兩個作用，一是容災，如果primary shard 掛了，數據也不會丟失，集羣仍然能正常工作；二是提高性能，因爲replica 和 primary shard 都能處理查詢。另外，如上圖右側紅框
示，shard數和replica數都可以設置，但是，shard 數只能在建立index 時設置，後期不能更改，但是，replica 數可以隨時更改。但是，由於 Elasticsearch 很友好的封裝了這部分，在使用Elasticsearch 的過
中，我們一般僅需要關注 index 即可，不需關注shard。
綜上所述，shard、node、cluster 在物理上構成了 Elasticsearch 集羣，field、type、index 在邏輯上構成一個index的基本概念，在使用 Elasticsearch 過程中，我們一般關注到邏輯概念就好，就像我們在使用
MySQL 時，我們一般就關注DB Name、Table和schema即可，而不會關注DBA維護了幾個MySQL實例、master 和 slave 等怎麼部署的一樣。
要了解ES首先就要弄清楚下面的幾個概念，這樣也不會對ES產生一些誤解：
1. 近實時(NRT)
ES並不是一個標準的數據庫，它不像MongoDB，它側重於對存儲的數據進行搜索。因此要注意到它 不是 實時讀寫 的，這也就意味着，剛剛存儲的數據，並不能馬上查詢到。
當然這裏還要區分查詢的方式，ES也有數據的查詢以及搜索，這裏的近實時強調的是搜索....
2. 集羣(Cluster)
在ES中，對用戶來說集羣是很透明的。你只需要指定一個集羣的名字（默認是elasticsearch），啓動的時候，凡是集羣是這個名字的，都會默認加入到一個集羣中。
你不需要做任何操作，選舉或者管理都是自動完成的。
對用戶來說，僅僅是一個名字而已！
3. 節點(Node)
跟集羣的概念差不多，ES啓動時會設置這個節點的名字，一個節點也就是一個ES得服務器。
默認會自動生成一個名字，這個名字在後續的集羣管理中還是很有作用的，因此如果想要手動的管理或者查看一些集羣的信息，最好是自定義一下節點的名字。
4. 索引(Index)
索引是一類文檔的集合，所有的操作比如索引（索引數據）、搜索、分析都是基於索引完成的。
在一個集羣中，可以定義任意數量的索引。
5. 類型(Type)
類型可以理解成一個索引的邏輯分區，用於標識不同的文檔字段信息的集合。但是由於ES還是以索引爲粗粒度的單位，因此一個索引下的所有的類型，都存放在一個索引下。這也就導致不同類型相同字段名字的字段會存在類型定義衝突的問題。
在2.0之前的版本，是可以插入但是不能搜索；在2.0之後的版本直接做了插入檢查，禁止字段類型衝突。
6. 文檔(Document)
文檔是存儲數據信息的基本單元，使用json來表示。
7. 分片與備份(Sherd & Replica)
在ES中，索引會備份成分片，每個分片是獨立的lucene索引，可以完成搜索分析存儲等工作。
分片的好處：
1. 如果一個索引數據量很大，會造成硬件硬盤和搜索速度的瓶頸。如果分成多個分片，分片可以分攤壓力。
2. 分片允許用戶進行水平的擴展和拆分
3. 分片允許分佈式的操作，可以提高搜索以及其他操作的效率
拷貝一份分片就完成了分片的備份，那麼備份有什麼好處呢？
1. 當一個分片失敗或者下線時，備份的分片可以代替工作，提高了高可用性。
2. 備份的分片也可以執行搜索操作，分攤了搜索的壓力。
ES默認在創建索引時會創建5個分片，這個數量可以修改。
不過需要注意：
1. 分片的數量只能在創建索引的時候指定，不能在後期修改
2. 備份的數量可以動態的定義
0x03 Elasticsearch主要解決問題
1. 檢索相關數據； 2. 返回統計結果； 3. 速度要快：
0x04 Elasticsearch工作原理
當ElasticSearch的節點啓動後，它會利用多播(multicast)(或者單播，如果用戶更改了配置)尋找集羣中的其它節點，並與之建立連接。這個過程如下圖所示：
0x05 Elasticsearch對外接口
1. JAVA API接口
2. RESTful API接口
0x06 Elasticsearch JAVA客戶端
1.Transport客戶端
Transport Client表示傳輸客戶端，ElasticSearch內置客戶端的一種，使用傳輸模塊遠程連接到Elasticsearch集羣
2.Jest客戶端
Jest是ElasticSearch的Java HTTP Rest客戶端，第三方工具，它爲索引和搜索結果提供了一個POJO編組機制
0x07 基於Lucence的全文檢索
全文檢索就是對一篇文章進行索引，可以根據關鍵字搜索，類似於mysql裏的like語句。
全文索引就是把內容根據詞的意義進行分詞，然後分別創建索引，例如”你們的激情是因爲什麼事情來的” 可能會被分詞成：“你們“，”激情“，“什麼事情“，”來“ 等token，這樣當你搜索“你們” 或者 “激情” 都會
這句搜出來。
0x08 ElasticSearch與傳統關係型數據庫對比
在ElasticSearch中，我們常常會聽到Index、Type以及Document等概念，將Elasticsearch和傳統關係型數據庫MySQL做一下類比：
index => databases type => table field => field document => record mapping => schema
簡單描述:
1） Index
定義：類似於mysql中的database。索引只是一個邏輯上的空間，物理上是分爲多個文件來管理的。
命名：必須全小寫
描述：因爲本身ES是基於Lucene的，所以內部索引的本質上其實Lucene的索引構造方式.
ES中index可能被分爲多個分片【對應物理上的lcenne索引】，在實踐過程中每個index都會有一個相應的副 本。主要用來在硬件出現問題時，用來回滾數據的。這也某種程序上，加劇了ES對於內存高要求。
2）Type
定義：類似於mysql中的table，根據用戶需求每個index中可以新建任意數量的type。
3）Document
定義：對應mysql中的row。有點類似於MongoDB中的文檔結構，每個Document是一個json格式的文本。
4）Mapping
更像是一個用來定義每個字段類型的語義規範在mysql中類似sql語句，在ES中經過包裝後，都被封裝爲友好的Restful風格的接口進行操作。這一點也是爲什麼開發人員更願意使用ES或者compass這樣的框架
而不是直接使用Lucene的一個原因。
5）Shards & Replicas
定義：能夠爲每個索引提供水平的擴展以及備份操作。
描述：
Shards:在單個節點中，index的存儲始終是有限制，並且隨着存儲的增大會帶來性能的問題。爲了解決這個問題，ElasticSearch提供一個能夠分割單個index到集羣各個節點的功能。你可以在新建這個索引時，
手動的定義每個索引分片的數量。
6）Replicas
在每個node出現宕機或者下線的情況，Replicas能夠在該節點下線的同時將副本同時自動分配到其他仍然可用的節點。而且在提供搜索的同時，允許進行擴展節點的數量，在這個期間並不會出現服務終止的情況。
默認情況下，每個索引會分配5個分片，並且對應5個分片副本，同時會出現一個完整的副本【包括5個分配的副本數據】。
從 Elasticsearch 中取出一條數據（document）看看：
由index、type和id三者唯一確定一個document，_source 字段中是具體的document 值，是一個JSON 對象，有5個field組成。
注意：mysql的Index和Elasticsearch的Index含義並不一致。
Elasticsearch集羣可以包含多個索引(indices)(數據庫),每一個索引可以包含多個類型(types)(表), 每一個類型包含多個文檔(documents)(行),然後每個文檔包含多個字段(Fields)(列)。數據被存儲和索引在分片
(shards)中,索引只是把一個或多個分片分組在一起的邏輯空間。我們只需要知道文檔存儲在索引(index)中。其他細節都可以有Elasticsearch搞定。
總結: （1）關係型數據庫中的數據庫（DataBase），等價於ES中的索引（Index） （2）一個數據庫下面有N張表（Table），等價於1個索引Index下面有N多類型（Type）。 （3）一個數據庫表（Table）下的數據由多行（ROW）多列（column，屬性）組成，等價於1個Type由多個文檔（Document）和多Field組成。 （4）在一個關係型數據庫裏面，schema定義了表、每個表的字段，還有表和字段之間的關係。 與之對應的，在ES中：Mapping定義索引下的Type的字段處理規則，即索引如何建立、索引類型、是否保存原 始索引JSON文檔、是否壓縮原始JSON文檔、是否需要分詞處理、如何進行分詞處理等。 （5）在數據庫中的增insert、刪delete、改update、查search操作等價於ES中的增PUT/POST、刪Delete、改_update、查GET。
0x09 Elasticsearch應用場景
1.它提供了強大的搜索功能，可以實現類似百度、谷歌等搜索。
2.可以搜索日誌或者交易數據，用來分析商業趨勢、蒐集日誌、分析系統瓶頸或者運行發展等等
3.可以提供預警功能（持續的查詢分析某個數據，如果超過一定的值，就進行警告）
4.分析商業信息，在百萬級的大數據中輕鬆的定位關鍵信息
5.維基百科使用Elasticsearch來進行全文搜做並高亮顯示關鍵詞，以及提供search-as-you-type、did-you-mean等搜索建議功能。
6.英國衛報使用Elasticsearch來處理訪客日誌，以便能將公衆對不同文章的反應實時地反饋給各位編輯。
7.StackOverflow將全文搜索與地理位置和相關信息進行結合，以提供more-like-this相關問題的展現。
8.GitHub使用Elasticsearch來檢索超過1300億行代碼。
0x10 Elasticsearch與Lucene的區別
Elasticsearch執行搜索的速度更快，可以簡單的通過HTTP方式，使用JSON來操作數據，並支持對分佈式集羣的搜索。
Elasticsearch對分佈式支持，其索引功能分拆爲多個分片，每個分片可有0個或多個副本，集羣中的每個數據節點都可承載一個或多個分片，並且能協調和處理各種操作；負載再平衡（Rebalancing）和路由
(Routing)在大多數情況下都是自動完成的。
Lucene只是一個庫。想要使用它，你必須使用Java來作爲開發語言並將其直接集成到你的應用中，更糟糕的是，Lucene非常複雜，你需要深入瞭解檢索的相關知識來理解它是如何工作的。
Elasticsearch也使用Java開發並使用Lucene作爲其核心來實現所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性，從而讓全文搜索變得簡單。
0x11 Elasticsearch與Solr的區別
比較總結：
1. 都是基於Lucene，且安裝都很簡單
2. Solr利用Zookeeper進行分佈式管理，而Elasticsearch自身帶有分佈式協調管理功能
3. Solr支持更多格式的數據，而Elasticsearch僅支持json格式
4. Solr官方提供功能較多，而Elasticsearch更注重核心功能，高級功能多由第三方插件提供
5. Solr在傳統的搜索應用中表現好於Elasticsearch，但Elasticsearch在實時搜索應用中效率更高
結論：
1. solr查詢快，但更新索引時慢（即插入刪除慢），用於電商等查詢多的應用；
2.ES建立索引快（即查詢慢），即實時性查詢快，用於facebook新浪等搜索。