ES--01

 

 

 

 

ES概念：

　　垂直搜索（站內搜索）

 

什麼是全文檢索和Lucene？

1 全文檢索 倒排索引

2 Lucene 就是一個jar包 裏面包含了封裝好的各類簡歷倒排索引 以及進行搜索的代碼 包括各類算法 咱們就用java開發的時候 引入 lucene jar 而後基於lucene的api進行開發 用lucene，將已有的數據創建索引 lucene會在本地磁盤上 給咱們組織索引的數據結構

ES的概念：

　　

一、Elasticsearch的功能

（1）分佈式的搜索引擎和數據分析引擎

搜索：百度，網站的站內搜索，IT系統的檢索
數據分析：電商網站，最近7天牙膏這種商品銷量排名前10的商家有哪些；新聞網站，最近1個月訪問量排名前3的新聞版塊是哪些
分佈式，搜索，數據分析

（2）全文檢索，結構化檢索，數據分析

全文檢索：我想搜索商品名稱包含牙膏的商品，select * from products where product_name like "%牙膏%"
結構化檢索：我想搜索商品分類爲日化用品的商品都有哪些，select * from products where category_id='日化用品'
部分匹配、自動完成、搜索糾錯、搜索推薦
數據分析：咱們分析每個商品分類下有多少個商品，select category_id,count(*) from products group by category_id

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

分佈式：ES自動能夠將海量數據分散到多臺服務器上去存儲和檢索
海聯數據的處理：分佈式之後，就能夠採用大量的服務器去存儲和檢索數據，天然而然就能夠實現海量數據的處理了
近實時：檢索個數據要花費1小時（這就不要近實時，離線批處理，batch-processing）；在秒級別對數據進行搜索和分析

跟分佈式/海量數據相反的：lucene，單機應用，只能在單臺服務器上使用，最多隻能處理單臺服務器能夠處理的數據量

 

二、Elasticsearch的適用場景

國外

（1）維基百科，相似百度百科，牙膏，牙膏的維基百科，全文檢索，高亮，搜索推薦
（2）The Guardian（國外新聞網站），相似搜狐新聞，用戶行爲日誌（點擊，瀏覽，收藏，評論）+社交網絡數據（對某某新聞的相關見解），數據分析，給到每篇新聞文章的做者，讓他知道他的文章的公衆反饋（好，壞，熱門，垃圾，鄙視，崇拜）
（3）Stack Overflow（國外的程序異常討論論壇），IT問題，程序的報錯，提交上去，有人會跟你討論和回答，全文檢索，搜索相關問題和答案，程序報錯了，就會將報錯信息粘貼到裏面去，搜索有沒有對應的答案
（4）GitHub（開源代碼管理），搜索上千億行代碼
（5）電商網站，檢索商品
（6）日誌數據分析，logstash採集日誌，ES進行復雜的數據分析（ELK技術，elasticsearch+logstash+kibana）
（7）商品價格監控網站，用戶設定某商品的價格閾值，當低於該閾值的時候，發送通知消息給用戶，好比說訂閱牙膏的監控，若是高露潔牙膏的家庭套裝低於50塊錢，就通知我，我就去買
（8）BI系統，商業智能，Business Intelligence。好比說有個大型商場集團，BI，分析一下某某區域最近3年的用戶消費金額的趨勢以及用戶羣體的組成構成，產出相關的數張報表，**區，最近3年，每一年消費金額呈現100%的增加，並且用戶羣體85%是高級白領，開一個新商場。ES執行數據分析和挖掘，Kibana進行數據可視化

國內

（9）國內：站內搜索（電商，招聘，門戶，等等），IT系統搜索（OA，CRM，ERP，等等），數據分析（ES熱門的一個使用場景）

三、Elasticsearch的特色

（1）能夠做爲一個大型分佈式集羣（數百臺服務器）技術，處理PB級數據，服務大公司；也能夠運行在單機上，服務小公司
（2）Elasticsearch不是什麼新技術，主要是將全文檢索、數據分析以及分佈式技術，合併在了一塊兒，才造成了獨一無二的ES；lucene（全文檢索），商用的數據分析軟件（也是有的），分佈式數據庫（mycat）
（3）對用戶而言，是開箱即用的，很是簡單，做爲中小型的應用，直接3分鐘部署一下ES，就能夠做爲生產環境的系統來使用了，數據量不大，操做不是太複雜
（4）數據庫的功能面對不少領域是不夠用的（事務，還有各類聯機事務型的操做）；特殊的功能，好比全文檢索，同義詞處理，相關度排名，複雜數據分析，海量數據的近實時處理；Elasticsearch做爲傳統數據庫的一個補充，提供了數據庫所不不能提供的不少功能

 

ElasticSearch 和 Lucene 的關係

一、lucene和elasticsearch的前世此生

lucene，最早進、功能最強大的搜索庫，直接基於lucene開發，很是複雜，api複雜（實現一些簡單的功能，寫大量的java代碼），須要深刻理解原理（各類索引結構）

elasticsearch，基於lucene，隱藏複雜性，提供簡單易用的restful api接口、java api接口（還有其餘語言的api接口）
（1）分佈式的文檔存儲引擎
（2）分佈式的搜索引擎和分析引擎
（3）分佈式，支持PB級數據

開箱即用，優秀的默認參數，不須要任何額外設置，徹底開源

二、elasticsearch的核心概念

（1）Near Realtime（NRT）：近實時，兩個意思，從寫入數據到數據能夠被搜索到有一個小延遲（大概1秒）；基於es執行搜索和分析能夠達到秒級

（2）Cluster：集羣，包含多個節點，每一個節點屬於哪一個集羣是經過一個配置（集羣名稱，默認是elasticsearch）來決定的，對於中小型應用來講，剛開始一個集羣就一個節點很正常
（3）Node：節點，集羣中的一個節點，節點也有一個名稱（默認是隨機分配的），節點名稱很重要（在執行運維管理操做的時候），默認節點會去加入一個名稱爲「elasticsearch」的集羣，若是直接啓動一堆節點，那麼它們會自動組成一個elasticsearch集羣，固然一個節點也能夠組成一個elasticsearch集羣

（4）Document&field：（document至關於一個row field至關於一個字段屬性）文檔，es中的最小數據單元，一個document能夠是一條客戶數據，一條商品分類數據，一條訂單數據，一般用JSON數據結構表示，每一個index下的type中，均可以去存儲多個document。一個document裏面有多個field，每一個field就是一個數據字段。

product document

{
"product_id": "1",
"product_name": "高露潔牙膏",
"product_desc": "高效美白",
"category_id": "2",
"category_name": "日化用品"
}

（5）Index：至關於數據庫 db 索引，包含一堆有類似結構的文檔數據，好比能夠有一個客戶索引，商品分類索引，訂單索引，索引有一個名稱。一個index包含不少document，一個index就表明了一類相似的或者相同的document。好比說創建一個product index，商品索引，裏面可能就存放了全部的商品數據，全部的商品document。
（6）Type：至關於表格 table  類型，每一個索引裏均可以有一個或多個type，type是index中的一個邏輯數據分類，一個type下的document，都有相同的field，好比博客系統，有一個索引，能夠定義用戶數據type，博客數據type，評論數據type。

商品index，裏面存放了全部的商品數據，商品document

可是商品分不少種類，每一個種類的document的field可能不太同樣，好比說電器商品，可能還包含一些諸如售後時間範圍這樣的特殊field；生鮮商品，還包含一些諸如生鮮保質期之類的特殊field

type，日化商品type，電器商品type，生鮮商品type

日化商品type：product_id，product_name，product_desc，category_id，category_name
電器商品type：product_id，product_name，product_desc，category_id，category_name，service_period
生鮮商品type：product_id，product_name，product_desc，category_id，category_name，eat_period

每個type裏面，都會包含一堆document

{
"product_id": "2",
"product_name": "長虹電視機",
"product_desc": "4k高清",
"category_id": "3",
"category_name": "電器",
"service_period": "1年"
}

{
"product_id": "3",
"product_name": "基圍蝦",
"product_desc": "純自然，冰島產",
"category_id": "4",
"category_name": "生鮮",
"eat_period": "7天"
}

（7）shard：單臺機器沒法存儲大量數據，es能夠將一個索引中的數據切分爲多個shard，分佈在多臺服務器上存儲。有了shard就能夠橫向擴展，存儲更多數據，讓搜索和分析等操做分佈到多臺服務器上去執行，提高吞吐量和性能。每一個shard都是一個lucene index。
（8）replica：任何一個服務器隨時可能故障或宕機，此時shard可能就會丟失，所以能夠爲每一個shard建立多個replica副本。replica能夠在shard故障時提供備用服務，保證數據不丟失，多個replica還能夠提高搜索操做的吞吐量和性能。primary shard（創建索引時一次設置，不能修改，默認5個），replica shard（隨時修改數量，默認1個），默認每一個索引10個shard，5個primary shard，5個replica shard，最小的高可用配置，是2臺服務器。

安裝運行es

elasticsearch 的安裝 head插件：

　　使用wget 安裝head插件

　　安裝後訪問localhost：//9100顯示未鏈接  停掉head服務 而後編輯es的配置文件 ElasticSearch.yml 

 

修改後　啓動es

而後開啓head插件

 

鏈接狀態

 

啓動kibana

 

使用devtools 

 

 

一、document數據格式

面向文檔的搜索分析引擎

（1）應用系統的數據結構都是面向對象的，複雜的
（2）對象數據存儲到數據庫中，只能拆解開來，變爲扁平的多張表，每次查詢的時候還得還原回對象格式，至關麻煩
（3）ES是面向文檔的，文檔中存儲的數據結構，與面向對象的數據結構是同樣的，基於這種文檔數據結構，es能夠提供複雜的索引，全文檢索，分析聚合等功能
（4）es的document用json數據格式來表達

public class Employee {

private String email;
private String firstName;
private String lastName;
private EmployeeInfo info;
private Date joinDate;

}

private class EmployeeInfo {

private String bio; // 性格
private Integer age;
private String[] interests; // 興趣愛好

}

EmployeeInfo info = new EmployeeInfo();
info.setBio("curious and modest");
info.setAge(30);
info.setInterests(new String[]{"bike", "climb"});

Employee employee = new Employee();
employee.setEmail("zhangsan@sina.com");
employee.setFirstName("san");
employee.setLastName("zhang");
employee.setInfo(info);
employee.setJoinDate(new Date());

employee對象：裏面包含了Employee類本身的屬性，還有一個EmployeeInfo對象

兩張表：employee表，employee_info表，將employee對象的數據從新拆開來，變成Employee數據和EmployeeInfo數據
employee表：email，first_name，last_name，join_date，4個字段
employee_info表：bio，age，interests，3個字段；此外還有一個外鍵字段，好比employee_id，關聯着employee表

{
"email": "zhangsan@sina.com",
"first_name": "san",
"last_name": "zhang",
"info": {
"bio": "curious and modest",
"age": 30,
"interests": [ "bike", "climb" ]
},
"join_date": "2017/01/01"
}

咱們就明白了es的document數據格式和數據庫的關係型數據格式的區別 

 

案例：

　　

二、電商網站商品管理案例背景介紹

有一個電商網站，須要爲其基於ES構建一個後臺系統，提供如下功能：

（1）對商品信息進行CRUD（增刪改查）操做
（2）執行簡單的結構化查詢
（3）能夠執行簡單的全文檢索，以及複雜的phrase（短語）檢索
（4）對於全文檢索的結果，能夠進行高亮顯示
（5）對數據進行簡單的聚合分析

三、簡單的集羣管理

（1）快速檢查集羣的健康情況

es提供了一套api，叫作cat api，能夠查看es中各類各樣的數據

GET /_cat/health?v

epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1488006741 15:12:21 elasticsearch yellow 1 1 1 1 0 0 1 0 - 50.0%

epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent    啓動第二個es進程的狀況 yellow變成green
1488007113 15:18:33 elasticsearch green 2 2 2 1 0 0 0 0 - 100.0%

epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1488007216 15:20:16 elasticsearch yellow 1 1 1 1 0 0 1 0 - 50.0%

如何快速瞭解集羣的健康情況？green、yellow、red？

green：每一個索引的primary shard和replica shard都是active狀態的
yellow：每一個索引的primary shard都是active狀態的，可是部分replica shard不是active狀態，處於不可用的狀態
red：不是全部索引的primary shard都是active狀態的，部分索引有數據丟失了

爲何如今會處於一個yellow狀態？

咱們如今就一個筆記本電腦，就啓動了一個es進程，至關於就只有一個node。如今es中有一個index，就是kibana本身內置創建的index。因爲默認的配置是給每一個index分配5個primary shard和5個replica shard，並且primary shard和replica shard不能在同一臺機器上（爲了容錯）。如今kibana本身創建的index是1個primary shard和1個replica shard。當前就一個node，因此只有1個primary shard被分配了和啓動了，可是一個replica shard沒有第二臺機器去啓動。

作一個小實驗：此時只要啓動第二個es進程，就會在es集羣中有2個node，而後那1個replica shard就會自動分配過去，而後cluster status就會變成green狀態。

（2）快速查看集羣中有哪些索引

GET /_cat/indices?v

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open .kibana rUm9n9wMRQCCrRDEhqneBg 1 1 1 0 3.1kb 3.1kb

（3）簡單的索引操做

建立索引：PUT /test_index?pretty

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open test_index XmS9DTAtSkSZSwWhhGEKkQ 5 1 0 0 650b 650b
yellow open .kibana rUm9n9wMRQCCrRDEhqneBg 1 1 1 0 3.1kb 3.1kb

刪除索引：DELETE /test_index?pretty

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open .kibana rUm9n9wMRQCCrRDEhqneBg 1 1 1 0 3.1kb 3.1kb

 

四、商品的CRUD操做

（1）新增商品：新增文檔，創建索引   version涉及到樂觀鎖的併發控制策略。

PUT /index/type/id
{
"json數據"
}

PUT /ecommerce/product/1
{
"name" : "gaolujie yagao",
"desc" : "gaoxiao meibai",
"price" : 30,
"producer" : "gaolujie producer",
"tags": [ "meibai", "fangzhu" ]
}

{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}

PUT /ecommerce/product/2
{
"name" : "jiajieshi yagao",
"desc" : "youxiao fangzhu",
"price" : 25,
"producer" : "jiajieshi producer",
"tags": [ "fangzhu" ]
}

PUT /ecommerce/product/3
{
"name" : "zhonghua yagao",
"desc" : "caoben zhiwu",
"price" : 40,
"producer" : "zhonghua producer",
"tags": [ "qingxin" ]
}

es會自動創建index和type，不須要提早建立，並且es默認會對document每一個field都創建倒排索引，讓其能夠被搜索

（2）查詢商品：檢索文檔

GET /index/type/id
GET /ecommerce/product/1

{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"name": "gaolujie yagao",
"desc": "gaoxiao meibai",
"price": 30,
"producer": "gaolujie producer",
"tags": [
"meibai",
"fangzhu"
]
}
}

（3）修改商品：替換文檔  version改變了

PUT /ecommerce/product/1
{
"name" : "jiaqiangban gaolujie yagao",
"desc" : "gaoxiao meibai",
"price" : 30,
"producer" : "gaolujie producer",
"tags": [ "meibai", "fangzhu" ]
}

{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}

{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 2,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": false
}

PUT /ecommerce/product/1
{
"name" : "jiaqiangban gaolujie yagao"
}

替換方式有一個很差，即便必須帶上全部的field，才能去進行信息的修改  若是隻帶name屬性來替換  其餘屬性就丟失了 只有name屬性了

（4）修改商品：更新文檔

POST /ecommerce/product/1/_update
{
"doc": {
"name": "jiaqiangban gaolujie yagao"
}
}

{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 8,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}

個人風格，其實有選擇的狀況下，不太喜歡念ppt，或者照着文檔作，或者直接粘貼寫好的代碼，儘可能是純手敲代碼

（5）刪除商品：刪除文檔

DELETE /ecommerce/product/1

{
"found": true,
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_version": 9,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}

{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"found": false
}

 

多種搜索方式：

一、query string search
二、query DSL
三、query filter
四、full-text search
五、phrase search
六、highlight search

一、query string search

搜索所有商品：GET /ecommerce/product/_search

took：耗費了幾毫秒
timed_out：是否超時，這裏是沒有
_shards：數據拆成了5個分片，因此對於搜索請求，會打到全部的primary shard（或者是它的某個replica shard也能夠）
hits.total：查詢結果的數量，3個document
hits.max_score：score的含義，就是document對於一個search的相關度的匹配分數，越相關，就越匹配，分數也高
hits.hits：包含了匹配搜索的document的詳細數據

{
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 3,
"max_score": 1,
"hits": [
{
"_index": "ecommerce",
"_type": "product",
"_id": "2",
"_score": 1,
"_source": {
"name": "jiajieshi yagao",
"desc": "youxiao fangzhu",
"price": 25,
"producer": "jiajieshi producer",
"tags": [
"fangzhu"
]
}
},
{
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_score": 1,
"_source": {
"name": "gaolujie yagao",
"desc": "gaoxiao meibai",
"price": 30,
"producer": "gaolujie producer",
"tags": [
"meibai",
"fangzhu"
]
}
},
{
"_index": "ecommerce",
"_type": "product",
"_id": "3",
"_score": 1,
"_source": {
"name": "zhonghua yagao",
"desc": "caoben zhiwu",
"price": 40,
"producer": "zhonghua producer",
"tags": [
"qingxin"
]
}
}
]
}
}

query string search的由來，由於search參數都是以http請求的query string來附帶的

搜索商品名稱中包含yagao的商品，並且按照售價降序排序：GET /ecommerce/product/_search?q=name:yagao&sort=price:desc

適用於臨時的在命令行使用一些工具，好比curl，快速的發出請求，來檢索想要的信息；可是若是查詢請求很複雜，是很難去構建的
在生產環境中，幾乎不多使用query string search

 

二、query DSL

DSL：Domain Specified Language，特定領域的語言
http request body：請求體，能夠用json的格式來構建查詢語法，比較方便，能夠構建各類複雜的語法，比query string search確定強大多了

查詢全部的商品

GET /ecommerce/product/_search
{
"query": { "match_all": {} }
}

查詢名稱包含yagao的商品，同時按照價格降序排序

GET /ecommerce/product/_search
{
"query" : {
"match" : {
"name" : "yagao"
}
},
"sort": [
{ "price": "desc" }
]
}

 

分頁查詢商品，總共3條商品，假設每頁就顯示1條商品，如今顯示第2頁，因此就查出來第2個商品

GET /ecommerce/product/_search
{
"query": { "match_all": {} },
"from": 1,
"size": 1
}

指定要查詢出來商品的名稱和價格就能夠

GET /ecommerce/product/_search
{
"query": { "match_all": {} },
"_source": ["name", "price"]
}

更加適合生產環境的使用，能夠構建複雜的查詢

 

三、query filter

搜索商品名稱包含yagao，並且售價大於25元的商品

四、full-text search（全文檢索） 計算相關度 分數 socre

producer這個字段 會被拆解 創建倒排索引

special 4
yagao 4
producer 1,2,3,4
gaolujie 1
zhognhua 3
jiajieshi 2

五、phrase search（短語搜索）

跟全文檢索相對應，相反，全文檢索會將輸入的搜索串拆解開來，去倒排索引裏面去一一匹配，只要能匹配上任意一個拆解後的單詞，就能夠做爲結果返回
phrase search，要求輸入的搜索串，必須在指定的字段文本中，徹底包含如出一轍的，才能夠算匹配，才能做爲結果返回

 

在yagao producer 之間多加幾個空格也能匹配  沒有空格 或者順序顛倒都不能匹配

六、highlight search（高亮搜索結果）

 

 

嵌套聚合、下鑽分析、聚合分析

 

一、計算每一個tag下的商品 聚合：

　　

將文本filed的fileddata屬性設置爲true

 

PUT /ecommerce/_mapping/product
{
"properties": {
"tags": {
"type": "text",
"fielddata": true
}
}
}

第二個聚合分析的需求：對名稱中包含yagao的商品，計算每一個tag下的商品數量

 

第三個聚合分析的需求：先分組，再算每組的平均值，計算每一個tag下的商品的平均價格

第四個數據分析需求：計算每一個tag下的商品的平均價格，而且按照平均價格降序排序

 

 

第五個數據分析需求：按照指定的價格範圍區間進行分組，而後在每組內再按照tag進行分組，最後再計算每組的平均價格

 

 

一、Elasticsearch對複雜分佈式機制的透明隱藏特性
二、Elasticsearch的垂直擴容與水平擴容
三、增減或減小節點時的數據rebalance
四、master節點
五、節點對等的分佈式架構

 

 

一、Elasticsearch對複雜分佈式機制的透明隱藏特性

Elasticsearch是一套分佈式的系統，分佈式是爲了應對大數據量
隱藏了複雜的分佈式機制

分片機制（咱們以前隨隨便便就將一些document插入到es集羣中去了，咱們有沒有care過數據怎麼進行分片的，數據到哪一個shard中去）

cluster discovery（集羣發現機制，咱們以前在作那個集羣status從yellow轉green的實驗裏，直接啓動了第二個es進程，那個進程做爲一個node自動就發現了集羣，而且加入了進去，還接受了部分數據，replica shard）

shard負載均衡（舉例，假設如今有3個節點，總共有25個shard要分配到3個節點上去，es會自動進行均勻分配，以保持每一個節點的均衡的讀寫負載請求）

shard副本，請求路由，集羣擴容，shard重分配

 

二、Elasticsearch的垂直擴容與水平擴容

垂直擴容：採購更強大的服務器，成本很是高昂，並且會有瓶頸，假設世界上最強大的服務器容量就是10T，可是當你的總數據量達到5000T的時候，你要採購多少臺最強大的服務器啊

水平擴容：業界常常採用的方案，採購愈來愈多的普通服務器，性能比較通常，可是不少普通服務器組織在一塊兒，就能構成強大的計算和存儲能力

普通服務器：1T，1萬，100萬
強大服務器：10T，50萬，500萬

擴容對應用程序的透明性

三、增減或減小節點時的數據rebalance

保持負載均衡

 

四、master節點

（1）建立或刪除索引
（2）增長或刪除節點

 

五、節點平等的分佈式架構

（1）節點對等，每一個節點都能接收全部的請求
（2）自動請求路由
（3）響應收集

請求轉發

接收到請求的shard 自動將請求轉發到目標document的shard 而且返回給client

 

第十講：

　　

一、shard&replica機制再次梳理
二、圖解單node環境下建立index是什麼樣子的

------------------------------------------------------------------------------------------------

一、shard&replica機制再次梳理

（1）index包含多個shard
（2）每一個shard都是一個最小工做單元，承載部分數據，lucene實例，完整的創建索引和處理請求的能力
（3）增減節點時，shard會自動在nodes中負載均衡
（4）primary shard和replica shard，每一個document確定只存在於某一個primary shard以及其對應的replica shard中，不可能存在於多個primary shard
（5）replica shard是primary shard的副本，負責容錯，以及承擔讀請求負載
（6）primary shard的數量在建立索引的時候就固定了，replica shard的數量能夠隨時修改
（7）primary shard的默認數量是5，replica默認是1，默認有10個shard，5個primary shard，5個replica shard
（8）primary shard不能和本身的replica shard放在同一個節點上（不然節點宕機，primary shard和副本都丟失，起不到容錯的做用），可是能夠和其餘primary shard的replica shard放在同一個節點上

------------------------------------------------------------------------------------------------

二、圖解單node環境下建立index是什麼樣子的

（1）單node環境下，建立一個index，有3個primary shard，3個replica shard
（2）集羣status是yellow
（3）這個時候，只會將3個primary shard分配到僅有的一個node上去，另外3個replica shard是沒法分配的
（4）集羣能夠正常工做，可是一旦出現節點宕機，數據所有丟失，並且集羣不可用，沒法承接任何請求

PUT /test_index
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}

 

 每一個shard都是一個最小的單元 就是一個lucene實例 自動把shard均勻分佈 

每一個document存在於一個primary shard 和它對應的replicate shard中

primaryshard的數量最開始固定了就不能變了 replica shard 的數量能改變