Elasticsearch可搜索快照是如何辦到大幅降低存儲成本的

Elasticsearch可搜索快照是如何辦到大幅降低存儲成本的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

一、功能介紹

在 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 中去查詢數據，真正做到按需加載。查詢完畢后，此次查詢而加載的內存數據將會自動釋放，不僅節省了大量的存儲成本，也因為集群的規模可以變得非常小而使得集群的穩定性大大地提高。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。