elasticsearch入門篇

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

1、elasticsearch背後有趣的故事

許多年前，一個剛結婚的名叫 Shay Banon 的失業開發者，跟着他的妻子去了倫敦，他的妻子在那裏學習廚師。 在尋找一個賺錢的工做的時候，爲了給他的妻子作一個食譜搜索引擎，他開始使用 Lucene 的一個早期版本。直接使用 Lucene 是很難的，所以 Shay 開始作一個抽象層，Java 開發者使用它能夠很簡單的給他們的程序添加搜索功能。 他發佈了他的第一個開源項目 Compass。後來 Shay 得到了一份工做，主要是高性能，分佈式環境下的內存數據網格。這個對於高性能，實時，分佈式搜索引擎的需求尤其突出， 他決定重寫 Compass，把它變爲一個獨立的服務並取名 Elasticsearch。第一個公開版本在2010年2月發佈，今後之後，Elasticsearch 已經成爲了 Github 上最活躍的項目之一，他擁有超過300名 contributors(目前736名 contributors )。 一家公司已經開始圍繞 Elasticsearch 提供商業服務，並開發新的特性，可是，Elasticsearch 將永遠開源並對全部人可用。
聽說，Shay 的妻子還在等着她的食譜搜索引擎…

 

2、elasticsearch簡介

Elasticsearch 是一個開源的搜索引擎，創建在一個全文搜索引擎庫 Apache Lucene™ 基礎之上。 Lucene 能夠說是當下最早進、高性能、全功能的搜索引擎庫--不管是開源仍是私有。可是 Lucene 僅僅只是一個庫。爲了充分發揮其功能，你須要使用 Java 並將 Lucene 直接集成到應用程序中。 更糟糕的是，您可能須要得到信息檢索學位才能瞭解其工做原理。Lucene 很是 複雜。Elasticsearch 也是使用 Java 編寫的，它的內部使用 Lucene 作索引與搜索，可是它的目的是使全文檢索變得簡單， 經過隱藏 Lucene 的複雜性，取而代之的提供一套簡單一致的 RESTful API。然而，Elasticsearch 不只僅是 Lucene，而且也不只僅只是一個全文搜索引擎。 它能夠被下面這樣準確的形容：

1 一個分佈式的實時文檔存儲，每一個字段 能夠被索引與搜索
2 一個分佈式實時分析搜索引擎
3 能勝任上百個服務節點的擴展，並支持 PB 級別的結構化或者非結構化數據

 

2.一、elasticsearch功能

　　1，分佈式的搜索引擎

es可做爲一個分佈式的搜索引擎，例如百度，淘寶的商品搜索，通常web系統的站內搜索，es都是不錯的技術選型。

　　2，數據分析引擎

es在搜索的基礎上提供了豐富的API支持個性化的搜索和數據分析功能，好比電商網站，咱們能夠查詢最近幾天的熱銷商品等。

　　3，對海量數據進行近實時的處理

es是一個分佈式的搜索引擎，es經過集羣和內部分片能夠將海量數據分散到多臺服務器上進行存儲和檢索，大大提升了其可伸縮性和容災能力。

所謂近實時是一個相對的概念，通常的若是相應速度能達到秒級別，咱們就稱爲其實近實時的。es的近實時包括兩個方面：其一寫入的數據在1s後就能夠進行檢索。其二其檢索和分析響應速度能夠達到秒級別。

 

2.二、elasticsearch的特色

　　1，分佈式

es是一個分佈式的搜索引擎，能夠很好的進行數據的容災遷移，動態擴容，負載均衡等分佈式特性。

　　2，海量數據

es能處理PB級別的數據，由於es是一個分佈式的架構，支持動態擴容，因此對於海量數據的處理和存儲都再也不是問題。

 

3、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最小的高可用配置爲兩臺服務器。 

 

4、elasticsearch的安裝和開發工具

本人安裝的是elasticsearch-6.6.2版本

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

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

安裝方式，你們去百度一下，有不少很詳細的安裝步驟，在這裏就不在贅述了。

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

 

4、集羣健康狀態

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