Elasticsearch：Searchable Snapshot（可搜尋快照）

使用限制

• 僅新購的訂用帳戶Elasticsearch 8.17.0版執行個體支援可搜尋快照功能。

• Searchable Snapshot 索引為唯讀，不支援寫入操作。

• 首次查詢延遲高於熱資料（取決於 OSS 網路延遲），快取命中後效能接近本機資料。

開通歸檔資料節點

使用 Searchable Snapshot 前，需要為 Elasticsearch 執行個體開通歸檔資料節點。歸檔資料節點是 Searchable Snapshot 的計算層，負責維護索引中繼資料、管理本機快取，並按需從 OSS 拉取查詢所需的資料區塊。

1. 登入檢索分析服務 Elasticsearch 版控制台。

2. 根據執行個體情況選擇對應的操作路徑：

   • 新購 8.17.0 版本執行個體：在建立執行個體頁面選擇 8.17.0 版本，在執行個體規格地區勾選歸檔數據節點並配置節點數量和規格。

3. 選擇節點規格。

   歸檔資料節點不需要大容量本地磁碟（資料存放區在 OSS 中），建議配置充足的記憶體以提升快取命中率。推薦配置：4 核 16 GB 及以上，磁碟 500 GB 以上（高效雲端硬碟或 ESSD 雲端硬碟）。

4. 購買並等待執行個體變更完成。歸檔資料節點就緒後，Searchable Snapshot 功能預設開啟，無需額外操作。

配置 OSS Snapshot 倉庫

阿里雲 Elasticsearch 內建 repository-oss 外掛程式，可直接將 OSS 用作 Snapshot 倉庫，無需手動安裝外掛程式。

在 Kibana Dev Tools 中執行以下命令註冊 OSS Snapshot 倉庫：

PUT _snapshot/my_oss_repo
{
  "type": "oss",
  "settings": {
    "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
    "access_key_id": "<your_access_key_id>",
    "secret_access_key": "<your_secret_access_key>",
    "bucket": "<your_bucket_name>",
    "base_path": "es_snapshots",
    "compress": true,
    "chunk_size": "500mb"
  }
}

驗證倉庫連通性：

POST _snapshot/my_oss_repo/_verify

返回成功且列出了叢集中的節點，這說明叢集中的相關節點已經成功串連到了 OSS 儲存，並且擁有讀寫權限。OSS 外掛程式完整參數說明參見 elasticsearch-repository-oss。

建立快照並掛載

PUT _snapshot/my_oss_repo/snapshot_20260227
{
  "indices": "logs-2025-*",
  "ignore_unavailable": true,
  "include_global_state": false
}

GET _snapshot/my_oss_repo/snapshot_20260227/_status

POST logs-2025-01-01/_doc
{ "message": "test log data 01", "level": "info", "timestamp": "2025-01-01T10:00:00" }

POST logs-2025-01-02/_doc
{ "message": "test log data 02", "level": "warn", "timestamp": "2025-01-02T10:00:00" }

POST logs-2025-01-03/_doc
{ "message": "test log data 03", "level": "error", "timestamp": "2025-01-03T10:00:00" }

POST logs-2025-01-04/_doc
{ "message": "test log data 04", "level": "info", "timestamp": "2025-01-04T10:00:00" }

POST logs-2025-01-05/_doc
{ "message": "test log data 05", "level": "debug", "timestamp": "2025-01-05T10:00:00" }

POST _snapshot/my_oss_repo/snapshot_20260227/_mount?storage=shared_cache&wait_for_completion=true
{
  "index": ".ds-logs-2025-01-01-2026.03.03-000001",
  "renamed_index": "frozen-logs-2025-01-01",
  "index_settings": {
    "index.number_of_replicas": 0
  },
  "ignore_index_settings": ["index.refresh_interval"]
}

GET frozen-logs-2025-01-01/_search
{
  "query": {
    "match": {
      "message": "error"
    }
  }
}

GET logs-2025-*,frozen-logs-2025-*/_search
{
  "query": {
    "range": {
      "timestamp": {
        "gte": "2025-01-01",
        "lt": "2025-02-01"
      }
    }
  }
}

DELETE frozen-logs-2025-01-01

POST _snapshot/my_oss_repo/snapshot_20260227/_restore
{
  "indices": ".ds-logs-2025-01-01-2026.03.03-000001",
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1"
}

通過 ILM 自動化管理資料生命週期

推薦使用 Index Lifecycle Management（ILM）策略自動將索引遷移到 Frozen Tier。以下策略實現 Hot → Warm → Frozen → Delete 的完整生命週期，索引進入 Frozen 階段時 ILM 自動建立快照到 OSS 並以 Partially Mounted 模式掛載，無需人工幹預：

PUT _ilm/policy/logs_lifecycle_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 }
        }
      },
      "frozen": {
        "min_age": "90d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_oss_repo"
          }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

生命週期階段總覽：

工作原理

Searchable Snapshot 採用存算分離架構，由歸檔資料節點（計算層）和阿里雲 OSS（儲存層）協同工作：

• 阿里雲 OSS 是持久化儲存層，承擔 Snapshot Repository 的角色。所有快照資料全量儲存在 OSS 中，藉助 OSS 自身的多副本冗餘機制保障資料可靠性，無需在 Elasticsearch 層維護副本分區。

• 歸檔資料節點 是計算層，負責接收查詢請求並協調資料訪問。節點內部包含三個關鍵組件：

  • Metadata（中繼資料）：記錄索引結構與分區映射資訊，維護 Searchable Snapshot 索引的邏輯視圖。

  • Shared Cache（共用快取）：緩衝近期查詢過的熱點資料區塊，同一節點上所有 Searchable Snapshot 索引的分區共用此緩衝。

  • Query Engine（查詢引擎）：接收查詢請求，判斷快取命中情況，未命中時從 OSS 按需拉取資料區塊。

資料流轉路徑分為寫入和查詢兩個方向：

• 寫入方向：通過手動操作或 ILM 策略，將到期索引建立快照並推送到 OSS。掛載時使用 storage=shared_cache 參數以 Partially Mounted 模式掛載，資料留在 OSS，歸檔資料節點僅載入中繼資料。

• 查詢方向：歸檔資料節點首先檢查本地共用快取是否命中所需資料區塊。命中時直接返回結果，效能接近本機資料；未命中時從 OSS 按需拉取對應資料區塊，返回查詢結果的同時將資料寫入緩衝供後續複用。

共用快取預設大小為節點總磁碟空間的 90%（或總空間減 100 GB，取較小值），採用 LRU（最近最少使用）策略淘汰冷資料區塊。

Elasticsearch 將資料按訪問頻率劃分為多個層級，Searchable Snapshot 服務於其中成本最低的 Frozen Tier（歸檔資料層）：

Searchable Snapshot 通過以下機制實現降本：

• 消除副本分區：資料可靠性由 OSS 多副本機制保障，無需在 Elasticsearch 層維護副本分區，降低 50% 儲存成本，同時消除跨可用性區域資料同步的流量費用。

• 存算分離：資料全量儲存在 OSS 中，OSS 單價遠低於雲端硬碟儲存（價差可達 10 倍以上），歸檔資料節點僅儲存中繼資料和熱點緩衝。

• 極高的資料密度比：歸檔資料節點可實現 1:1500 的記憶體與資料量之比。一個 64 GB 記憶體的節點可管理約 100 TB 歸檔資料，相同資源在 Warm Tier 僅能承載約 10 TB。

適用情境

• 日誌歸檔：將超過一定時間的日誌從 Hot/Warm 層遷移至 Frozen 層，保持可查詢的同時降低儲存成本。

• 合規審計：以極低成本長期保留監管要求的業務資料，支援按需檢索。

• 歷史資料分析：偶爾需要回溯分析的歷史業務資料，無需長期佔用 SSD 儲存資源。

相關文檔

• Elasticsearch Searchable Snapshots 官方文檔

• Mount Snapshot API

• ILM Searchable Snapshot Action

• 阿里雲 OSS Snapshot 倉庫外掛程式

• ES執行個體節點配置說明