环境：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来处理聚集阶段。

其它节点类型及相关节点类型说明查看官方文档：

完毕！！！