Elasticsearch 可搜索快照技术原理及最 佳实践

作者：吴容——腾讯云 Elasticsearch 高级开发工程师

Elasticsearch于7.10版本推出可搜索快照功能，但是7.10版本的可搜索快照技术还不够成熟，随着7.14版本的发布，可搜索快照技术才真正能够大规模用于生产实践中。本文将基于ES 7.14.2版本，继续从原理和实践两个角度向大家介绍可搜索快照技术。

可搜索快照特性向我们展现一种能够直接搜索快照中数据的魔力，通常我们会将快照备份到非常廉价的存储介质中，如腾讯云对象存储COS中。这样我们就可以将集群的使用成本降到最低。

一、可搜索快照技术原理

1.1 DataTier模型

要了解可搜索快照的工作机制，首先我们需要了解从7.10版本开始ES对节点的分层规划，即DataTier概念。

ES对不同的节点类型做了如下分层，分别是Content tier、Hot tier、Warm tier、Cold tier和Frozen tier。

• Content tier：主要处理产品目录等内容型索引和查询负载；

• Hot tier：主要处理数据的读写，尤其是时序类数据的写入和查询,由于对读写性能要求最高，并且查询的频率也最高，因此我们建议对于Hot tier的节点挂载SSD硬盘；

• Warm tier：主要处理时序类场景数据，数据不再被更新，查询频率相对Hot tier节点较低；

• Cold tier：主要处理数据的读请求，且查询的数据较老，通常查询频率更低，因此建议Warm/Cold tier的节点挂载HDD；

• Frozen tier：查询的频率更低，可能半年才查询那么几次，但是这种数据体量其实是最大的；于Frozen tier中的数据，则是通过可搜索快照的技术挂载在集群中的。原始的数据其实是在快照中，集群中只会保存索引的元数据相关信息，以及每次查询时的缓存数据。

1.2 节点属性优化

另外7.10版本之后的集群不再通过node.master，node.data来区分是何种角色的节点，而是通过node.roles数组来定义一个节点的角色。如我们的测试集群中，Hot tier节点的node.roles如下：

node.roles: ["data_hot", "data_content", "ingest", "ml", "remote_cluster_client", "transform"]

专用主节点的node.roles则是：

node.roles: ["master"]

如果集群中有Frozen tier的节点，我们通过是将该节点设置为专用Frozen节点，不和任何角色混用，如设置node.roles如下：

node.roles: ["data_frozen"]

除了对节点角色的优化，还对索引的allocation做了优化，原先我们是通过include.{attribute}、require.{attribute}、exclude.{attribute}来设置索引的allocation settings；而升级到DataTier模式后，则是通过index.routing.allocation.include._tier_preference属性决定索引分片应该分配在哪一Tier节点上。

index.routing.allocation.include._tier_preference的属性值是一个字符串，多个tier_preference之间通过逗号 ',' 隔开，分片分配的优先级是从前往后依次降低。例如集群中的系统索引.kibana_7.14.2_001在创建时，其index.routing.allocation.include._tier_preference属性值为："data_hot,data_warm,data_cold"，如下图1所示：