Elasticsearch 5.0-基礎概念
標籤 ： Elasticsearch
本文是 Elasticsearch 5.0 系列博文的基礎概念篇，主要介紹集羣，節點，索引，類型，文檔，分片，副本等基礎概念
寫在前面
- 本文以 Elasticsearch 5.0.1 版本爲例進行講解,不定期更新
- 該系列主要參考的 Elasticsearch Reference: 5.0，儘量避免照搬翻譯，只摘錄精要部分輔以簡單說明
- 寫這個系列博客的初衷是強迫自己梳理，同時方便一些較忙/沒空耐心看英文文檔的朋友快速上手，建議讀者有空多讀官方文檔，畢竟別人寫的都是二手資料
- 如需查看 ES 系列更多博文，請關注我的個人網站@brianway 或者 @CSDN
基本概念
有關概念在Basic Concepts中已經介紹的很詳細了，這裏簡單說一下。
- 集羣(cluster)：集羣由一個或者多個節點組成，由名稱唯一標識
- 節點(node)：一個單獨的 Elasticsearch 實例
- 索引(index)：文檔的集合
- 類型(type)：索引的邏輯分類/分區
- 文檔(document)：能夠被索引的信息基礎單元
- 分片(shard)：索引的物理分區，是一個最小的 Lucene 索引單元。分爲 primary shard(主分片) 和 replica shard(簡稱replicas)。
- 副本/備份(replicas)：主分片的備份
下面就這幾個概念進一步說明
類比關係型數據庫
其中索引,類型,文檔的概念可以類比關係型數據庫
| Elasticsearch | 關係型數據庫 |
|---|---|
| 索引(index) | 數據庫(database) |
| 類型(type) | 表(table) |
| 文檔(document) | 行記錄(row) |
| 字段(field) | 列(column) |
爲什麼有shard和replica
爲什麼有 shard?
- 可以水平切分和擴展內容容量
- 在shards 間分發和並行執行操作，從而提供性能和吞吐量
爲什麼有replica?
- 當 shard 失效時提供高可用性。因爲這個原因，一個primary shard的replica不會分配到和該shard所處的同一節點
- 擴展查詢的容量/吞吐量，因爲查詢操作是一個讀操作，可以在所有replica上並行執行
其他補充
Elasticsearch 默認爲每個 index 創建 5 個主分片，且備份數爲 1。也就是說，每個索引由 5 個主分片組成，並且每個分片擁有一個備份。需要注意的是，主分片的數量一旦確定，之後是不能更改的（除非重新建立索引），而 replicas 的數量可以在之後隨時更改。
所以在上一篇文章中，我們啓動 Kibana 後在 Consonle 查詢索引狀態GET /_cat/indices?v，會發現 health 是 yellow 而不是 green，就是因爲我們只開啓了一個節點，而且 Kibana 啓動後在 Elasticsearch 中建立了一個默認索引 .kibana，該索引只有 1 個主分片和一個副本，故 shard 都在該節點上，而 shard 的副本不能和該 shard 分配在同一節點，故未生效，從而導致狀態是黃色。
另外，每個索引被分配到多個分片，但 number_of_shards 的值只適用於索引，而不是整個集羣。這個值指定了每個索引的分片數，而非整個集羣中的全部主分片數。（摘自Optimizing Elasticsearch: How Many Shards per Index?）