剖析ElasticSearch核心概念，NRT，索引，分片，副本等

ElasticSearch 的核心概念

Near RealTime(NRT) 近實時

近實時有兩種意思，一種是從寫入數據到能夠被搜索到有一個小延遲（大概一秒），還有一種就是基於ElasticSearch 進行搜索和分析能夠達到秒級, 下圖來講明一下近實時的效果。

1. 首先咱們先使用Java向ElasticSearch存入一條數據，時間是 ** 2點16分20秒**     
2. 在使用一個Java程序從ElasticSearch裏面來讀取數據，那麼在讀取數據的時候這個時間的偏差應該保持在秒級，不管是這個集羣體系有多大，都應該保持這種速度，好比下面這個例子就是將時間延遲控制在了一秒。     
3. 這裏須要提到一下：實時又分爲準實時和近實時，準實時是毫秒級，近實時是秒級

Cluster 集羣

集羣裏面包含多個節點，每一個屬於那個集羣都是經過一個配置（集羣名稱，默認是elasticSearch）來決定的，對於中小型企業來講，剛開始一個集羣就一個節點很正常。

Node 節點

集羣裏面的一個節點，節點也有一個名稱，默認是隨機分配的，節點名稱很重要(在運維管理操做的時候)，每一個節點默認會去加入一個名叫 elasticsearch 的集羣, 若是直接啓動一堆節點，那麼他們會自動組成一個名爲 elasticsearch 的集羣, 固然一個節點也能夠組成一個 elasticsearch 集羣，只不過狀態是yellow(警告)，正常的狀態應該是green(正常)，這個在後面會詳細說明爲何會有yellow和green之分。

Document 文檔

es中最小的數據單元，它能夠是一條簡單的客戶數據，一條商品分類數據，一條訂單數據，一般用json結構表示，每一個index下的type中，均可以存儲多個document。下面就舉例一個簡單的商品document。

product document
{
    "product_name":"田園布藝沙發",
    "product_id":"1",
    "category_name": "沙發",
    "category_id": "2"
}

Type 類型 

一個type裏面能夠有不少個document，就至關於一個表裏面有條記錄是一個意思，在ElasticSearch6.0版本以前一個索引是能夠有多個type的，可是在6.0以後就只能有一個type了。在7.0事後將會徹底拋棄type，爲何type會慢慢的被ElasticSearch移除呢？咱們都把type比喻成一張表，把index比喻成數據庫，可是在數據庫裏面的表都是相互獨立的，各個字段之間互不影響，可是在ElasticSerarch中，多個type裏面若是有相同字段，那麼多個type就會同用同一個字段，也就是說他們並不會區分開來，因此後期就慢慢的將type潛移默化了。下面的例子將會展現document在type裏面是怎麼存儲的（這裏type和document的數據關係，並非表明es裏面數據結構就是這樣，這裏只是演示，瞭解就行）。

{
"type":[
    {
        "product_name":"田園布藝沙發",
        "product_id":"1",
        "category_name":"布藝沙發",
        "category_id":"2"
    },
    {
        "product_name":"田園實木沙發",
        "product_id":"2",
        "category_name":"實木沙發",
        "category_id":"3"
    }
]
}

index 索引

在6.0版本以前index裏面能夠存多個type，可是在6.0以後就只能存一個type了，這個type裏面又有不少的document。就像是下面這樣（這裏只是體現一個index和type還有document的數據關係，並非表明es裏面數據結構就是這樣，這裏只是演示，瞭解就行）          {     "index":{         "type":[             {                 "product_name":"田園布藝沙發",                 "product_id":"1",                 "category_name":"布藝沙發",                 "category_id":"2"             },             {                 "product_name":"田園實木沙發",                 "product_id":"2",                 "category_name":"實木沙發",                 "category_id":"3"             }         ]     }     }     

shards 分片

ElasticSearch 中特別重要的一個，先簡單介紹一下什麼是shards，它是一個數據的分片，這裏先大概說明一下，下面就來詳細解釋一下這個shards爲何重要了。

1. 如今咱們有這麼一個需求，要求將3T數據存儲在ES集羣中，可是咱們的每一個節點最大容量只有1T，這時候單臺服務器就容不下咱們的數據。     
2. 這個時候咱們就須要將這個3T的數據拆分紅3份存在3個節點上面（不要說這裏有6臺服務器，爲何不每臺服務器存500G呢，我不接受擡槓😄，開玩笑的啦，後面會解釋這剩餘3臺服務器的用處），那麼就能存下此次的數據了。這個時候就引出了shards的概念了，簡單來講就是index會被拆分爲多個shard（具體被拆分爲幾個shard是能夠配置的，後面再說），每一個shard存放了這個index的部分數據，而後這些shard會散落在多臺服務器上面。     
3. shard的好處，第一點，橫向擴展，好比說咱們數據量增長到了4T的時候，只須要增長一個節點，而後創建一個有4個shard的索引，在將以前的有3個shard的索引的數據倒過來就好了（倒數據很簡單，後面會介紹）。     
4. shard的第二點好處就是，數據分佈在多個shard上，多臺服務器上面全部的操做都會分佈在多臺服務器上面並行分佈式執行，提神吞吐量和性能，好比說若是隻有一個節點，那麼全部的請求過來了事後，全部的壓力都只有一臺服務器來承擔。舉例，若是如今單臺服務器承受的壓力只有2000，那麼4臺服務器就能夠承受8000的訪問量了。     

replica 分片副本

它的做用就是shard的備份，直接上例子，好比咱們的節點7宕機了，那麼這個節點上面的數據就丟失了沒法獲取該節點上面的數據，這個時候估計大家也猜到，replica的用處了，它就是shard的備份，若是某個主節點宕機了，那麼就會到節點的備份分片replica上面去查詢數據（replica的做用不只僅只有備份，還能夠提升吞吐量等等），一個replica存儲的數據和shard上是同樣的。

這個時候就能夠解釋爲何只有單臺服務器時集羣狀態的yellow的了，由於ElasticSearch不容許同一個索引額shard和replace出如今同一臺機器上面，由於這樣若是這臺機器宕機了，那麼就沒法獲取數據了，全部會爆出警告，最低(不發生警告)的集羣配置是2臺服務器，一臺存全部的shard，另外一臺出全部的replace，這就是replace的最重要的做用了。