共计 4643 个字符，预计需要花费 12 分钟才能阅读完成。
导语 | Elasticsearch 7.10 版本最近公布，该版本有一个重磅个性：Searchable snapshots（可搜寻快照性能），能够大幅度地升高存储老本。那么 Searchable snapshots 的应用形式和实现成果是怎么的呢，上面就让咱们来一探到底吧！本文作者：高斌龙，腾讯云大数据研发工程师。
一、性能介绍
在 Searchable snapshots 可搜寻快照性能公布之前，通过调用 _snapshot API 对索引打的快照，不论是存储在 S3 还是 HDFS 或者是腾讯云的对象存储 COS 上，都是不可能间接进行查问的。
快照只能用于数据的冷备份，如果要查问的话须要先调用 API 把快照复原到集群中，当快照中的索引初始化实现后，才能够去查问。
而可搜寻快照性能就使得存储在远端 S3、HDFS、COS 中的快照可能满足查问的需要了，ES 的数据文件不是只能存储在本地文件系统上，还能够反对存储在远端的 S3、HDFS、COS 等存储介质上，实际上实现了存储与计算的拆散。
Searchable snapshots 可搜寻快照性能预计会给 ES 带来新的凋敝，因为有十分多的用户应用 ELK 架构构建日志零碎。日志的数据量是十分大的，然而查问的频率个别比拟低，所以用户的痛点是：在满足根本查问需要的条件下同时升高 ES 的存储老本。
当初基于 Searchable snapshots 可搜寻快照性能，能够把大量的比拟旧的索引都存储到 S3/COS 上，真正须要查问的时候能够去查问 S3/COS 中的数据。因为 S3/COS 自身老本是非常低的，大概只有 SSD 磁盘的十分之一，所以应用 ES 存储数据的老本大大降低了。
另外一方面，可搜寻快照性能也能够进步集群的稳定性，能够仅仅应用一个较小规模的集群撑持最近一段时间热索引的读写即可，老的索引都能够寄存在 S3/COS 中，真正须要查问的时候再去查 S3/COS 中的数据，因为集群规模小，不至于呈现一个超大规模的集群存储所有的数据，从而导致集群不稳固的景象产生。
不过就以后 7.10 版本的可搜寻快照性能的特点来看，没有咱们料想的能够齐全实现存储计算拆散。
因为当把一个存储在 S3/COS 上的快照 mount 到一个集群中时，须要先执行快照复原，把快照中的文件从 S3/COS 读取到集群的本地磁盘上，快照中的索引先进行初始化，索引所有的数据文件复原结束后该索引才变为 green。
看起来和咱们手动去从快照中复原索引没有什么两样，区别在于 Searchable snapshots 可搜寻快照性能时，在执行快照复原的这段过程中索引依然是能够查问的。如果集群本地磁盘上的索引文件不存在的话就间接去 S3/COS 中去读，只不过读的过程会比较慢。
而为什么须要先把数据文件从 S3/COS 复原到本地呢？官网的解释是这样能够保障查问性能，在一个可搜寻快照中的索引齐全初始化实现后，读取该索引和读取一般的索引的性能简直没有差异。实际上可搜寻快照类型的索引在集群的本地磁盘上寄存了残缺的一份数据文件，只不过命名规定和一般的索引不一样。
因为以后 7.10 版本的可搜寻快照性能，数据还须要从 S3/COS 中复原到集群的本地磁盘上缓存一份，所以该性能真正的用途在于能够节俭最多一半的存储空间。
可搜寻快照类型的索引在集群中默认正本数为 0，数据的可靠性以及弹性齐全交由 S3/COS 来保障，不须要额定给索引减少正本，从而能够升高一半的存储老本。
当集群中可搜寻快照类型的索引的分片因为节点故障不可用时，ES 会主动地从 S3/COS 中读取分片对应的数据文件进行复原，从而保证数据的可靠性；如果须要进步可搜寻快照类型的索引的正本数量，也是间接从 S3/COS 中读取数据，而不是从本地磁盘上复制主分片的数据文件。
利用以后版本的可搜寻快照性能，咱们能够对一些老的查问频率非常低的索引，先备份到 S3/COS，之后删除，而后再把备份好的快照 mount 到集群中，使得这些索引下须要的时候依然能够查问。
在极其状况下，实际上只须要对这些老的查问频率非常低的索引，只进行备份，真正须要查问的时候再 mount 到集群上，当然，须要容忍迟缓的查问过程。
以后 7.10 版本的可搜寻快照性能的为 Beta 版，社区里也给出了该性能的路线图，会在未来的版本中实现齐全的计算存储拆散，间接去拜访 S3/COS 中的索引数据实现查问, 而不是像以后这个版本须要先复原到本地磁盘中。
所以总的来说，以后 7.10 版本的可搜寻快照性能，一方面能够升高一半左右的存储空间，大大的节俭了老本；另外一方面保障了从快照中复原到集群上的索引的查问性能，使得应用层不用感知到这种新的存储形式带来的变动。
二、应用形式
可搜寻快照的应用形式比较简单，咱们能够抉择通过手动调用 API 来把远端的快照 mount 到集群中，也能够在 ILM 中 应用。
1. 手动 mount 快照
间接调用 API:
POST /_snapshot/my_repository/my_snapshot/_mount?wait_for_completion=true
{
"index": "test",
"renamed_index": "test1",
"index_settings": {"index.number_of_replicas": 0},
"ignored_index_settings": ["index.refresh_interval"]
}上述操作把快照 my_snapshot 中的 test 索引挂载到集群中，重命名为 test1, 挂载后的索引正本数设置为 0，同时疏忽掉旧索引中设置的 index.refresh_interval 参数。
在执行完上述操作后，能够看到集群中呈现了一个新的索引 test1, 集群以后状态为 yellow，test 索引的分片执行初始化，初始化实现后，test1 索引状态变为 green。
此时查看新索引 test1 的 settings，发现其和一般的索引有以下不同点：
{
"test1":{
"settings":{
"index": {
"blocks":{"write":"true"},
"recovery":{"type":"snapshot_prewarm"},
"store":{
"type":"snapshot",
"snapshot":{
"snapshot_name":"test",
"index_uuid":"p1Opq7gdQz6WTeKgiIEaTw",
"index_name":"test-aggregation-2020-11-25-02",
"repository_name":"my_repository2",
"snapshot_uuid":"Muy7vsiLSWKbQf3mJALfLw"
}
}
}
}
}
}- index.blocks.write 默认为 true，也即可搜寻快照索引默认是只读的；
- index.recovery.type 为 snapshot_prewarm, 意味着数据是从快照中复原的；
- index.store.type 为 snapshot，区别于一般索引的 fs 形式。
另外须要留神的是，索引 test1 复原到 green 后，除了索引的局部元数据和底层的数据文件命名形式与一般的索引不同，索引本身的一些数据结构如 FST 也是常驻内存的，并不会在查问结束后主动开释掉内存，所以此时曾经和一般的索引区别不大了。当然，新索引 test1 也是能够解冻的，解冻的执行过程和一般的索引雷同。
2. 在 ILM 中应用
在 ILM 索引生命周期治理中也能够应用可搜寻快照性能，通过 API 应用该性能的根本用法如下：
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"cold": {
"actions": {
"searchable_snapshot" : {
"snapshot_repository" : "my_repository",
"force_merge_index": true
}
}
}
}
}
}对于应用上述 ILM 策略的索引，在 cold phase 会首先把该索引备份到指定的快照仓库 my_repository 中，而后再把快照中的索引挂载为一个可搜寻快照的索引。
应用过程中须要留神以下几点：
- 可搜寻快照只能在 cold phase 应用；
- 如果 ILM 策略有配置 delete phase，默认状况下，在 delete phase 会被动删除 cold phase 中的可搜寻快照, 因而须要在 delete phase 中显式设置 delete_searchable_snapshot 为 false；
- 默认状况下 force_merge_index 为 true, 也即在索引进入到 cold phase 时，会先把索引 force merge 到 1 个 segment，而后再备份到快照仓库中。此举一方面是为了升高存储到 S3/COS 上的存储老本，同时升高后续从 S3/COS 中拉取数据时的产生的费用，文件越少读取 S3/COS 产生的费用就越低；另外一方面当数据从 S3/COS 复原到本地后，也能够取得较好的查问性能。
比拟遗憾的是，在以后 7.10 版本中，还不反对间接在 kibana 的索引生命周期治理页面中通过操作界面间接应用可搜寻快照性能。
三、将来瞻望
Searchable snapshots 可搜寻快照性能，在以后 Beta 版本中，依然须要把存储在远端 S3/COS 中的数据恢复到本地缓存起来，所以能够节俭的存储老本是无限的。所以，官网也给出了可搜寻快照性能的路线图：
联合 Data tiers 数据分层性能咱们看到，以后 Beta 版的可搜寻快照是用在数据分层的 Cold 层，在该层中的索引个别是只读的，然而依然须要保障肯定的查问性能。
所以在 Cold 层能够把数据先从 S3/COS 中复原到集群的本地磁盘上，做一层缓存，查问索引的时候优先从本地缓存中读取，这样查问性能就有了保障。
然而数据的可靠性或者弹性能够齐全由 S3/COS 来保障，因而在 Cold 层中的索引，能够只保留主分片，当主分片所在的节点故障时能够从远端的 S3/COS 中复原数据，这样存储老本就升高了一半。
而官网将来的布局，是要开发 Frozen 层，在该层中的索引，对查问性能没有较高的要求，因而能够间接去查问 S3/COS 中的数据，而不须要再把数据从 S3/COS 中复原到本地缓存起来。
因而在 Frozen 层，才真正实现了存储与计算的拆散，带来的影响是不可估量的，因为一个集群可能撑持的数据存储量能够无限大，用户的老本能够大大的升高。
然而，在 Frozen 层，间接去查问存储在 S3/COS 上的数据，查问性能就齐全取决于 S3/COS 的 API 接口的性能，可能会造成查问过程十分迟缓。
而在新近的版本中，ES 曾经实现了异步查问 Async search, 提交查问申请时只返回一个 ID, 后续通过轮询这个 ID 获取到查问后果，在轮询过程中能够获取到查问的局部后果，直至查问后果齐全返回。因而 Async search 就解决了在 Frozen 层因为查问数据迟缓带来的的体验成果不好的问题。
所以，在未来 Frozen 层开发实现之后，咱们能够借助于齐全实现存储于计算拆散的可搜寻快照性能，依据须要从 S3/COS 中去查问数据，真正做到按需加载。查问结束后，此次查问而加载的内存数据将会主动开释，不仅节俭了大量的存储老本，也因为集群的规模能够变得十分小而使得集群的稳定性大大地进步。
总的来说，不光是 Searchable sanpshots 性能，还有 Data tiers 数据分层性能，都还在逐步演进的路上，两者联合起来，将会给 Elasticsearch 带来革命性的改革！
