1 Elasticsearch¶

在如今數據為王的時代，如何充分高效實現數據檢索和分析是數據應用的關鍵。以電商平台為例，輸入一個商品名稱，那么就要求系統以最快的速度將所有相關的商品搜索處理。現在的數據大多存儲在mysql、Oracle或其他企業自主研發的關系型數據庫中，搜索能力已經逐漸跟不上實際需求。例如需要檢索“格力空調”這個商品，那么，按照關系型數據庫中的邏輯，sql語句大概應該是這樣的：

select * from table where name like "%格力空調%"

注意，因為sql語句中使用了模糊查詢，而且在“格力空調”這個關鍵詞前面也使用了通配符，所以索引將會失效，這將倒是檢索性能大大降低。

另外，我們必須承認，有時候，我們會將關鍵詞輸入錯誤，例如將“格力空調”輸入成了“格空調”，那么這時候SQL語句將變成這樣：

select * from table where name like "%格空調%"

可想而知，我們查詢不出任何真正相關的結果。

另一方面，雖然目前的主流數據庫都已經能夠很好的支持分布式擴展，但通常需要對應用程序進行非常大的改動，才能利用上橫向擴容的新增資源。

這就是目前關系型數據庫在實際應用中的一些局限性。為了解決這些問題，Elasticsearch應運而生。

Elasticsearch 是一個分布式的 RESTful 風格的分布式可擴展的准實時搜索和分析引擎，一個建立在全文搜索引擎 Apache Lucene(TM) 基礎上的搜索引擎.當然 Elasticsearch 並不僅僅是 Lucene 那么簡單，它不僅包括了全文搜索功能（或者說倒排索引，將一段詞語進行分詞，並且將分出的單個詞語統一的放到一個分詞庫中，在搜索時，根據關鍵字去分詞庫中檢索，找到匹配的內容），還可以進行以下工作:

分布式實時文件存儲，並將每一個字段都編入索引，使其可以被搜索。
實時分析的分布式搜索引擎。
可以通過極其簡單配置擴展到上百台服務器實現分布式橫向擴容，處理PB級別的結構化或非結構化數據。

2 核心概念理解¶

2.1 索引（index）¶

在elasticsearch中，索引有兩種含義：

一種是名詞意義上的索引。我們通常所說的索引也大多指這一種，這時候的索引就是文檔(Document)的容器，是具有某種相似特性文檔的集合，所以，在設計elasticsearch時，通常將相似的文檔存放在同一個索引中（當然，個別document可能多一個或少一個field），這樣Elasticsearch對磁盤存儲的利用率最高。例如，對於博客類系統，可以將文章（artical）存放為一個索引中，將作者（author）存放為一個索引。索引由一個名稱（必須全部是小寫，不能以'_', '-', 或 '+'開頭）標識，當對其中的文檔執行索引、搜索、更新和刪除操作時，該名稱用於引用索引。通常索引是由兩部分構成：Mapping和Setting。Mapping 定義該索引包含的文檔的數據結構的信息；Setting定義了該索引的數據分布信息。
另一種索引是指動詞意義上的索引。保存一個文檔到索引(名詞)的過程，就類似於SQL語句中的 INSERT關鍵詞，當然，如果文檔已存在，那就相當於數據庫的UPDATE。

2.2 類型（type）¶

就目前7.X版本的ES來說，再談類型（type）的概念已經不是太有意義，因為類型的概念正在被逐漸淡化拋棄。

在5.X或者更早的版本中，類型的概念確實很常用，類型是索引內部的邏輯分區(category/partition)，然而其意義完全取決於用戶需求。因此，一個索引內部可定義一個或多個類型(type)。一般來說，類型就是為那些擁有相同的域的文檔做的預定義。例如，在一個博客系統類的索引中，可以定義一個用於存儲作者信息的類型，一個存儲博客文章信息的類型，以及一個存儲評論數據的類型。類比傳統的關系型數據庫領域來說，類型相當於“表”。

然而，從6.X開始單個索引中只能有一個類型，7.X的版本中只存在一個默認的名為“_doc”的類型，官方也不建議繼續使用這一概念，甚至8.X以后完全不支持。這是為什么呢？

許多資料指出ES中“索引”的概念和關系數據庫的“庫”是相似的，“類型”和“表”是對等的。這其實是一個不正確的對比，掩蓋了一些基礎的特性。在關系型數據庫里,"表"是相互獨立的,一個“表”里的列和另外一個“表”的同名列沒有關系，互不影響。但在類型里字段不是這樣的。在一個ES索引里，所有不同類型的同名字段內部使用的是同一個lucene字段存儲。也就是說，上面例子中，作者信息類型的author_name字段和博客文章信息類型的author_name字段是存儲在一個字段里的，兩個類型里的這一字段必須有一樣的字段定義。這可能導致一些問題，例如我們希望在類型1中的phone_number存儲為數值類型，而在類型2中的phone_number字段存儲為字符類型，這是不可能做到的。另外，在同一個索引中，存儲僅有小部分字段相同或者全部字段都不相同的文檔，會導致數據稀疏，影響Lucene有效壓縮數據的能力。

所以，在一個索引中，最好只擁有一個類型，如果有多種實體數據，那就分別存儲在多個索引中。

2.3 文檔（document）¶

在索引中存儲的每一個目標數據稱為文檔，ES中的文檔可以類比關系型數據庫中的每一行記錄來理解。ES是面向文檔的搜索，文檔是ES所有可搜索數據的最小單元。在ES中文檔會被序列化成json格式進行保存，每個文檔都會有一個Unique ID，這個ID可以有用戶在創建文檔的時候指定，在用戶未指定時則由ES自己生成，這個ID中在查詢結果中以_id這個元數據表示。除了_id外，文檔中還包括一下這些元數據：

_index：文檔所屬索引名稱。
_type：文檔所屬類型名。
_id：文檔的ID值。
_version：文檔的版本信息。ES通過使用version來保證對文檔的變更能以正確的順序執行，避免亂序造成的數據丟失。
_seq_no：嚴格遞增的順序號，每個文檔一個，Shard級別嚴格遞增，保證后寫入的Doc的_seq_no大於先寫入的Doc的_seq_no。
primary_term：primary_term也和_seq_no一樣是一個整數，每當Primary Shard發生重新分配時，比如重啟，Primary選舉等，_primary_term會遞增1
found：查詢的ID正確那么ture, 如果 Id 不正確，就查不到數據，found字段就是false。
_source：文檔的原始JSON數據，這才是我們儲存在ES中的業務數據。

2.4 映射（mapping）¶

ES中中的映射（Mapping）用來定義一個文檔，類似於關系型數據庫中的表結構的概念，但卻比表結構具有更加強大的功能，如下圖所示，具體來說主要包含以下功能：

文檔中哪些字段需要定義成全文索引字段。
文檔中哪些字段定義為精確值，例如日期，數字、地理位置等。
文檔中哪些字段需要被索引（能通過該字段的值查詢文檔）。
日期值的格式。
動態添加字段的規則定義等。

映射可以分為動態映射和靜態映射：

靜態映射：若在數據寫入索引前，映射（mapping）已經創建，那么在寫入數據時，ES會根據映射和寫入數據的key進行對比，然后寫入相應的映射中；

動態映射：如果mapping沒有創建，elasticsearch將會根據寫入的數據的key自行創建相應的mapping，並寫入數據。

2.5 集群（cluster）¶

集群是一個或多個節點(服務器)的集合，它們共同保存你的整個數據，並提供跨所有節點的聯合索引和搜索功能。一個集群由一個唯一的名稱標識，默認這個唯一標識的名稱是"elasticsearch"（可修改）。這個名稱很重要，因為如果節點被設置為按其名稱加入集群，那么節點只能是集群的一部分。

注意，在同一環境中用最好使用不同的集群名稱，否則可能導致節點加入到錯誤的集群中。例如，你可以使用"logging-dev", "logging-test", "logging-prod"分別用於開發、測試和正式集群的名字。

ES集群實際上是一個分布式系統，這是ES的一大優勢，它需要具備兩個特性：

　　1）高可用性

　　　　a）服務可用性：允許有節點停止服務；

　　　　b）數據可用性：部分節點丟失，不會丟失數據；

　　2）可擴展性

　　　　隨着請求量的不斷提升，數據量的不斷增長，系統可以將數據分布到其他節點，實現水平擴展；

ES集群有三種健康狀態：

green：所有主要分片和復制分片都可用
yellow：所有主要分片可用，但不是所有復制分片都可用
red：不是所有的主要分片都可用

我們可以通過查詢語句對健康狀態進行查詢，關注和提升ES集群的健康狀態對保證數據安全性、高效查詢十分有必要。

2.6 節點（node）¶

節點是一個ElasticSearch的實例，其本質就是一個Java進程，負責進行數據存儲，並且參與集群的索引和搜索功能；一台機器上可以運行多個ElasticSearch實例，但是建議在生產環境中一台機器上只運行一個ElasticSearch實例。

與集群一樣，節點由一個名稱標識，默認情況下，該名稱是在啟動時分配給節點的隨機通用唯一標識符（UUID）。如果不希望使用默認值，則可以定義所需的任何節點名稱。

一個集群可以有任意數量的節點。此外，如果在網絡上當前沒有運行任何節點，那么此時啟動一個節點將默認形成一個單節點的名字叫"elasticsearch"的集群。一個節點可以通過配置集群名稱來加入到一個特定的集群中。默認情況下，每個節點都被設置加入到一個名字叫"elasticsearch"的集群中，這就意味着如果你啟動了很多個節點，並且假設它們彼此可以互相發現，那么它們將自動形成並加入到一個名為"elasticsearch"的集群中。

在一個ES的集群中包含着多個ES的節點，往往每個節點所扮演的角色也不盡相同，ES的節點類型主要包含以下幾類：

Master-eligible Node：每個節點啟動后，默認是一個 Master-eligible 節點，Master-eligible的節點可參加選主流程，成為Master節點，通過配置項 node.master:falase 可以禁用節點的Master-eligible職責，禁止后當前節點就不會參加選主流程；
Master Node：ES集群中雖然每個節點都保存了集群狀態，但是只有Master節點才有修改集群狀態的權限，集群狀態包括：集群中節點信息、所有索引和其相關的Mapping和Setting信息、分片的路由信息。在集群啟動時，第一個啟動的Master-eligible節點會將自己選舉為主節點；
Data Node：保存數據的節點，負責保存分片數據，對數據擴展有重要作用；
Coordinating Node：負責接受Client請求，將請求分發到合適的節點獲取響應后，將結果最終匯集在一起，每個節點默認都有Coordinating節點的職責；
Machine Learning Node：負責運行機器學習的Job，用來做異常檢測；
Ingest Node：數據預處理的節點，支持Pipeline管道設置，可以使用Ingest對數據進行過濾、轉換等操作。

注意，每個ES節點可以承擔多個職責。

2.7 分片（shard）¶

ES的shard（分片）機制可將一個索引內部的數據分布地存儲於多個節點，它通過將一個索引切分為多個底層物理的Lucene索引完成索引數據的分割存儲功能，這每一個物理的Lucene索引稱為一個分片(shard)。每個分片其內部都是一個全功能且獨立的索引，因此可由集群中的任何主機存儲。創建索引時，用戶可指定其分片的數量，默認數量為5個。

Shard有兩種類型：primary和replica，即主分片及副本分片。主分片用於文檔存儲，每個新的索引會自動創建5個主分片，當然此數量可在索引創建之前通過配置自行定義，不過，一旦創建完成，其主分片的數量將不可更改。Replica分片是主分片的副本，用於冗余數據及提高搜索性能，為保證副本分片的有效性，主分片絕不會被創建在同一節點上。每個主分片默認配置了一個副本，但也可以配置多個，且其數量可動態更改。ES會根據需要自動增加或減少這些Replica shard的數量。

ES集群可由多個節點組成，各分片分布式地存儲於這些節點上。ES可自動在節點間按需要移動分片，例如增加節點或節點故障時。簡而言之，分片實現了集群的分布式存儲，而副本實現了其分布式處理及冗余功能。