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

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

成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供萬州企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計、做網(wǎng)站、成都外貿(mào)網(wǎng)站建設(shè)公司、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為萬州眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進(jìn)行中。

一、功能介紹

在 Searchable snapshots 可搜索快照功能發(fā)布之前，通過調(diào)用 _snapshot API 對索引打的快照，不管是存儲在 S3 還是 HDFS 或者是騰訊云的對象存儲 COS上，都是不能夠直接進(jìn)行查詢的。

快照只能用于數(shù)據(jù)的冷備份，如果要查詢的話需要先調(diào)用 API 把快照恢復(fù)到集群中，當(dāng)快照中的索引初始化完成后，才可以去查詢。

而可搜索快照功能就使得存儲在遠(yuǎn)端 S3、HDFS、COS 中的快照能夠滿足查詢的需求了，ES 的數(shù)據(jù)文件不是只能存儲在本地文件系統(tǒng)上，還可以支持存儲在遠(yuǎn)端的 S3、HDFS、COS 等存儲介質(zhì)上，實際上實現(xiàn)了存儲與計算的分離。

Searchable snapshots 可搜索快照功能預(yù)計會給 ES 帶來新的繁榮，因為有非常多的用戶使用 ELK 架構(gòu)構(gòu)建日志系統(tǒng)。日志的數(shù)據(jù)量是非常大的，但是查詢的頻率一般比較低，所以用戶的痛點是：在滿足基本查詢需求的條件下同時降低 ES 的存儲成本。

現(xiàn)在基于 Searchable snapshots 可搜索快照功能，可以把大量的比較舊的索引都存儲到 S3/COS 上，真正需要查詢的時候可以去查詢 S3/COS 中的數(shù)據(jù)。因為 S3/COS 本身成本是非常低的，大約只有 SSD 磁盤的十分之一，所以使用 ES 存儲數(shù)據(jù)的成本大大降低了。

另外一方面，可搜索快照功能也可以提高集群的穩(wěn)定性，可以僅僅使用一個較小規(guī)模的集群支撐最近一段時間熱索引的讀寫即可，老的索引都可以存放在 S3/COS 中，真正需要查詢的時候再去查 S3/COS 中的數(shù)據(jù)，因為集群規(guī)模小，不至于出現(xiàn)一個超大規(guī)模的集群存儲所有的數(shù)據(jù)，從而導(dǎo)致集群不穩(wěn)定的現(xiàn)象發(fā)生。

不過就當(dāng)前 7.10 版本的可搜索快照功能的特點來看，沒有我們預(yù)想的可以完全實現(xiàn)存儲計算分離。

因為當(dāng)把一個存儲在 S3/COS 上的快照 mount 到一個集群中時，需要先執(zhí)行快照恢復(fù)，把快照中的文件從 S3/COS 讀取到集群的本地磁盤上，快照中的索引先進(jìn)行初始化，索引所有的數(shù)據(jù)文件恢復(fù)完畢后該索引才變?yōu)?green。

看起來和我們手動去從快照中恢復(fù)索引沒有什么兩樣，區(qū)別在于 Searchable snapshots 可搜索快照功能時，在執(zhí)行快照恢復(fù)的這段過程中索引仍然是可以查詢的。如果集群本地磁盤上的索引文件不存在的話就直接去 S3/COS 中去讀，只不過讀的過程會比較慢。

而為什么需要先把數(shù)據(jù)文件從 S3/COS 恢復(fù)到本地呢？官方的解釋是這樣可以保證查詢性能，在一個可搜索快照中的索引完全初始化完成后，讀取該索引和讀取普通的索引的性能幾乎沒有差別。實際上可搜索快照類型的索引在集群的本地磁盤上存放了完整的一份數(shù)據(jù)文件，只不過命名規(guī)則和普通的索引不一樣。

因為當(dāng)前 7.10 版本的可搜索快照功能，數(shù)據(jù)還需要從 S3/COS 中恢復(fù)到集群的本地磁盤上緩存一份，所以該功能真正的用處在于可以節(jié)省最多一半的存儲空間。

可搜索快照類型的索引在集群中默認(rèn)副本數(shù)為 0， 數(shù)據(jù)的可靠性以及彈性完全交由 S3/COS 來保證，不需要額外給索引增加副本，從而可以降低一半的存儲成本。

當(dāng)集群中可搜索快照類型的索引的分片因為節(jié)點故障不可用時， ES 會自動地從 S3/COS 中讀取分片對應(yīng)的數(shù)據(jù)文件進(jìn)行恢復(fù)，從而保證數(shù)據(jù)的可靠性；如果需要提高可搜索快照類型的索引的副本數(shù)量，也是直接從 S3/COS 中讀取數(shù)據(jù)，而不是從本地磁盤上復(fù)制主分片的數(shù)據(jù)文件。

利用當(dāng)前版本的可搜索快照功能，我們可以對一些老的查詢頻率非常低的索引，先備份到 S3/COS，之后刪除，然后再把備份好的快照 mount 到集群中，使得這些索引下需要的時候仍然可以查詢。

在極端情況下，實際上只需要對這些老的查詢頻率非常低的索引，只進(jìn)行備份，真正需要查詢的時候再 mount 到集群上，當(dāng)然，需要容忍緩慢的查詢過程。

當(dāng)前 7.10 版本的可搜索快照功能的為 Beta 版，社區(qū)里也給出了該功能的路線圖，會在將來的版本中實現(xiàn)完全的計算存儲分離，直接去訪問 S3/COS 中的索引數(shù)據(jù)完成查詢, 而不是像當(dāng)前這個版本需要先恢復(fù)到本地磁盤中。

所以總的來說，當(dāng)前 7.10 版本的可搜索快照功能，一方面可以降低一半左右的存儲空間，大大的節(jié)省了成本；另外一方面保證了從快照中恢復(fù)到集群上的索引的查詢性能，使得應(yīng)用層不必感知到這種新的存儲方式帶來的變化。

二、使用方式

可搜索快照的使用方式比較簡單，我們可以選擇通過手動調(diào)用 API 來把遠(yuǎn)端的快照 mount 到集群中，也可以在 ILM中 使用。

1. 手動mount快照

直接調(diào)用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, 掛載后的索引副本數(shù)設(shè)置為 0， 同時忽略掉舊索引中設(shè)置的 index.refresh_interval 參數(shù)。

在執(zhí)行完上述操作后，可以看到集群中出現(xiàn)了一個新的索引 test1, 集群當(dāng)前狀態(tài)為 yellow，test 索引的分片執(zhí)行初始化，初始化完成后，test1 索引狀態(tài)變?yōu)?green。

此時查看新索引 test1 的 settings，發(fā)現(xiàn)其和普通的索引有以下不同點：

{
    "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 默認(rèn)為 true，也即可搜索快照索引默認(rèn)是只讀的；

• index.recovery.type 為 snapshot_prewarm, 意味著數(shù)據(jù)是從快照中恢復(fù)的；

• index.store.type 為 snapshot，區(qū)別于普通索引的 fs 方式。

另外需要注意的是，索引 test1 恢復(fù)到 green 后，除了索引的部分元數(shù)據(jù)和底層的數(shù)據(jù)文件命名方式與普通的索引不同，索引自身的一些數(shù)據(jù)結(jié)構(gòu)如 FST 也是常駐內(nèi)存的，并不會在查詢完畢后自動釋放掉內(nèi)存，所以此時已經(jīng)和普通的索引區(qū)別不大了。當(dāng)然，新索引test1也是可以凍結(jié)的，凍結(jié)的執(zhí)行過程和普通的索引相同。

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， 默認(rèn)情況下，在 delete phase 會主動刪除 cold phase 中的可搜索快照, 因此需要在 delete phase 中顯式設(shè)置 delete_searchable_snapshot 為 false；

• 默認(rèn)情況下 force_merge_index 為 true, 也即在索引進(jìn)入到 cold phase 時，會先把索引 force merge 到 1 個 segment，然后再備份到快照倉庫中。此舉一方面是為了降低存儲到 S3/COS 上的存儲成本，同時降低后續(xù)從 S3/COS 中拉取數(shù)據(jù)時的產(chǎn)生的費用，文件越少讀取 S3/COS 產(chǎn)生的費用就越低；另外一方面當(dāng)數(shù)據(jù)從 S3/COS 恢復(fù)到本地后，也可以獲得較好的查詢性能。

比較遺憾的是，在當(dāng)前 7.10 版本中，還不支持直接在 kibana 的索引生命周期管理頁面中通過操作界面直接使用可搜索快照功能。

三、未來展望

Searchable snapshots 可搜索快照功能，在當(dāng)前 Beta 版本中，仍然需要把存儲在遠(yuǎn)端 S3/COS 中的數(shù)據(jù)恢復(fù)到本地緩存起來，所以可以節(jié)省的存儲成本是有限的。所以，官方也給出了可搜索快照功能的路線圖：

結(jié)合 Data tiers 數(shù)據(jù)分層功能我們看到，當(dāng)前 Beta 版的可搜索快照是用在數(shù)據(jù)分層的 Cold 層，在該層中的索引一般是只讀的，但是仍然需要保證一定的查詢性能。

所以在 Cold 層可以把數(shù)據(jù)先從 S3/COS 中恢復(fù)到集群的本地磁盤上，做一層緩存，查詢索引的時候優(yōu)先從本地緩存中讀取，這樣查詢性能就有了保證。

但是數(shù)據(jù)的可靠性或者彈性可以完全由 S3/COS 來保證，因此在 Cold 層中的索引，可以只保留主分片，當(dāng)主分片所在的節(jié)點故障時可以從遠(yuǎn)端的 S3/COS 中恢復(fù)數(shù)據(jù)，這樣存儲成本就降低了一半。

而官方未來的規(guī)劃，是要開發(fā) Frozen 層，在該層中的索引，對查詢性能沒有較高的要求，因此可以直接去查詢 S3/COS 中的數(shù)據(jù)，而不需要再把數(shù)據(jù)從 S3/COS 中恢復(fù)到本地緩存起來。

因此在 Frozen 層，才真正實現(xiàn)了存儲與計算的分離，帶來的影響是不可估量的，因為一個集群能夠支撐的數(shù)據(jù)存儲量可以無限大，用戶的成本可以大大的降低。

然而，在 Frozen 層，直接去查詢存儲在 S3/COS 上的數(shù)據(jù)，查詢性能就完全取決于 S3/COS 的 API 接口的性能，可能會造成查詢過程非常緩慢。

而在早先的版本中，ES 已經(jīng)實現(xiàn)了異步查詢 Async search, 提交查詢請求時只返回一個 ID, 后續(xù)通過輪詢這個 ID 獲取到查詢結(jié)果，在輪詢過程中可以獲取到查詢的部分結(jié)果，直至查詢結(jié)果完全返回。因此 Async search 就解決了在 Frozen 層因為查詢數(shù)據(jù)緩慢帶來的的體驗效果不好的問題。

所以，在將來 Frozen 層開發(fā)完成之后，我們可以借助于完全實現(xiàn)存儲于計算分離的可搜索快照功能，根據(jù)需要從 S3/COS 中去查詢數(shù)據(jù)，真正做到按需加載。查詢完畢后，此次查詢而加載的內(nèi)存數(shù)據(jù)將會自動釋放，不僅節(jié)省了大量的存儲成本，也因為集群的規(guī)?？梢宰兊梅浅Ｐ《沟眉旱姆€(wěn)定性大大地提高。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。

當(dāng)前文章：Elasticsearch可搜索快照是如何辦到大幅降低存儲成本的
文章出自：http://muchs.cn/article16/ispddg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、ChatGPT、商城網(wǎng)站、小程序開發(fā)、App開發(fā)、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)