當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

干货 | Elasticsearch 可搜索快照深入详解

發布時間：2024/3/12 编程问答 37 豆豆

生活随笔收集整理的這篇文章主要介紹了干货 | Elasticsearch 可搜索快照深入详解小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

0、可搜索快照認知前提

Elasticsearch 可搜索快照是 7.10 版本才有的新功能，之前呼聲非常高。

Elastic 官方網站用一整頁面介紹，可見對該功能的重視。

https://www.elastic.co/cn/elasticsearch/elasticsearch-searchable-snapshots

但，有個細節要跟大家強調：該功能是企業版本才有的收費功能，黃金版、白金版、基礎免費開源版本都不具備該功能。

本文的相關實戰驗證，是基于 30 天試用版本做的驗證。

1、什么是可搜索快照？

講可搜索快照的定義前，先說一下大數據的存儲。

對于小微企業來講，硬件成本是產品、項目環節非常重要的考量因素。數據量的激增和項目的經費之間本來就是相生相克、相愛相殺的關系。

一方面：老板要控制成本的前提下滿足甲方的功能需求、性能需求且追求利潤最大化。

另一方面：開發人員為滿足性能指標最大程度的優化，多少會涉及提升硬件資源配置的需求，比如：換 SSD 磁盤、加內存或更換CPU。

老板會說：經費有限，給老子優化性能，盡一切可能滿足甲方的需求。
開發人員心里暗自嘀咕：不給老子提升資源配置，我優化個毛線。

當聽說字節跳動線上環境：最小 256 GB內存，多數都是 1TB 內存的時候，除了羨慕還是羨慕。

然后，說一下用戶的關注點。

拿大數據輿情場景，當前（此刻為：20210731）用戶關注的肯定是時下最熱新聞數據：奧運會。一年前的熱點：“馬老師，很快啊，不講武德等”即便當時家喻戶曉、婦孺皆知，現在看早已“打入冷宮”、“灰飛煙滅”，沒有了任何熱度可言。

熱數據——更多用戶關注的熱點數據。
冷數據——6個月或1年前（時間自己界定）的熱點數據。

熱數據、冷數據都要保存怎么辦？

一方面：要有足夠的磁盤資源，數百TB甚至PB級別磁盤。只有超大規模的企業才有如此財力和資源。

另一方面：劃分冷熱集群架構，讓高配硬件資源（如：SSD磁盤）用到刀刃（如：熱點數據）上，冷數據或者低頻數據考慮存儲到：NFS 磁盤陣列或者云廠商的OSS。

快照：是繼副本后保證集群數據高可用的利器。一般高可用的場景：除了副本至少設置為1，還要定期設置增量快照 snapshot。

設置快照的好處就在于：當集群故障時，即便數據丟失，也能通過快照的方式及時恢復。

我們在虛擬機集群 VSphere 中鼓弄虛擬機，一般都在適當的時機設置快照，這和 Elasticsearch 的增量快照是一樣的道理。

線上環境不出問題一般都相安無事，一般出現問題多半都和數據有關系，有了快照至少多了一份保障，運維人員會多一份心安。

但是，早期的快照就是“死數據”，是不支持搜索的，但這種使用頻次非常低的數據也是有搜索需求的。

傳統做法可能是：將很久之前的“冷”數據以快照方式存儲（副本設置為0，節約存儲），當需要檢索的時候，再由快照恢復到索引，實現檢索。

勢必，這會有較長的時間成本。

可搜索快照就在此大背景下應運而生的。

可搜索快照是指使用快照以極具成本效益的方式搜索不常訪問的只讀數據。冷數據層和凍結數據層（ cold and frozen data tiers ）使用可搜索的快照來降低存儲和運營成本。

可搜索快照消除了對副本分片的需求（副本默認設置為0），會將搜索數據所需的本地存儲減半?？伤阉骺煺找蕾囉谝延糜趥浞莸南嗤煺諜C制，并保障對快照存儲庫存儲成本的影響最小。

關于快照，如果您感覺不大熟悉或者沒有用過，推薦閱讀：

干貨 | Elasitcsearch7.X集群/索引備份與恢復實戰

2、可搜索快照適用場景

可搜索快照非常適合管理大量歷史歸檔數據。

歷史信息的搜索頻率通常低于最近的數據，因此可能不需要副本以獲得性能優勢。

對于更復雜或耗時的搜索，你可以將異步搜索與可搜索快照結合使用。

異步搜索推薦：

https://www.elastic.co/guide/en/elasticsearch/reference/current/async-search.html

3、可搜索快照的特點

以下三條內容來自官網文檔，為了保證原汁原味，我沒有任何刪減。3.1、3.2、3.3 要連起來讀完才能更好的理解可搜索快照的設計初衷和特點。

https://www.elastic.co/cn/elasticsearch/elasticsearch-searchable-snapshots

3.1 平衡存儲成本

時序數據以指數速度增長。而且，隨著數據對您的業務和運營方式的影響越來越大，存儲和搜索所有數據的成本可能會非常高。

數據層是一種集成的自動化數據生命周期管理方法，它可以幫助您平衡存儲成本。

3.2 管理數據生命周期

Elasticsearch 中的重要數據存儲在熱層中，用于快速搜索查詢。隨著數據越來越舊，它們變得不再重要，并且搜索的頻率也降低了，這些數據會被移動到由較低成本、較低性能的計算和存儲節點組成的溫層。

‘’當數據變得不太重要且為只讀時，會以快照形式將它們存儲在對象存儲（如 S3）中。但是，要搜索這類數據，需要進行恢復，無法立即進行搜索。

3.3 跳過手動恢復

引入可搜索快照這一功能為 S3 和其他對象存儲帶來全新的生命力：允許您直接搜索存儲在快照中的數據。

在冷層利用可搜索快照，您可以進一步降低多達一半的存儲成本，同時兼顧搜索性能。

這是通過將用于獲得彈性的數據與用于搜索的數據分開存儲來實現的，從而使您能夠平衡存儲成本和性能以滿足您的需求。

4、可搜索快照實戰

介紹兩種實現方式：手動掛載快照、ILM（索引生命周期管理）可搜索快照。

手動是基礎，理解了手動，再理解 ILM 自動管理可搜索快照會很容易。

4.1 手動掛載快照

4.1.1 步驟1：配置快照存儲路徑及注冊快照存儲庫

在elasticsearch中添加如下配置：

"path.repo:?"/www/elasticsearch_0713/elasticsearch-7.13.0/backup"

注冊快照存儲庫（即設置存儲路徑）

PUT?/_snapshot/my_repository {"type":?"fs","settings":?{"location":?"/www/elasticsearch_0713/elasticsearch-7.13.0/backup"} }

4.1.2 步驟2：為指定索引創建/拍攝快照

PUT?my_docs/_doc/1 {"title":?"just?testing" }PUT?/_snapshot/my_repository/snapshot_docs_index?wait_for_completion=true {"indices":?"my_docs","ignore_unavailable":?true,"include_global_state":?false }

前兩步中規中矩，都是之前創建非可搜索快照的套路。

也就是說：在沒有可搜索快照之前，要創建快照也得這么干。

4.1.3 步驟3：將快照掛載為可搜索的快照索引

這一步我們之前沒有見過，這一步就是可搜索快照最為核心的地方。

重中之重：要搜索快照，必須首先將其作為索引掛載到本地。

通常 ILM 會自動執行此操作，手動創建可搜索快照需要自己調用掛載快照 API（這點很重要，后面還會強調一次）。

POST?/_snapshot/my_repository/snapshot_docs_index/_mount?wait_for_completion=true {"index":?"my_docs",?"renamed_index":?"docs",?"index_settings":?{?"index.number_of_replicas":?0},"ignored_index_settings":?[?"index.refresh_interval"?]? }

挨個參數解讀一下：

index：必須設置，要掛載數據的快照中包含的索引的名稱。如果renamed_index不設置，該 index 將用以創建新索引。
renamed_index: 可選，將創建的索引的名稱。
index_settings: 掛載時應添加到索引中的設置。
ingored_index_settings:掛載時應從索引中刪除的設置。

執行結束，結果如下：

{"snapshot"?:?{"snapshot"?:?"snapshot_docs_index","indices"?:?["docs"],"shards"?:?{"total"?:?1,"failed"?:?0,"successful"?:?1}} }

這里的 my_docs 是快照里面的索引，不是外層的索引，也就是說：把 my_docs 索引（非快照里）刪除，上面的掛載操作照樣可以運行。

4.1.4 步驟4：掛載完畢后，執行快照搜索

被掛載后的索引是：docs?？梢阅盟推胀ㄋ饕粯邮褂?#xff0c;執行檢索操作即可。

GET?docs/_search

4.2 基于 ILM 索引生命周期管理實現自動掛載快照

以下實戰演練基于3節點 7.13.0 版本集群。

參見：https://www.elastic.co/guide/en/elasticsearch/reference/7.x/ilm-searchable-snapshot.html

4.2.1 步驟1：注冊快照存儲庫（即設置存儲路徑）

如下：在elasticsearch.yml 文件中配置。

"path.repo:?"/home/elasticsearch/elasticsearch-7.13.0/backup" PUT?/_snapshot/my_repository {"type":?"fs","settings":?{"location":?"/home/elasticsearch/elasticsearch-7.13.0/backup"} }

4.2.2 步驟2：設置ilm policy

測試需要，刷新值調的很小，實戰環境以需求為準。 PUT?_cluster/settings {"persistent":?{"indices.lifecycle.poll_interval":?"1s"} }#?cold?階段設置可搜索快照 PUT?_ilm/policy/my_custom_policy_filter {"policy":?{"phases":?{"hot":?{"actions":?{"rollover":?{"max_age":?"3d","max_docs":?5,"max_size":?"50gb"},"set_priority":?{"priority":?100}}},"warm":?{"min_age":?"15s","actions":?{"forcemerge":?{"max_num_segments":?1},"allocate":?{"require":?{"box_type":?"warm"},"number_of_replicas":?0},"set_priority":?{"priority":?50}}},"cold":?{"min_age":?"20s","actions":?{"allocate":?{"require":?{"box_type":?"cold"},"number_of_replicas":?0},"searchable_snapshot":?{"snapshot_repository":?"my_repository"}}}}} }

4.2.3 步驟3：創建模板，關聯配置的ilm_policy

PUT?_index_template/timeseries_template {"index_patterns":?["timeseries-*"],?????????????????"template":?{"settings":?{"number_of_shards":?1,"number_of_replicas":?0,"index.lifecycle.name":?"my_custom_policy_filter",??????"index.lifecycle.rollover_alias":?"timeseries","index.routing.allocation.require.box_type":?"hot"}} }

4.2.4 步驟4:創建起始索引（便于滾動）

PUT?timeseries-000001 {"aliases":?{"timeseries":?{"is_write_index":?true}} }

4.2.5：批量插入數據，驗證滾動和可搜索快照。

PUT?timeseries/_bulk {"index":{"_id":1}} {"title":"testing?01"} {"index":{"_id":2}} {"title":"testing?02"} {"index":{"_id":3}} {"title":"testing?03"} {"index":{"_id":4}} {"title":"testing?04"}PUT?timeseries/_bulk {"index":{"_id":5}} {"title":"testing?05"}#?#?臨界值（會滾動至下一個索引） PUT?timeseries/_bulk {"index":{"_id":6}} {"title":"testing?06"}

剛執行hot后的索引狀態：

執行完warm后：

執行cold后的索引狀態：

cold 階段：原來的timeseries-000001不再存在，形成可搜索快照。索引名稱前面加了前綴：restored-*，之前的索引名稱變成了別名。

相比于手動實現，不需要人為實現掛載環節，ILM自動后臺實現。

這點，官方文檔也有強調：“Usually ILM will do this automatically, but you can also call the mount snapshot API yourself. ”。

到了這一步，下面就可以對可搜索快照進行檢索了：

#?基于可搜索快照索引檢索 POST?restored-timeseries-000001/_search #?基于別名檢索 POST?timeseries/_search POST?timeseries-000001/_search

5、可搜索快照的工作原理

當從快照掛載索引時，Elasticsearch 將其分片分配給集群內的數據節點。然后，數據節點根據指定的掛載選項自動從存儲庫檢索相關分片數據到本地存儲。如果可能，搜索使用本地存儲中的數據。如果數據在本地不可用，Elasticsearch 會從快照存儲庫找它需要的數據。

如果持有這些分片之一的節點出現故障，Elasticsearch 會自動將受影響的分片分配到另一個節點上，并且該節點從存儲庫中恢復相關的分片數據。不需要副本，也不需要復雜的監控或處理來恢復丟失的分片。

盡管默認情況下可搜索快照索引沒有副本，但仍可以通過調整 index.number_of_replicas 將副本添加到這些索引中。可搜索快照分片的副本通過從快照存儲庫復制數據來恢復，就像可搜索快照分片的主分片一樣。相比之下，常規索引的副本是通過從主數據庫復制數據來恢復的。

6、可搜索快照常見問題？

6.1 如何區分正常索引和可搜索快照索引

ILM 實現的話，看名字，前綴為：restored_*。
手動實現的場景的確不多，自己控制就可以，也可以參考ILM 的實現，設置 renamed_index 的名稱。

6.2 除了掛載，還有哪些靠譜API？

獲取快照緩存詳情

GET?/_searchable_snapshots/cache/stats

檢索有關可搜索快照的統計信息

GET?/_searchable_snapshots/stats

清理可搜索快照的緩存

POST?/_searchable_snapshots/cache/clear

7、小結

實戰出真知。本文講解了可搜索快照的產生背景、定義、適用場景、特點、工作原理、兩種方式實戰演練以及常見問題與解答，但這些都是可搜索快照基礎內容的冰山一角。

可搜索快照還有很多細節問題待實戰驗證、討論。

歡迎大家就可搜索快照問題留言交流。

8、參考

https://www.elastic.co/guide/en/elasticsearch/reference/master/searchable-snapshots-apis.html

https://www.elastic.co/guide/en/elasticsearch/reference/7.13/ilm-searchable-snapshot.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/searchable-snapshots.html