Elasticsearch(4)--- 基本概念(Index、Type、Document、集羣、節點、分片及副本、倒排索引)

#<center> Elasticsearch核心技術(2)--- 基本概念</center>node

這篇博客講到基本概念包括: Index、Type、Document。集羣，節點，分片及副本，倒排索引。數據庫

## 1、Index、Type、Document服務器

一、Index

index：索引是文檔(Document)的容器，是一類文檔的集合。分佈式

索引這個詞在 ElasticSearch 會有三種意思:性能

1)、索引(名詞)ui

類比傳統的關係型數據庫領域來講，索引至關於SQL中的一個數據庫(Database)。索引由其名稱(必須爲全小寫字符)進行標識。搜索引擎

2)、索引(動詞)url

保存一個文檔到索引(名詞)的過程。這很是相似於SQL語句中的 INSERT關鍵詞。若是該文檔已存在時那就至關於數據庫的UPDATE。spa

3)、倒排索引.net

關係型數據庫經過增長一個B+樹索引到指定的列上，以便提高數據檢索速度。索引ElasticSearch 使用了一個叫作 倒排索引 的結構來達到相同的目的。

二、Type

Type 能夠理解成關係數據庫中Table。

以前的版本中，索引和文檔中間還有個類型的概念，每一個索引下能夠創建多個類型，文檔存儲時須要指定index和type。從6.0.0開始單個索引中只能有一個類型，

7.0.0之後將將不建議使用，8.0.0 之後徹底不支持。

棄用該概念的緣由：

咱們雖然能夠通俗的去理解Index比做 SQL 的 Database，Type比做SQL的Table。但這並不許確，由於若是在SQL中,Table 以前相互獨立，同名的字段在兩個表中毫無關係。

可是在ES中，同一個Index 下不一樣的 Type 若是有同名的字段，他們會被 Luecence 看成同一個字段，而且他們的定義必須相同。因此我以爲Index如今更像一個表，

而Type字段並無多少意義。目前Type已經被Deprecated，在7.0開始，一個索引只能建一個Type爲_doc

三、Document

Document Index 裏面單條的記錄稱爲Document（文檔）。等同於關係型數據庫表中的行。

咱們來看下一個文檔的源數據

_index 文檔所屬索引名稱。

_type 文檔所屬類型名。

_id Doc的主鍵。在寫入的時候，能夠指定該Doc的ID值，若是不指定，則系統自動生成一個惟一的UUID值。

_version 文檔的版本信息。Elasticsearch經過使用version來保證對文檔的變動能以正確的順序執行，避免亂序形成的數據丟失。

_seq_no 嚴格遞增的順序號，每一個文檔一個，Shard級別嚴格遞增，保證後寫入的Doc的_seq_no大於先寫入的Doc的_seq_no。

primary_term primary_term也和_seq_no同樣是一個整數，每當Primary Shard發生從新分配時，好比重啓，Primary選舉等，_primary_term會遞增1

found 查詢的ID正確那麼ture, 若是 Id 不正確，就查不到數據，found字段就是false。

_source 文檔的原始JSON數據。

## 2、集羣，節點，分片及副本

一、集羣

ElasticSearch集羣其實是一個分佈式系統，它須要具有兩個特性：

　　1）高可用性

　　　　a）服務可用性：容許有節點中止服務；

　　　　b）數據可用性：部分節點丟失，不會丟失數據；

　　2）可擴展性

　　　　隨着請求量的不斷提高，數據量的不斷增加，系統能夠將數據分佈到其餘節點，實現水平擴展；

一個集羣中能夠有一個或者多個節點；

集羣健康值

green：全部主要分片和複製分片均可用
yellow：全部主要分片可用，但不是全部複製分片均可用
red：不是全部的主要分片均可用

當集羣狀態爲 red，它仍然正常提供服務，它會在現有存活分片中執行請求，咱們須要儘快修復故障分片，防止查詢數據的丟失；

二、節點(Node)

　1）節點是什麼？

　　　　a）節點是一個ElasticSearch的實例，其本質就是一個Java進程；

　　　　b）一臺機器上能夠運行多個ElasticSearch實例，可是建議在生產環境中一臺機器上只運行一個ElasticSearch實例；

Node 是組成集羣的一個單獨的服務器，用於存儲數據並提供集羣的搜索和索引功能。與集羣同樣，節點也有一個惟一名字，默認在節點啓動時會生成一個uuid做爲節點名，

該名字也能夠手動指定。單個集羣能夠由任意數量的節點組成。若是隻啓動了一個節點，則會造成一個單節點的集羣。

三、分片

Primary Shard(主分片）

ES中的shard用來解決節點的容量上限問題,，經過主分片，能夠將數據分佈到集羣內的全部節點之上。

它們之間關係

一個節點對應一個ES實例；
一個節點能夠有多個index（索引）;
一個index能夠有多個shard（分片）；
　一個分片是一個lucene index（此處的index是lucene本身的概念，與ES的index不是一回事）；

主分片數是在索引建立時指定，後續不容許修改，除非Reindex

一個索引中的數據保存在多個分片中(默認爲一個)，至關於水平分表。一個分片即是一個Lucene 的實例，它自己就是一個完整的搜索引擎。咱們的文檔被存儲和索引到分片內，

可是應用程序是直接與索引而不是與分片進行交互。

Replica Shard（副本）

副本有兩個重要做用：

一、服務高可用：因爲數據只有一份,若是一個node掛了,那存在上面的數據就都丟了,有了replicas,只要不是存儲這條數據的node全掛了,數據就不會丟。所以分片副本不會與

主分片分配到同一個節點；

二、擴展性能：經過在全部replicas上並行搜索提升搜索性能.因爲replicas上的數據是近實時的(near realtime),所以全部replicas都能提供搜索功能,經過設置合理的replicas

數量能夠極高的提升搜索吞吐量

分片的設定

　　對於生產環境中分片的設定，須要提早作好容量規劃，由於主分片數是在索引建立時預先設定的，後續沒法修改。

分片數設置太小

　　　　　　致使後續沒法增長節點進行水平擴展。

　　　　　　致使分片的數據量太大，數據在從新分配時耗時；

分片數設置過大

　　　　　　影響搜索結果的相關性打分，影響統計結果的準確性；

　　　　　　單個節點上過多的分片，會致使資源浪費，同時也會影響性能；

## 3、倒排索引

ES的搜索功能是基於lucene,而lucene搜索的基本原理就是倒敘索引,倒序排序的結果跟分詞的類型有關。

舉例

一、假設文檔集合包含五個文檔，毎個文檔內容如圖所示，在圖中最左端一欄是每一個文檔對應的文擋編號。

如圖(盜圖）

二、首先要用分詞系統將文擋自動切分紅單詞序列，記錄下哪些文擋包含這個單詞，在如此處理結束後，咱們能夠獲得最簡單的倒排索引。

三、索引系統還能夠記錄除此以外的更多信息，下圖還記載了單詞頻率信息。文檔中的句子被劃分爲一個個term(term 用來表示一個單詞或詞語,取決於使用的分詞方式),

倒敘索引中存儲着term,term的出現頻率(tf,term frequency)和出現位置(倒敘索引中的單詞是按順序排列的,這張圖沒有體現出來),請注意這裏的文檔內容是document

中的一個字段,也就是說每一個被索引了的字段都有本身的倒敘索引

一次簡單的搜索流程

假設咱們搜索谷歌地圖之父,搜索流程會是這樣

分詞,分詞插件將句子分爲3個term 谷歌,地圖,之父
將這3個term拿到倒敘索引中去查找(會很高效,好比二分查找),若是匹配到了就拿對應的文檔id,得到文檔內容

可是,如何肯定結果順序?

這裏要引入_score的概念,對於term的匹配,lucene會對其打分,得分越高,排名越靠前.這裏要介紹幾個相關的概念

- TF(term frequency),詞頻,term在當前document中出現的頻率,一個term在當前document中出現5次要比出現1次更相關,打分也會更高
- IDF(inverse doucment frequency),逆向文檔頻率,term在全部document中出現的頻率,這個頻率越高,該term對應的分值越低
- 字段長度歸一值,簡單來講就是字段越短,字段的權重越高, 好比 term `我`在匹配 `我123`和`我123456`時,`我123`的得分會更高.

### 參考

一、Elasticsearch核心技術與實戰---阮一鳴(eBay Pronto平臺技術負責人

二、ElasticSearch 基本概念

三、Elasticsearch之基礎概念

四、ElasticSearch第5節倒排索引、分詞器

我相信，不管從此的道路多麼坎坷，只要抓住今天，早晚會在奮鬥中嚐到人生的甘甜。抓住人生中的一分一秒，賽過虛度中的一月一年！(8）