環境：elasticsearch7.8.0

索引模板

通過事先定義好的模板，在創建索引時，如果索引名稱與模版中定義的索引模式匹配那么就會自動應用模版中的配置信息。如果有多個索引模板被匹配，那么會根據order進行優先級。

• 語法格式

{
  "order": 0,                                        // 模板優先級，當有多個模板被匹配那么會根據這個order優先級。
  "index_patterns": "xxx_yyy_*",         // 模板匹配的名稱方式，可以使用通配符
  "settings": {...},                                 // 索引設置
  "mAppings": {...},                             // 索引中各字段的映射定義
  "aliases": {...}                                   // 索引的別名
}

• 創建模板

localhost:9200/_template/t-order-tpl

{
    "index_patterns": [
        "t-order-*"
    ],
    "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 0
    },
    "mappings": {
        "_source": {
            "enabled": true
        },
        "properties": {
            "sno": {
                "type": "keyword"
            },
            "name": {
                "type": "text",
                "analyzer": "ik_max_word"
            },
            "price": {
                "type": "double"
            },
            "created": {
                "type": "date"
            }
        }
    }
}

• 查看模板

http://localhost:9200/_cat/templates?v

 

默認order為0。

• 創建索引

body中什么也沒有輸入，查看索引創建情況：

自動應用了上面創建的模版。

模板在很多場景下都非常的有用，比如：我們希望每天對系統的日志信息進行記錄，每次都去指定這些通用的信息非常麻煩也可能由于疏忽導致錯誤等問題。有個模版，每次再創建索引的時候我們只需要指定索引名稱即可。

索引別名

索引別名可以很好地解決多個不同索引版本的無縫切換，有點數據庫中的視圖的意思。操作的時候是使用的索引別名，實際在es內部會自動轉換到真實的索引上。

• 創建索引別名

方式1、如果在創建索引模板的時候指定了別名，那么在創建索引的時候會自動應該索引別名。

方式2、通過如下接口。

我們對上面創建的索引創建別名

接口1：

POST http://localhost:9200/t-order-20210513/_alias/order-01

接口2：

POST http://localhost:9200/_aliases

{
    "actions" : [
        { 
        	"add" : { 
        		"index" : "t-order-20210513", 
        		"alias" : "order-02" 
        	} 
        }
    ]
}

或者

批量操作

POST http://localhost:9200/_aliases

{
    "actions" : [
        { 
        	"add" : { 
        		"index" : "t-order-20210513", 
        		"alias" : "order-03" 
        	}
        },
        { 
        	"add" : { 
        		"index" : "t-order-20210513", 
        		"alias" : "order-04" 
        	}
        }
    ]
}

查看索引：

• 索引別名進行操作

通過別名創建文檔

查詢文檔

• 修改索引別名的指向

POST http://localhost:9200/_aliases

{
    "actions" : [
        { "remove" : { "index" : "t-order-20210513", "alias" : "order-01" } },
        { "add" : { "index" : "t-order-202105", "alias" : "order-01" } }
    ]
}

這樣就會進行了別名與索引的無縫切換。

_source字段

_source：默認是開啟存儲的，如上面看到的查詢文檔時返回的就有_source。在有些實際的業務情況下我們是可以通過關閉_source功能來節省硬盤空間的。比如，我們只需要通過關鍵詞查詢出具體文檔對應的id即可的時候我們就可以關閉_source功能。

總的來說在默認的情況下，我們添加一份文檔的時候會存儲一份原始的文檔信息和一個倒排索引（倒排索引記錄的就是關鍵字與原始文檔之間的一個對應關系，文檔的ID）。

默認情況下查詢文檔：

關閉_source功能：

"mappings": {
  "_source": { "enabled": false },  // 是否保存字段的原始值
  "properties": {
    "name": {
      "type": "text"
    }
  }
}

結果中已經沒有_source。

節點類型

• 主節點

#是否能成為主節點（true：表示具有被選舉成為主節點的資格）
node.master: true

作用：

1. 索引的創建或刪除
2. 跟蹤哪些節點是集群的一部分
3. 決定哪些分片分配給相關的節點

說明：

默認情況下任何一個集群中的節點都有可能被選為主節點。索引數據和搜索查詢等操作會占用大量的cpu，內存，io資源，為了確保一個集群的穩定，分離主節點和數據節點是一個比較好的選擇。雖然主節點也可以協調節點，路由搜索和從客戶端新增數據到數據節點，但最好不要使用這些專用的主節點。一個重要的原則是，盡可能做盡量少的工作。
為了防止數據丟失，配置
discovery.zen.minimum_master_nodes設置是至關重要的（默認為1），每個主節點應該知道形成一個集群的最小數量的主資格節點的數量。
解釋如下：
假設我們有一個集群。有3個主資格節點，當網絡發生故障的時候，有可能其中一個節點不能和其他節點進行通信了。這個時候，當
discovery.zen.minimum_master_nodes設置為1的時候，就會分成兩個小的獨立集群，當網絡好的時候，就會出現數據錯誤或者丟失數據的情況。當discovery.zen.minimum_master_nodes設置為2的時候，一個網絡中有兩個主資格節點，可以繼續工作，另一部分，由于只有一個主資格節點，則不會形成一個獨立的集群，這個時候當網絡回復的時候，節點又會從新加入集群。

• 數據節點

#是否能成為主節點（true：表示具有被選舉成為主節點的資格）
node.master: false
#數據節點
node.data: true

作用：

1. 存儲索引數據
2. 對文檔進行增刪改查,聚合操作

說明：數據節點對磁盤，內存，要求比較高最好給機器更高的配置。

• 協調節點

#是否能成為主節點（true：表示具有被選舉成為主節點的資格）
node.master: false
#數據節點
node.data: false
node.ingest: false

都設置成false就成為了協調節點。

像搜索請求或批量索引請求這樣的請求可能涉及保存在不同數據節點上的數據。例如，搜索請求分兩個階段執行，這兩個階段由接收客戶端請求的協調節點。

在分散階段，協調節點將請求轉發給保存數據的數據節點。每個數據節點在本地執行請求，并將其結果返回給協調節點。

在收集階段，協調節點將每個數據節點的結果縮減為單個全局結果集。

總結：協調節點就是負責接收Client 的請求，包括 REST Client 等。該節點將請求分發到合適的節點，最終把結果匯集到一起。一般來說，每個節點默認起到了 Coordinating Node 的職責。

三種節點類型對機器要求簡單說明：
master節點：普通服務器即可(CPU 內存 消耗一般)
data 節點：主要是消耗磁盤，內存
coordinating 節點：需要有足夠的內存和CPU來處理聚集階段。

其它節點類型及相關節點類型說明查看官方文檔：

完畢?。?！