Elastic Searchable snapshot功能初探 二 （hot phase）

在上一篇文章中（Elastic Searchable snapshot功能初探），我们已经做了可搜索快照的简单演示。在总结中，我们提到：

通过以上演示，我们发现，通过配合新的node_roles，我们可以快速将节点标记为冷层（cold tier），在ILM中，这个新的冷层，会自动成为cold phase搬移数据的目的节点。而通过ILM，我们可以快速的通过策略指定索引该什么时候打开可搜索快照功能，并自动帮我们完成对接快照，配置别名的动作。而可搜索快照可以在hot phase就打开，在整个数据生命周期中为我们节省成本。

即可搜索快照功能，在我们的热节点上就可以直接打开。

在本篇博客中，我们将进一步演示该功能。所有的基本配置不变，要准备一套环境可以参考上一篇文章。

hot phase Searchable snapshot 演示

创建索引生命周期管理策略

仍然，我们先通过ILM工具来创建一个Hot phase的策略，如下图：

这里，我们将rollover的条件改为当索引超过3MB的时候，执行滚动切分。

对应的，为了将注意力放在hot phase，我们不enable另外的warm phase和cold phase

创建索引模板和索引别名

因为我们使用的是rollover功能，因此，必须使用data stream或者index alias。在下面的配置中，我们将指定匹配索引的lifecycle.name和lifecycle.rollover_alias:

PUT _template/searchable_snapshot_hot_demo
{"index_patterns": ["data-*"],"settings": {"index.lifecycle.name": "searchable_snapshot_demo","index.lifecycle.rollover_alias": "data_alias"}
}

可以参考rollover的官方文档，我们需要指定一个alias，并且背后的写索引，其索引名需要匹配特定的索引名pattern: ^.*-\d+$。这里的%3Cdata-%7Bnow%2Fd%7D-0001%3E 是<data-{now-1d}-0001>的URI编码

PUT %3Cdata-%7Bnow%2Fd%7D-0001%3E
{"aliases": {"data_alias": {"is_write_index": true}}
}

写入数据

我们仍然是使用样本数据来做这次演示。通过将kibana_sample_data_logs索引reindex到data_alias，我们将触发之前的索引生命周期管理规则

POST _reindex
{"source": {"index": "kibana_sample_data_logs"},"dest": {"index": "data_alias"}
}

当data_alias中的索引大小超过3MB的时候，将自动rollover出新的索引

触发生命周期管理的action

先看样本数据集的情况，一主一副本，14074个文档，占用20mb的存储空间：

如果没有启动searchable snapshot，我们看到的是，经过reindex，写入到data-*索引的数据被拆分成3个集群，每个索引都是一主一副本，总体大小在22MB左右

而如果打开searchable snapshot功能，可以看到，在hot phase就已经将冗余副本搬移到对象存储中，这时只剩下一个主分片，并且索引名被改为restored-*

总结

通过以上演示，我们看到，并非需要等到cold phase我们才可使用searchable snapshot，我们可以在索引数据的任意生命周期都可享受到可搜索快照带来的成本降低的优势，唯一需要考虑的是，我们如果平衡搜索性能、故障恢复时间以及存储成本之间的关系。可以预见的是，在一些低并发，对查询延时不是特别敏感的场景，比如运维日志，我们可以完全借助可搜索快照的功能来降低存储成本。