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 將永遠開源並對所有人可用。
據說，Shay 的妻子還在等着她的食譜搜索引擎…
二、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