elasticsearch索引管理知识点总结(elasticsearch设计减少内存使用)

对于许多新手来说，弹性搜索可搜索快照如何大大降低存储成本尚不清楚。为了帮助大家解决这个问题，下面小编就详细讲解一下。需要的人可以从中学习，希望你能有所收获。

一、功能介绍

在可搜索快照功能发布之前，通过调用_snapshot API获取的索引快照，无论是存储在HDFS S3还是腾讯云的对象存储COS，都无法直接查询。

快照只能用于数据的冷备份。如果要查询，需要先调用API将快照还原到集群中，初始化快照中的索引后再进行查询。

可搜索快照功能使存储在远程S3、HDFS和COS中的快照能够满足查询要求。es的数据文件不仅可以存储在本地文件系统中，还可以存储在远程的S3、HDFS、COS等存储介质中，实际上实现了存储和计算的分离。

可搜索快照可搜索快照功能有望为ES带来新的繁荣，因为很多用户使用ELK架构构建日志系统。日志数据量很大，但查询频率普遍较低，因此用户的痛点是在满足基本查询需求的同时降低ES的存储成本。

现在，基于可搜索快照功能，大量较旧的索引可以存储在S3/COS中，当您真正需要查询时，可以在S3/COS中查询数据。因为S3/COS本身成本很低，大约是SSD磁盘的十分之一，所以使用ES存储数据的成本大大降低。

另一方面，可搜索快照功能也可以提高集群的稳定性。只能用小规模集群来支持最近一段时间热门索引的读写。旧的索引可以存储在S3/COS中，当您真正需要查询时，可以在S3/COS中检查数据。由于集群规模较小，超大型集群不会存储所有数据，会导致集群不稳定。

然而，就当前7.10版本中的可搜索快照功能的特性而言，我们没有想到存储和计算会完全分离。

因为当存储在S3/COS中的快照装载到群集时，有必要首先执行快照恢复，并将快照中的文件从S3/COS读取到群集的本地磁盘。快照中的索引首先初始化，索引中的所有数据文件恢复后，索引变为绿色。

这似乎与从快照手动恢复索引没有什么不同。不同之处在于，当可以搜索可搜索快照时，在快照恢复过程中仍然可以查询索引。如果集群本地磁盘上的索引文件不存在，可以直接在S3/COS中读取，但读取过程会很慢。

为什么需要先将数据文件从S3/COS恢复到本地？官方的解释是这样可以保证查询性能。可搜索快照中的索引完全初始化后，读取索引和读取普通索引几乎没有区别。事实上，可搜索快照类型的索引在群集的本地磁盘上存储了一个完整的数据文件，但是命名规则不同于普通索引。

由于当前7.10版本的可搜索快照功能，数据需要从S3/COS恢复到集群的本地磁盘并缓存，因此该功能的真正用途是可以节省多达一半的存储空间。

集群中可搜索快照索引的默认副本数为0，数据的可靠性和弹性完全由S3/COS保证，因此无需在索引中添加额外的副本，可以将存储成本降低一半。

当集群中可搜索快照索引的碎片因节点故障而不可用时，ES会自动从S3/COS读取碎片对应的数据文件进行恢复，从而保证数据的可靠性；如果需要增加可搜索快照索引的副本数量，还需要直接从S3/COS读取数据，而不是从本地磁盘复制主切片的数据文件。

使用当前版本的可搜索快照功能，我们可以先将一些查询频率非常低的旧索引备份到S3/COS，然后删除它们，然后将备份的快照装载到集群中，这样在需要时仍然可以查询这些索引。

在极端情况下，实际上您只需要以非常低的查询频率备份这些旧索引，然后在真正需要查询时将它们装载到集群上。当然，您需要容忍缓慢的查询过程。

当前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 中去查询数据，真正做到按需加载。查询完毕后，此次查询而加载的内存数据将会自动释放，不仅节省了大量的存储成本，也因为集群的规模可以变得非常小而使得集群的稳定性大大地提高。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。