深度剖析：可搜索快照性能测试报告

通过利用Elastic的可搜索快照，冷冻数据层能在低成本下保持良好的性能。这为在预算内管理海量数据并保持高效搜索性提供了令人信服的解决方案。

本文通过对Elastic的热层和冷冻层进行基准测试，运行了覆盖105TB日志、跨度超过90天的示例查询。这些查询模拟了Kibana中的常见任务，包括带高亮的搜索、总命中数、日期直方图聚合和术语聚合。结果显示，Elastic的冷冻数据层查询速度快，延迟与热层相当，只有第一次查询对象存储时稍慢，之后的查询速度都很快。

我们通过Kibana的Discover功能，模拟典型用户如何与热-冷冻部署进行交互，Discover是与索引文档交互的主要界面。

当用户使用Discover的搜索栏发出搜索请求时，通常会并行执行以下三个任务：

• 对500个文档进行搜索和高亮操作，不跟踪总命中数（在结果中被称为discover_search任务）
• 跟踪总命中数的搜索（在结果中被称为discover_search_total）
• 用于构建柱状图的日期直方图聚合（在结果中被称为discover_date_histogram）

此外，

• 当用户点击左侧栏时，会执行术语聚合（在结果中被称为discover_terms_agg）

Elastic中的数据层

有些类型的数据会随着时间的推移而贬值。举个例子，应用日志中，最新的记录通常是查询频率最高且需要最快响应时间的。但还有其他例子，如病历记录（详细的病人历史、诊断和医生笔记）、法律文件（合同、法院判决、案件文件等）和银行记录（包括购买描述和商家名称的交易记录），这些都包含非结构化或半结构化文本，需要高效的搜索能力来提取相关信息。虽然这些记录随着时间推移即刻相关性可能下降，但它们在历史分析、合规性和参考用途上仍具有重要价值。

Elastic的数据层——热层、温层、冷层和冷冻层——提供了速度和成本的理想平衡，确保在不牺牲可用性的情况下，随着数据老化最大限度地发挥其价值。通过Kibana和Elasticsearch的搜索API，底层数据层的使用总是自动且透明的——用户不需要以不同的方式发出搜索请求来从特定层检索数据（无需手动恢复数据或“再水化”）。

在本文中，我们仅使用热层和冷冻层，常被称为热-冷冻场景。

冷冻层的工作原理

在热-冷冻场景中，数据从热层开始，被积极摄取和查询。热层优化了高速读写操作，适合处理最新和访问频率最高的数据。随着数据老化并被较少访问，它会过渡到冷冻层以优化存储成本和资源利用。

从热层到冷冻层的过渡涉及将数据转换为可搜索快照。可搜索快照利用用于备份的快照机制，允许数据以成本效益高的方式存储，同时仍然可搜索。这消除了对副本分片的需求，显著减少了本地存储需求。

一旦数据进入冷冻层，它由专门指定的节点管理。这些节点无需有足够的磁盘空间来存储所有索引的完整副本。相反，它们使用一个基于磁盘的最近最少使用（LFU）缓存。这个缓存只存储从blob存储中下载的部分索引数据，以便根据需要提供查询服务。基于磁盘的缓存类似于操作系统的页面缓存，增强了对频繁请求数据部分的访问速度。

当在冷冻层执行查询时，过程包括几个步骤，以确保高效的数据检索和缓存：

1. 读取请求映射：在Lucene级别，读取请求映射到本地缓存。这个映射确定请求的数据是否已经存在于缓存中。

2. 缓存未命中处理：如果所需数据不在本地缓存中（缓存未命中），Elasticsearch会通过从blob存储下载更大区域的Lucene文件来处理。通常，这个区域是16MB的块，平衡了减少获取次数和优化传输数据量。

3. 添加数据到缓存：下载的块会被添加到本地缓存。这确保了对相同区域的后续读取请求可以直接从本地缓存中提供，显著提高查询性能，减少反复从blob存储获取数据的需求。

4. 缓存配置选项：

• 共享缓存大小：该设置接受总磁盘空间的百分比或绝对字节值。对于专用冷冻层节点，默认是总磁盘空间的90%。

xpack.searchable.snapshot.shared_cache.size: 4TB

• 最大预留空间：定义要保持的最大预留空间。如果没有明确设置，默认是100GB用于专用冷冻层节点。

xpack.searchable.snapshot.shared_cache.size.max_headroom: 100GB

5. 驱逐策略：节点级共享缓存使用LFU策略管理其内容。该策略确保频繁访问的数据保留在缓存中，而较少访问的数据被驱逐以腾出空间给新数据。这种动态缓存管理有助于保持磁盘空间的高效利用和对最相关数据的快速访问。

6. Lucene索引管理：为了进一步优化资源使用，Lucene索引仅在有活动搜索时按需打开。这种方法允许单个冷冻层节点管理大量索引而不会消耗过多的内存。

方法

我们在谷歌云平台上使用N2系列节点的Elastic Cloud上运行了六节点集群的测试：

• 3个 gcp.es.datahot.n2.68x10x45 - 针对热数据的存储优化型Elasticsearch实例。
• 3个 gcp.es.datafrozen.n2.68x10x90 - 作为冷冻数据缓存层的存储优化（密集型）Elasticsearch实例。

我们测量了以下跨度，等同于以天为单位的TB数，因为我们每天索引一个TB。

我们使用Rally运行测试，以下是一个测试样例，相对于一天冷冻数据未缓存的搜索（discover_search_total-1d-frozen-nocache），iterations指整个操作集重复的次数，在这个例子中是10次。每个operation定义一个特定任务或任务集，在这个例子中是一个复合操作。在这个操作中，有多个requests指定要执行的操作，如通过发出POST请求清除冷冻缓存。请求中的stream表示一系列相关操作，如提交搜索查询，然后检索和删除结果。

{
  "iterations": 10,
  "operation": {
    "operation-type": "composite",
    "name": "discover_search_total-1d-frozen-nocache",
    "requests": [
      {
        "name": "clear-frozen-cache",
        "operation-type": "raw-request",
        "path": "/_searchable_snapshots/cache/clear",
        "method": "POST"
      },
      {
        "stream": [
          {
            "name": "async-search",
            "operation-type": "submit-async-search",
            "index": "hotfrozenlogs",
            "request-params": {
              "track_total_hits": "true"
            },
            "body": {
              "_source": false,
              "size": 0,
              "query": {
                "bool": {
                  "filter": [
                    {
                      "multi_match": {
                        "type": "best_fields",
                        "query": "elk lion rider",
                        "lenient": true
                      }
                    },
                    {
                      "range": {
                        "@timestamp": {
                          "format": "strict_date_optional_time",
                          "gte": "2024-02-15T00:00:00",
                          "lt": "2024-02-16T00:00:00"
                        }
                      }
                    }
                  ]
                }
              },
              "stored_fields": [
                "*"
              ],
              "fields": [
                {
                  "field": "@timestamp",
                  "format": "date_time"
                }
              ]
            }
          }
        ]
      },
      {
        "operation-type": "get-async-search",
        "retrieve-results-for": [
          "async-search"
        ]
      },
      {
        "operation-type": "delete-async-search",
        "delete-results-for": [
          "async-search"
        ]
      }
    ]
  }
}

每个测试在每次基准运行中运行10次，我们在几天内进行了500次基准运行，因此每个任务的样本量为5000次。当我们想确保结果的统计显著性和可靠性时，大量测量数据是必不可少的。这个大样本量有助于平滑异常现象，并提供更准确的性能表示，使我们能够从数据中得出有意义的结论。

结果

详细结果如下图所示。烛台顶端代表所有请求中某特定操作观察到的最大（或p100）值，并按层分组。绿色值代表p99.9，即99.9%的请求会落在该值以下。

由于Kibana与Elasticsearch交互的方式是通过异步搜索，因此更合理的时间表示方式是使用如下的水平条形图。由于请求是异步并行的，它们会在不同时间完成。您不必等到所有请求完成后才能看到查询结果，这就是我们阅读基准结果的方式。

async-searches.gif

1天跨度 / 1TB

热层的99.9%性能在543毫秒到2秒之间，而冷冻层缓存情况下在558毫秒到11秒之间，未缓存情况下在1.8秒到14秒之间。

0.1%的情况下，我们观察到冷冻层的最大延迟为28秒。

1d_latency_barchart_with_columns.png.webp

7天跨度 / 7TB

热层的99.9%性能在552毫秒到791毫秒之间，而冷冻层缓存情况下在1秒到12秒之间，未缓存情况下在2.3秒到14.5秒之间。

0.1%的情况下，我们观察到冷冻层的最大延迟为33秒。

14天跨度 / 14TB

热层的99.9%性能在550毫秒到608毫秒之间，而冷冻层缓存情况下在1秒到12秒之间，未缓存情况下在2.3秒到14.5秒之间。

0.1%的情况下，我们观察到冷冻层的最大延迟为31秒。

30天跨度 / 30TB

我们没有在14天后使用热数据。冷冻层的99.9%性能在缓存情况下为1秒到11秒之间，未缓存情况下为2秒到12秒之间。

0.1%的情况下，我们观察到冷冻层的最大延迟为68秒。

60天跨度 / 60TB

冷冻层的99.9%性能在缓存情况下为1秒到11秒之间，未缓存情况下为2秒到13秒之间。

0.1%的情况下，我们观察到冷冻层的最大延迟为240秒。

90天跨度 / 90TB

冷冻层的99.9%性能在缓存情况下为1秒到11秒之间，未缓存情况下为2.5秒到13秒之间。

0.1%的情况下，我们观察到冷冻层的最大延迟为304秒。

使用Elastic的冷冻数据层降低数据存储成本

Elastic的冷冻数据层重新定义了数据存储和检索的可能性。基准测试结果显示，对于99.9%的查询，它的性能与热层相当，高效处理典型用户任务。虽然在极少情况下（0.1%的时间）可能会出现稍高的延迟，但Elastic的可搜索快照确保了管理大数据集的强大且成本效益高的解决方案。不论是搜索多年安全数据以查找高级持续威胁，还是从日志和指标中分析历史季节性趋势，可搜索快照和冷冻层都提供了无与伦比的价值和性能。通过采用冷冻层，组织可以优化存储策略，保持响应速度，使数据可搜索，并保持在预算之内。