導語 | 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 帶來革命性的變革！