ElasticSearch 是一個高可用開源全文檢索和分析組件。提供存儲服務，搜索服務，大數據準實時分析等。一般用于提供一些提供復雜搜索的應用。

ElasticSearch 提供了一套基于restful風格的全文檢索服務組件。前身是compass，直到2010被一家公司接管進行維護，開始商業化，并提供了ElasticSearch 一些相關的產品，包括大家比較熟悉的 kibana、logstash 以及ElasticSearch 的一些組件，比如安全組件shield 。當前最新的ElasticSearch 版本為 5.1.1 ，比較應用廣泛的為2.X，直到 2016-12 推出了5.x 版本，將版本號調為 5.X 。這是為了和 kibana 和 logstash 等產品版本號進行統一ElasticSearch 。我們將從以下幾個問題快速了解一些ElasticSearch索引服務器。

一、ES是如何產生背景

1、大規模數據如何檢索？

當系統數據量上了10億、100億條的時候，我們在做系統架構的時候通常會從以下角度去考慮問題：

1）用什么數據庫好？(MySQL、sybase、oracle、達夢、神通、mongodb、hbase…)

2）如何解決單點故障；(lvs、F5、A10、Zookeep、MQ)

3）如何保證數據安全性；(熱備、冷備、異地多活)

4）如何解決檢索難題；(數據庫代理中間件：mysql-proxy、Cobar、MaxScale等;)

5）如何解決統計分析問題；(離線、近實時)

2、傳統數據庫的應對解決方案

對于關系型數據，我們通常采用以下或類似架構去解決查詢瓶頸和寫入瓶頸：

1）通過主從備份解決數據安全性問題；

2）通過數據庫代理中間件心跳監測，解決單點故障問題；

3）通過代理中間件將查詢語句分發到各個slave節點進行查詢，并匯總結果

3、非關系型數據庫的解決方案

對于Nosql數據庫，基本原理類似：

1）通過副本備份保證數據安全性；

2）通過節點競選機制解決單點問題；

3）先從配置庫檢索分片信息，然后將請求分發到各個節點，最后由路由節點合并匯總結果

4、另辟蹊徑完全把數據放入內存怎么樣？

我們知道，完全把數據放在內存中是不可靠的，實際上也不太現實，當我們的數據達到PB級別時，按照每個節點96G內存計算，在內存完全裝滿的數據情況下，我們需要的機器是:1PB=1024T=1048576G 節點數=1048576/96=10922個實際上，考慮到數據備份，節點數往往在2.5萬臺左右。成本巨大決定了其不現實！

從前面討論我們了解到，把數據放在內存也好，不放在內存也好，都不能完完全全解決問題。全部放在內存速度問題是解決了，但成本問題上來了。為解決以上問題，從源頭著手分析，通常會從以下方式來尋找方法：

1、存儲數據時按有序存儲；

2、將數據和索引分離；

3、壓縮數據；這就引出了Elasticsearch

二、ES基礎知識

1、ES主要解決問題

1）檢索相關數據； 2）返回統計結果； 3）速度要快；

2、Lucene與ES關系

1） Lucene只是一個庫。想要使用它，你必須使用JAVA來作為開發語言并將其直接集成到你的應用中，更糟糕的是，Lucene非常復雜，你需要深入了解檢索的相關知識來理解它是如何工作的。

2） Elasticsearch也使用Java開發并使用Lucene作為其核心來實現所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的復雜性，從而讓全文搜索變得簡單。

3、ES工作原理

當ElasticSearch的節點啟動后，它會利用多播(multicast)(或者單播，如果用戶更改了配置)尋找集群中的其它節點，并與之建立連接。這個過程如下圖所示：

4、ES的基本概念

1）近實時查詢（Near RealTime）

Elasticsearch 是一個能提供近實時查詢的搜索服務引擎，這意味著從索引文檔到真正可搜索之間會有一個輕微的延遲（大概在一秒內）。

2）節點和集群

節點(node)是一個運行著的 Elasticsearch 實例，你可以認為是單個服務器。集群(cluster)是一個或多個節點的集合，他們協同工作，共享數據并提供故障轉移和擴展功能。集群由唯一名稱標識，如 .NET Core 中的環境名稱，推薦在不同的環境中使用諸如 Development，Production 之類的名稱部署開發。其實節點和集群就是 web 開發中的常見概念而已，大家注意區分即可。

3）文檔

文檔是可索引信息的基本單元，以JSON表示。你可以用其來定義單個產品信息或是員工信息。我們可以把文檔理解為數據庫文檔中的行列數據。在索引/類型中，您可以存儲任意數量的文檔。文檔有幾個共同不可缺的屬性，分別為 _index, _type, _id, 針對特定一個或一類文檔進行操作時，必須指定這些屬性。最后要提醒大家的是，雖然文檔物理上是駐留在索引中，但實際上文檔必須索引/分配給索引中的類型。

4）索引

索引是具有某些相似特征的文檔的集合，它和數據庫中的索引概念并不十分相同。我們可以把索引理解為數據庫文檔中的數據庫。事實上，我們的數據被存儲和索引在分片(shards)中，索引只是一個把一個或多個分片分組在一起的邏輯空間。然而，這只是一些內部細節——我們的程序完全不用關心分片。

5）類型

在索引中，我們可以定義一個或多個類型。類型是索引的邏輯類別/分區，其語義完全由開發者決定。通常，為具有一組公共字段的文檔定義類型。例如，假設開發者運行博客平臺并將所有數據存儲在一個索引中。在此索引中，我們可以為用戶數據定義類型，為博客數據定義另一種類型，并為注釋數據定義另一種類型。我們可以把索引理解成數據庫文檔中的表。

6）分片和復制

理論上，索引可以存儲盡可能多的數據，但是這種情況下性能往往不太樂觀，或者常見的磁盤容量限制也不能允許。所以 Elasticsearch 提供了類似于 MongoDB 中的分片功能，該功能能將索引細分為多個分片。每個分片本身是一個功能完全和獨立的"索引"，可以托管在集群中的任何節點上。

同樣的，有分片技術來處理數據量增長快速的問題，就意味著需要復制技術來應對這種過程中（其實不只是該過程，任何情況下都應該有安全意識）數據安全的問題。Elasticsearch 允許您將索引分片的一個或多個副本轉換為所謂的副本分片。復制技術為我們提供了數據的高可用性和搜索吞吐的擴展性。不過需要注意的是，副本分片從不分配在與從其復制的原始/主分片相同的節點上。

總而言之，每個索引可以拆分為多個分片。索引也可以復制為零（意味著沒有副本）或更多次。一旦復制，每個索引將具有主分片（從索引復制的原始分片）和副本分片（主分片的副本）。開發者可以在創建索引時就為每個索引定義分片和副本的數量。創建索引后，可以隨時動態更改副本數，但不能在此過程后隨即更改分片數。