一文掌握Elasticsearch的核心概念

一、近實時

Near Realtime，也稱NRT。這裏包含兩個含義

• 從數據寫入到能被搜索到這個全過程會有1s左右的延遲
• 直接檢索和分析海量數據，可以達到秒級。小數據量肯定毫秒級
  

二、天然支持集羣

一個集羣包含多個node（節點，至少兩個，否則不叫集羣），每個節點屬於哪個集羣是通過一個配置（集羣名稱，默認是elasticsearch）來決定的。啓動多個es實例就自動構成一個集羣。它默認會找9300-9305這端口範圍的實例，官方有寫：

https://www.elastic.co/guide/en/elasticsearch/reference/current/discovery-settings.html

三、Node

Node：節點。多個Node湊成一個集羣，我理解每個Elasticsearch實例就是一個Node。

四、field

就是字段，一個document裏可包含多個field，看完下面的document就明白了。

五、Document

文檔，ES中的最小數據單元，通常用JSON表示，理解成mysql裏的一條數據。

{
    "id": 1,
    "name": "小米",
    "price": {
        "型號1": 999,
        "型號2": 1999,
        "型號3": 2999
    }
}

六、index

索引，包含一堆有相似結構的文檔數據。舉個例子：商品索引、用戶索引這是兩個完全不同的東西，所以建議弄兩個index。 可以粗糙理解成mysql的庫的概念。有點模糊？看完下面的type就懂了。

七、type

每個index下的具體分類。一個index可以有多個type。比如上面index舉例的商品索引，下面可以包含家電商品、生鮮商品、生活用品等，可以粗糙理解成mysql表的概念。

八、小結以及注意

Index理解成數據庫、type理解成數據表、document理解成數據行。一個index下有多個type，每個type下有多個document。
Elasticsearch已經將type這個概念去掉了，也就是隻有index和document的概念，相當於index就對應到mysql的庫表。
因爲type的概念是錯誤的使用方式，畢竟在RDBMS中，表與表之間的數據是分割存儲的，而ES中同一個索引的不同type數據最終是放在一起的，必須保證不同type之間同名field的類型一致，還不算其他亂七八糟的問題。設計上就不合理。

九、shard

分爲兩種：Primary Shard以及Replica Shard。

• 每個shard都可以理解成是一個lucene實例，負責搜索分析和倒排索引。
• 1個index默認包含5個Primary Shard和1個Replica Shard（這裏的1個每個PrimaryShard都對應1個ReplicaShard），所以默認1個index一共有10個shard，5P5R。
• Replica Shard就是副本shard，理解成“從節點”。防止單點故障，減輕PrimaryShard的壓力。
• Primary Shard的數量是創建index的時候設置的，如果後期想更改需要重建索引，代價很大。Replica Shard可以隨時修改數量。
• 一個document的數據只能落到一個Primary上，但是可能落到多個Replica上
• ES會自動在nodes上爲我們做shard的負載均衡。

假設只有1個index，每個index默認5P5R。假設只有一臺node，那肯定這10個shard都在這一臺node上，假設新增了一臺node實例與之前的湊成了集羣。那麼ES會自動將這個shard平分到兩臺node上，比如：
Anode：2個PrimaryShard+3個ReplicaShard（這3個是Bnode中3P的副本，這樣可以保證高可用）
Bnode：3個PrimaryShard+2個ReplicaShard（這2個是Anode中2P的副本，這樣可以保證高可用）

• 實現最小高可用的node至少需要2個。

Primary和Replica不能同時存到同一個node上，否則這個node掛了就單點故障了 ，不叫高可用。