ELK學習筆記之ElasticSearch簡介

 

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新浪等搜索。