elasticsearch專欄：https://www.cnblogs.com/hello-shf/category/1550315.html

一、elasticsearch背後有趣的故事

許多年前，一個剛結婚的名叫 Shay Banon 的失業開發者，跟著他的妻子去了倫敦，他的妻子在那裡學習廚師。 在尋找一個賺錢的工作的時候，為了給他的妻子做一個食譜搜尋引擎，他開始使用 Lucene 的一個早期版本。直接使用 Lucene 是很難的，因此 Shay 開始做一個抽象層，Java 開發者使用它可以很簡單的給他們的程式新增搜尋功能。 他釋出了他的第一個開源專案 Compass。後來 Shay 獲得了一份工作，主要是高效能，分散式環境下的記憶體資料網格。這個對於高效能，實時，分散式搜尋引擎的需求尤為突出， 他決定重寫 Compass，把它變為一個獨立的服務並取名 Elasticsearch。第一個公開版本在2010年2月釋出，從此以後，Elasticsearch 已經成為了 Github 上最活躍的專案之一，他擁有超過300名 contributors(目前736名 contributors )。 一家公司已經開始圍繞 Elasticsearch 提供商業服務，並開發新的特性，但是，Elasticsearch 將永遠開源並對所有人可用。

二、elasticsearch簡介

Elasticsearch 是一個開源的搜尋引擎，建立在一個全文搜尋引擎庫 Apache Lucene™ 基礎之上。 Lucene 可以說是當下最先進、高效能、全功能的搜尋引擎庫--無論是開源還是私有。但是 Lucene 僅僅只是一個庫。為了充分發揮其功能，你需要使用 Java 並將 Lucene 直接整合到應用程式中。 更糟糕的是，您可能需要獲得資訊檢索學位才能瞭解其工作原理。Lucene 非常 複雜。Elasticsearch 也是使用 Java 編寫的，它的內部使用 Lucene 做索引與搜尋，但是它的目的是使全文檢索變得簡單， 通過隱藏 Lucene 的複雜性，取而代之的提供一套簡單一致的 RESTful API。然而，Elasticsearch 不僅僅是 Lucene，並且也不僅僅只是一個全文搜尋引擎。 它可以被下面這樣準確的形容：

1 一個分散式的實時文件儲存，每個欄位 可以被索引與搜尋
2 一個分散式實時分析搜尋引擎
3 能勝任上百個服務節點的擴充套件，並支援 PB 級別的結構化或者非結構化資料

2.1、elasticsearch功能

　　1，分散式的搜尋引擎

es可作為一個分散式的搜尋引擎，例如百度，淘寶的商品搜尋，一般web系統的站內搜尋，es都是不錯的技術選型。

　　2，資料分析引擎

es在搜尋的基礎上提供了豐富的API支援個性化的搜尋和資料分析功能，比如電商網站，我們可以查詢最近幾天的熱銷商品等。

　　3，對海量資料進行近實時的處理

es是一個分散式的搜尋引擎，es通過叢集和內部分片可以將海量資料分散到多臺伺服器上進行儲存和檢索，大大提高了其可伸縮性和容災能力。

所謂近實時是一個相對的概念，一般的如果相應速度能達到秒級別，我們就稱為其實近實時的。es的近實時包括兩個方面：其一寫入的資料在1s後就可以進行檢索。其二其檢索和分析響應速度可以達到秒級別。

2.2、elasticsearch的特點

　　1，分散式

es是一個分散式的搜尋引擎，可以很好的進行資料的容災遷移，動態擴容，負載均衡等分散式特性。

　　2，海量資料

es能處理PB級別的資料，因為es是一個分散式的架構，支援動態擴容，所以對於海量資料的處理和儲存都不再是問題。

三、elasticsearch的幾個基礎概念

1，es中資料的基礎概念

　　index：

索引(index)類似於關係型資料庫裡的“資料庫”——它是我們儲存和索引關聯資料的地方。

提示：
    事實上，我們的資料被儲存和索引在分片(shards)中，索引只是一個把一個或多個分片分組在一起的邏輯空間。然而，這只是一些內部細節——我們的程式完全不用關心分 片。對於我們的程式而言，文件儲存在索引(index)中。
剩下的細節由Elasticsearch關心 既可。

　　type：

type的概念類似於MySql中表的概念。

在應用中，我們使用物件表示一些“事物”，例如一個使用者、一篇部落格、一個評論，或者一封郵 件。每個物件都屬於一個類(class)，這個類定義了屬性或與物件關聯的資料。 user 類的物件 可能包含姓名、性別、年齡和Email地址。 在關係型資料庫中，我們經常將相同類的物件儲存在一個表裡，因為它們有著相同的結構。 同理，在Elasticsearch中，我們使用相同型別(type)的文件表示相同的“事物”，因為他們的數 據結構也是相同的。 每個型別(type)都有自己的對映(mapping)或者結構定義，就像傳統資料庫表中的列一樣。所 有型別下的文件被儲存在同一個索引下，但是型別的對映(mapping)會告訴Elasticsearch不同 的文件如何被索引。 我們將會在《對映》章節探討如何定義和管理對映，但是現在我們將依 賴Elasticsearch去自動處理資料結構。

　　document：

document是es的基本索引單元，document類似於MySql中的一行記錄。document的資料是json格式。

　　id：

在MySql中我們使用主鍵表示一條記錄的唯一性，在es中id就是這種概念。在es中id同樣可以是自產生的，es自動生成的ID具備以下特點：自動生成的是 url安全的，base64編碼，GUID，保證分散式下ID不衝突（全域性唯一ID）。當然也可以我們自己來指定。

2，es在分散式下的幾個概念

　　Cluster（叢集）：

相信熟悉分散式的小夥伴對這個Cluster都不會陌生，Cluster表示es的一個叢集，所謂叢集就是有好多es組合成的一個分散式下的es叢集。

　　node（節點）：

node就是es叢集（Cluster）中的一個es節點就稱為node。簡單來說可以理解成一個es例項就是該叢集中的一個節點。

3，es儲存策略上的兩個概念

　　shard（分片）和 replica：

為了將資料新增到Elasticsearch，我們需要索引(index)——一個儲存關聯資料的地方。實際 上，索引只是一個用來指向一個或多個分片(shards)的“邏輯名稱空間(logical namespace)”. 一個分片(shard)是一個最小級別“工作單元(worker unit)”,它只是儲存了索引中所有資料的一 部分。道分片就是一個Lucene例項，並且它本身就是一個完整的搜尋引擎。我們的文件儲存在分片中，並且在分片中被索引，但是我們的應用程式不會直接與它們通訊，取而代之的是，直接與索引通訊。 分片是Elasticsearch在叢集中分發資料的關鍵。把分片想象成資料的容器。文件儲存在分片中，然後分片分配到你叢集中的節點上。當你的叢集擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使叢集保持平衡。 分片可以是主分片(primary shard)或者是複製分片(replica shard)。

你索引中的每個文件屬於一個單獨的主分片，所以主分片的數量決定了索引最多能儲存多少資料。 理論上主分片能儲存的資料大小是沒有限制的，限制取決於你實際的使用情況。分片的最大容量完全取決於你的使用狀況：硬體儲存的大小、文件的大小和複雜度、如何索引 和查詢你的文件，以及你期望的響應時間。

複製分片只是主分片的一個副本，它可以防止硬體故障導致的資料丟失，同時可以提供讀請 求，比如搜尋或者從別的shard取回文件。 當索引建立完成的時候，主分片的數量就固定了，但是複製分片的數量可以隨時調整。 預設情況下，一個索引被分配5個主分片，一個主分片預設只有一個複製分片。

重點：
shard分為兩種：
    1，primary shard --- 主分片
    2，replica shard --- 複製分片（或者稱為備份分片或者副本分片）

需要注意的是，在業界有一個約定俗稱的東西，單說一個單詞shard一般指的是primary shard，而單說一個單詞replica就是指的replica shard。

另外一個需要注意的是replica shard是相對於索引而言的，如果說當前index有一個複製分片，那麼相對於主分片來說就是每一個主分片都有一個複製分片，即如果有5個主分片就有5個複製分片，並且主分片和複製分片之間是一一對應的關係。

很重要的一點：primary shard不能和replica shard在同一個節點上。重要的事情說三遍：

primary shard不能和replica shard在同一個節點上

primary shard不能和replica shard在同一個節點上

primary shard不能和replica shard在同一個節點上

所以es最小的高可用配置為兩臺伺服器。 

四、elasticsearch的安裝和開發工具

本人安裝的是elasticsearch-6.6.2版本

開發工具：kibana-6.6.2（注意kibana的版本一定要和elasticsearch的版本一致）

另外本地還配置了另一個開發工具：elasticsearch-head

安裝方式，大家去百度一下，有很多很詳細的安裝步驟，在這裡就不在贅述了。

簡單貼一張圖關於如何在kibana中執行curl

四、叢集健康狀態

Elasticsearch 的叢集監控資訊中包含了許多的統計資料，其中最為重要的一項就是叢集健康，它在 status 欄位中展示為 green 、 yellow 或者 red。

在kibana中執行：GET /_cat/health?v

1 epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
2 1568794410 08:13:30  my-application yellow          1         1     47  47    0    0       40             0                  -                 54.0%

其中我們可以看到當前我本地的叢集健康狀態是yellow ，但這裡問題來了，叢集的健康狀況是如何進行判斷的呢？

green（很健康）
    所有的主分片和副本分片都正常執行。
yellow（亞健康）
    所有的主分片都正常執行，但不是所有的副本分片都正常執行。
red（不健康）
    有主分片沒能正常執行。

 注意：

我本地只配置了一個單節點的elasticsearch，因為primary shard和replica shard是不能分配到一個節點上的所以，在我本地的elasticsearch中是不存在replica shard的，所以健康狀況為yellow。

　　參考文獻：

　　《elasticsearch-權威指南》

　　如有錯誤的地方還請留言指正。

　　原創不易，轉載請註明原文地址：https://www.cnblogs.com/hello-shf/p/11393655.html 

&n