在我们的实际部署中，我们的各个node（节点）的能力是不一样的。比如有的节点的计算能力比较强，而且配有高性能的存储，速度也比较快，同时我们可能有一些node的能力稍微差一点，比如计算能力及存储器的速度都比较差一点。针对这两种情况，我们其实可以把这两种节点用来做不同的用途：运算能力较强的节点可以用来做indexing（建立索引表格）的工作，而那些能力较差一点的节点，我们可以用来做搜索用途。我们可以把这两种节点分别叫做：
- hot node：用于支持索引并写入新文档
- warm node：用于处理不太频繁查询的只读索引
这种架构在Elasticsearch中，我们称之为hot/warm架构。
Hot node
我们可以使用hot node来做indexing：
- indexing是CPU和IO的密集操作，因此热节点应该是功能强大的服务器
- 比warm node更快的存储
Warm node
对较旧的只读索引使用热节点：
- 倾向于利用大型附加磁盘（通常是旋转磁盘）
- 大量数据可能需要其他节点才能满足性能要求
Shard filtering
Shard filtering在Elasticsearch中，我们可以利用这个能力来把我们想要的index放入到我们想要的node里。我们可以使用在elasticsearch.yml配置文件中的：
- node.attr来指定我们node属性：hot或是warm。
- 在index的settings里通过index.routing.allocation来指定索引（index)到一个满足要求的node
为节点分配索引有三种规则：
就像上面的表格说明的一样：include指的是至少包含其中的一个值；exclude指的是不包含任何值；require指的是必须包含里面索引的值。这些值实际上我们用来标识node的tag。针对自己的配置这些tag可以由厂商自己标识。
标识node
在上面的图中，我们标识my_temp属性为hot或是warm，表明我们的cluster中分为两类：hot或是warm。在这里特别指出：这里的my_temp，hot及warm都是我们任意取的可以让我们记住的属性及名称。只要在使用时和index.routing.allocation.include index.routing.allocation.exclude及index.routing.allocation.require中的值相对应即可。
配置index的settings
我们可以通过配置在Index中的settings来分配我们的index到相应的具有哪些属性的node里，比如：
PUT logs-2019-03
{
"settings": {
"index.routing.allocation.require.my_temp": "hot"
}
}
在上面我们通过logs-2019-03的这个index的settings来控制这个index必须分配到具有hot属性的node里。
假如我们上面的index logs-2019-03由于一些原因不再是当前的用来做indexing的index，比如我们可以通过rollover API接口来自动滚动我们的index名字。我们可以通过如下的命令把该index移动到warm node里：
PUT logs-2019-03
{
"settings": {
"index.routing.allocation.require.my_temp": "warm"
}
}
这样Elasticsearch会自动帮我们把logs-2019-03索引移动到warm node中，以便直供搜索之用。
例子
首先，我们我们按照如下的方式来做一个实验，虽然不能应用于实际的生产环境中：
- 按照“如何在Linux，MacOS及Windows上进行安装Elasticsearch”安装好自己的Elasticsearh，但是不要运行Elasticsearch
- 按照“如何在Linux及MacOS上安装Elastic栈中的Kibana”安装好自己的Kibana
在我们完成上面的两个安装后，我们分别打开两个terminal，然后分别在两个terminal中运行如下的指令：
./bin/elasticsearch -E node.name=node1 -E node.attr.data=hot -Enode.max_local_storage_nodes=2
上面的指令运行一个名字叫做node1的，data属性为hot的node。
./bin/elasticsearch -E node.name=node2 -E node.attr.data=warm -Enode.max_local_storage_nodes=2
上面的指令运行一个名字叫做node2的，data属性为hot的warm。
我们可以在Kibana里查看我们的nodes：
我们可以看出来有两个node正在运行：node1及node2。如果我们想了解这两个node的更多属性，我们可以打入如下的命令：
GET _cat/nodeattrs?v&s=name
显示的结果为：
我们可以看到node被标识为hot node，而node2被标识为warm node。
接下来，我们运用我们上面命令来把我们的logs-2019-03置于我们的hot node里。我们可以通过如下的命令：
PUT logs-2019-03
{
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0,
"index.routing.allocation.require.data": "hot"
}
}
运行上面的结果后，可以通过如下的命令来查看：
GET _cat/shards/logs-*?v&h=index,shard,prirep,state,node&s=index,shard,prirep
显示的结果为：
从上面我们可以看出来我们的logs-2019-03是分配到node1上面的。
假如我们由于某种原因，想把logs-2019-03分配到node2上面，那么该怎么做呢？我们可以通过如下的命令来实现：
PUT logs-2019-03/_settings
{
"index.routing.allocation.require.data": "warm"
}
运行上面的指令显示的结果是：
显然我们logs-2019-03已经成功地移到node2了。
针对硬件的shard filtering
上面我们说了，对于node.attr来说，我们可以添加任意的属性。在上面的我们已经使用hot/warm来标识我们的my_temp属性。其实我们也可以同时定义一些能标识硬件的属性my_server，这个属性值可以为small，medium及large。有多个属性组成的集群就像是如下的结构：
那么这样的集群里的每个node可能具有不同的属性。我们可以通过如下的方法来分配index到同时具有两个或以上属性的node里:
PUT my_index1
{
"settings": {
"number_of_shards": 2,
"number_of_replicas": 1,
"index.routing.allocation.include.my_server": "medium",
"index.routing.allocation.require.my_temp": "hot"
}
}
如上所示，我们把我们的my_index1分配到这么一个node：这个node必须具有hot属性，同时也具有medium的属性。针对我们上面显示的图片，只有node1满足我们的要求。
总结：在今天的这篇文章中，我们介绍了如何使用shard filtering来控制我们的index的分配。在实际的操作中，可能大家会觉得麻烦一点，因为这个比较需要我们自己来管理这个。这个技术可以和我之前的文章“Elasticsearch: rollover API”一起配合使用。Elasticsearch实际已经帮我做好了。在接下来的文章里，我会来介绍如何使用Index life cycle policy来自动管理我们的Index。