超越 Filter Rewrite：OpenSearch Doc Value Skip Index 如何让聚合查询快 28 倍

原文：https://opensearch.org/blog/beyond-filter-rewrite-how-doc-value-skip-indexes-accelerate-aggregations-in-opensearch/ 作者：Ankit Jain, Asim Mahmood (AWS/OpenSearch 团队)

前言

在之前的博客中，我们介绍了如何通过 Filter Rewrite 和多范围遍历技术，利用 Lucene 的 BKD 树实现高达 100 倍的日期直方图聚合性能提升。这些技术效果显著，但有一个根本限制：要求查询过滤字段和聚合字段必须是同一个，且无法支持复杂的子聚合逻辑。当过滤字段和聚合字段不同时，或者子聚合需要逐文档计算时，查询引擎只能退回到逐个扫描文档的传统方式。

本文将介绍如何通过 Lucene 10 的 Doc Value Skip Index 克服这些限制，即使过滤字段和聚合字段不相关，也能实现最高 28 倍 的聚合性能提升。

Filter Rewrite 的局限性

Filter Rewrite 将日期直方图聚合转换为一系列范围过滤器，然后使用 Lucene 的 BKD 树（Points 索引）来统计每个桶的文档数量，无需访问单个文档值。多范围遍历进一步优化了这一点，通过单次有序遍历处理所有桶。

这两种技术都依赖一个关键假设：查询中用于过滤的字段就是被聚合的字段。

问题场景

考虑以下查询，它在 trip_distance 上过滤，但在 dropoff_datetime 上聚合：

{
  "size": 0,
  "query": {
    "range": {
      "trip_distance": {
        "gte": 0,
        "lte": 20
      }
    }
  },
  "aggs": {
    "dropoffs_over_time": {
      "date_histogram": {
        "field": "dropoff_datetime",
        "calendar_interval": "month"
      }
    }
  }
}

由于 trip_distance 和 dropoff_datetime 是不同的字段，trip_distance 的 BKD 树无法提供 dropoff_datetime 值在各桶中分布的信息。引擎无法将聚合重写为对聚合字段的范围过滤器，只能退回到传统方法：遍历每个匹配的文档，获取其 dropoff_datetime 文档值，然后放入正确的桶中。

同样，当子聚合需要逐文档计算时（例如计算每个时间桶内的平均值），Filter Rewrite 也无能为力，因为它只提供文档计数，无法访问单个字段值。

这些并非边缘情况。在实际分析查询中，很多场景是在一个维度上过滤，在另一个维度上聚合，子聚合在仪表板和报表中也很常见。我们需要一种更通用的方法。

Doc Value Skip Index：聚合引擎的新工具

从 Lucene 10.0 开始，一种新的索引结构可用：数值文档值上的可选 Skip Index，在 PR #13449 中引入，并在 PR #13563 中增加了多级支持。该结构通过 DocValuesSkipper 抽象暴露，为本文描述的优化提供了基础。

什么是 Skip Index？

在计算机科学中，跳表（Skip List）是一种概率数据结构，通过在有序数据上分层多个级别的链表，使用随机化决定哪些元素出现在更高层，从而提供期望 O(log n) 的搜索时间。

Lucene 的 Doc Value Skip Index 借用了多级概念，但完全是确定性的。它不使用随机化，而是在段创建时将文档划分为固定大小的区间，并在编译时构建摘要级别的层次结构。没有随机性：该结构完全由文档计数和配置的区间大小决定。

类比理解：就像书的目录。不需要逐页扫描来找到所需内容，先查看章标题，然后是节标题，最后缩小到具体页面。Skip Index 的工作原理相同：它让聚合引擎在决定是否检查单个值之前，先检查大块文档的摘要元数据。

Lucene 如何实现 Skip Index

Lucene 的实现使用最多 4 层（level 0-3）的层次结构。基础层（level 0）以 4,096 个文档为区间进行摘要。每个后续层聚合下一层的 8 个区间（2^3 的偏移），如下表所示：

对于最坏情况下有 2^31 - 1（约 21 亿）个文档的索引，Skip Index 层次结构在 level 0 约有 524,288 个条目，level 1 有 65,536 个，level 2 有 8,192 个，level 3 有 1,024 个。因此，搜索空间从数十亿个文档减少到仅需几千次元数据检查。

每个区间条目非常紧凑（仅 29 字节），编码以下元数据：

• 级别数（1 字节）：该条目包含在多少个级别中
• 最小值和最大值（16 字节）：该区间内字段值的范围
• 最小和最大文档 ID（8 字节）：该区间的文档 ID 边界
• 文档计数（4 字节）：该区间内的文档数量

这些元数据使聚合引擎能够对每个区间做出三种决策：

1. 如果区间的最小/最大值完全在当前聚合桶之外，跳过整个区间
2. 如果区间的最小/最大值完全在单个桶内，批量计数所有文档，无需单独检查
3. 如果区间跨越多个桶，退回到逐个处理文档

遍历从最高可用级别开始，仅在需要时下降，类似于之前优化中 BKD 树遍历跳过整个子树的方式。关键区别在于该结构操作的是文档值而非 Points 索引，因此无论查询过滤哪个字段都有效。

Skip Index 如何解决 Filter Rewrite 的局限性

回顾我们确定的两个主要限制：

1. 不相关字段：Filter Rewrite 要求过滤字段和聚合字段相同
2. 复杂子聚合：Filter Rewrite 只提供计数；无法支持桶内的逐文档计算

Skip Index 解决了这两个限制，因为它直接操作聚合字段的文档值，独立于匹配文档集的产生方式。查询引擎首先评估查询（使用适合过滤字段的索引）以产生一组匹配的文档 ID。然后，在聚合期间，它查询聚合字段的 Skip Index，以确定这些匹配文档的块是否可以跳过或批量计数。

这种解耦是关键洞察。Skip Index 不关心文档集是否被过滤过，它只需要知道聚合字段的值在每个区间内的分布情况。

示例

例如，考虑一个在 process.name 上过滤（词项过滤器）并在 @timestamp 上聚合（按天分桶的日期直方图）的查询：

GET /logs-*/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "range": {
            "@timestamp": {
              "gte": "2024-01-01",
              "lte": "2024-01-31"
            }
          }
        },
        {
          "term": {
            "process.name": "systemd"
          }
        }
      ]
    }
  },
  "aggs": {
    "daily_counts": {
      "date_histogram": {
        "field": "@timestamp",
        "calendar_interval": "day"
      }
    }
  }
}

没有 Skip Index 时，@timestamp 上的范围查询可能受益于 Filter Rewrite，但 process.name 上的词项过滤器阻止了查询被重写。引擎必须遍历匹配两个条件的每个文档，并单独检索每个 @timestamp 值。

启用 @timestamp 的 Skip Index 后，聚合引擎可以在收集期间查询 Skip Index。当它遇到一个区间，其中最小和最大 @timestamp 值都落在同一个日桶内时，它会批量计数该区间中所有匹配的文档，无需查找单个值。这可以将总查找次数减少约 85%。

使用 Popcount 高效计数

批量计数步骤有一个值得探讨的细节。当 Skip Index 表明区间内的所有值都落在单个桶内时，我们知道批量计数是可能的；然而，我们不能直接使用区间的文档计数。Skip Index 覆盖段中的所有文档，但查询产生的 DocIdSetIterator 只代表匹配查询过滤器的文档子集。我们需要计算该过滤子集中有多少文档落在 Skip Index 区间内。

一种方法是逐个遍历迭代器，边遍历边计数。但这违背了跳过的大部分目的。相反，我们使用硬件级优化：popcount（人口计数）CPU 指令，它可以在单次操作中计算机器字中设置位的数量。

当查询引擎产生 DocIdSetIterator 时，它通常在内部将匹配文档集表示为位集，其中每个位对应一个文档 ID，如果文档匹配查询则设置为 1。要计算 Skip Index 区间内有多少匹配文档，我们提取该位集的相关部分（对应区间内最小/最大文档 ID 范围内的位），并对这些字应用 popcount。这给出了区间内的精确匹配文档数，无需逐个遍历。

DocIdSetIterator 还支持批量收集接口：收集器可以接收文档 ID 流，而不是重复调用 nextDoc()。当流中的所有文档 ID 都落在同一个桶内时（由 Skip Index 确定），整个流可以在一次操作中收集。初步基准测试显示，这种方法在 Skip Index 收益的基础上可额外带来最高 3 倍 的提升。

有序数据：Skip Index 的最佳场景

当文档按聚合字段排序时，Skip Index 发挥最佳性能。数据有序时，连续文档具有相似或单调递增的值，意味着每个 4,096 文档区间内的最小/最大范围较窄。窄范围更有可能完全落在单个聚合桶内，最大化批量计数的机会。

对于时序工作负载（日志分析、指标和可观测性），时间戳字段是自然的选择。大多数时序数据大致按时间顺序到达，OpenSearch 中的数据流保持这种顺序。

确保数据保持有序

仅仅有时间戳字段并不能保证数据在段合并和文档添加时保持有序。有两种方法可以保持排序：

1. Index Sort（推荐）：配置显式的索引排序设置，确保无论段如何合并，数据都保持排序：

{
  "settings": {
    "index.sort.field": "@timestamp",
    "index.sort.order": "desc"
  }
}

这保证所有段保持时间戳顺序，提供一致的 Skip Index 性能。

2. Log Merge Policy：或者，使用保留传入文档顺序的合并策略。log_byte_size 合并策略倾向于保持时序数据典型的仅追加工作负载的时间顺序。

当数据无序时，Skip Index 仍然可以正常工作，但提供较少的跳过和批量计数机会，因为每个区间的最小/最大范围可能跨越多个桶。

启用 Skip Index

Skip Index 可以根据 OpenSearch 版本自动启用或通过手动配置启用。

按版本的默认行为

手动配置

要在其他数值字段上启用 Skip Index，请在字段映射中添加 skip_list 参数：

PUT /my-index
{
  "mappings": {
    "properties": {
      "custom_timestamp": {
        "type": "date",
        "skip_list": true
      },
      "price": {
        "type": "long",
        "skip_list": true
      }
    }
  }
}

性能测试结果

我们使用 OpenSearch Benchmark 和 http_logs 及 big5 数据集测量了性能。结果显示了显著改进，特别是对于 Filter Rewrite 之前无法帮助的查询。

日期直方图性能（http_logs 工作负载）

基于 PR #19130 使用 http_logs 数据集的测试：

第一个操作展示了 Skip Index 在纯计数聚合与不相关过滤器上的全部优势。第二个操作包含子聚合（指标），改进较小，因为逐文档指标计算仍然需要指标字段的单个值查找。

日期直方图查询的吞吐量提高了 21%，对索引性能没有可测量的影响。

自动日期直方图性能（big5 工作负载）

OpenSearch 3.4 将 Skip Index 优化扩展到自动日期直方图聚合。基于 PR #20057 使用 big5 数据集的测试：

这些结果结合了范围查询的 Filter Rewrite 优化和自动日期直方图的 Skip Index，展示了两种技术如何互补。

索引大小影响

Skip Index 引入的存储开销极小：

由于这种极小的开销，OpenSearch 默认只在 @timestamp 字段上启用 Skip Index，在不显著增加存储成本的情况下提供针对性收益。

总结

Doc Value Skip Index 是 OpenSearch 聚合引擎的重要进步，解决了 Filter Rewrite 的根本限制。通过在文档值上构建多级摘要结构，它实现了：

• 不相关字段的聚合优化：过滤字段和聚合字段可以不同
• 子聚合支持：即使需要逐文档计算也能受益
• 最高 28 倍性能提升：在合适的场景下
• 极低存储开销：仅增加约 0.1%-1% 的存储

对于时序数据和分析工作负载，这是一个值得启用的强大优化。

原文作者：Ankit Jain（Amazon OpenSearch Service 软件工程师，Apache Lucene 和 OpenSearch 活跃维护者）、Asim Mahmood（AWS 高级软件工程师）

大家好，我是 INFINI Labs 的石阳。

欢迎关注 《搜索百科》 专栏！每天 5 分钟，带你速览一款搜索相关的技术或产品，同时还会带你探索它们背后的技术原理、发展故事及上手体验等。

上一篇我们围观了 “流量明星” Elasticsearch — 从食谱搜索到 PB 级明星产品，从 Apache 2.0 到 SSPL 协议风波；今天我们来聊聊它的“分叉兄弟” OpenSearch。

引言

2021 年，当 Elasticsearch 宣布将其许可证从 Apache 2.0 变更为 SSPL/Elastic License 时，整个搜索社区为之震动。这一变更直接催生了一个新的开源分支 — OpenSearch。这个由 AWS 主导的项目不仅在短短几年内迅速发展成熟，更成为了许多企业在云原生环境下搜索解决方案的新选择。

OpenSearch 概述

OpenSearch 是从 Elasticsearch 7.10.2 分支而来的开源搜索与分析套件，由 AWS 主导开发并贡献给开源社区。OpenSearch 包括 OpenSearch（搜索引擎）和 OpenSearch Dashboards（可视化界面），完全兼容 Apache 2.0 协议，旨在为用户提供一个真正开源、社区驱动的搜索与分析解决方案。

• 首次发布：2021 年 4 月
• 最新版本：3.2.0（截止 2025 年 9 月）
• 开源协议：Apache License 2.0
• 主导企业：Amazon Web Services (AWS)
• 官方网址：https://opensearch.org/
• GitHub 仓库：https://github.com/opensearch-project

诞生故事：开源协议争议的产物

时间回到 2021 年 1 月，Elastic 公司宣布 Elasticsearch 从 7.11 版本起不再使用 Apache 2.0 协议，而改为 Elastic License 与 SSPL。这一决定立刻在社区和产业界引发巨大争议。

AWS（亚马逊云）作为 Elasticsearch 的重要用户与云服务提供商，不愿意被 Elastic 的商业条款所限制，随即牵头将 Elasticsearch 7.10 版本 fork 出来，并与 Kibana 一起重命名为 OpenSearch 与 OpenSearch Dashboards。

从此，开源世界分裂成了两条路线：

1. Elastic 官方的 Elasticsearch + Kibana（带有商业许可）。
2. 社区驱动的 OpenSearch + OpenSearch Dashboards（继续遵循 Apache 2.0 协议）。

这个分叉，既是开源协议之争的产物，也是云厂商与开源公司之间博弈的缩影。虽然初期被质疑过“是否真开源”，但经过数年的迭代，OpenSearch 已形成了相对独立的开发节奏和用户群体，插件和生态也逐渐丰富。

技术架构与特性

OpenSearch 是一个基于 Apache Lucene 的分布式搜索与分析引擎。在将数据添加到 OpenSearch 后，可以对其执行各种功能完备的全文搜索操作：按字段搜索、跨多个索引搜索、提升字段权重、按得分排序结果、按字段排序结果以及对结果进行聚合。

OpenSearch 的核心架构由集群、节点、索引、分片和文档组成。最高层是 OpenSearch 集群，它是由多个节点组成的分布式网络，每个节点会根据其类型负责不同的集群操作。数据节点负责存储索引（即文档的逻辑分组），并处理数据写入、搜索和聚合等任务。

每个索引会被划分为多个分片，分片包含主数据和副本数据。分片会分布在多台机器上，从而实现水平扩展，提升性能并高效利用存储资源。

OpenSearch vs Elasticsearch：详细对比

快速开始：5 分钟部署 OpenSearch

1. 使用 Docker 部署

# 拉取 OpenSearch 镜像
docker pull opensearchproject/opensearch:3.2.0

# 启动 OpenSearch 节点
docker run -d --name opensearch-node \
  -p 9200:9200 -p 9600:9600 \
  -e "discovery.type=single-node" \
  -e "plugins.security.disabled=true" \
  opensearchproject/opensearch:3.2.0

# 拉取 OpenSearch Dashboards
docker pull opensearchproject/opensearch-dashboards:3.2.0

# 启动 Dashboards
docker run -d --name opensearch-dashboards \
  -p 5601:5601 \
  -e "OPENSEARCH_HOSTS=http://opensearch-node:9200" \
  opensearchproject/opensearch-dashboards:3.2.0

2. 验证安装

# 检查集群状态
curl -X GET "http://localhost:9200/"

出现如下结果说明安装成功。

3. 创建索引和搜索

# 索引文档
curl -X POST "http://localhost:9200/my-first-index/_doc" -H 'Content-Type: application/json' -d'
{
  "title": "OpenSearch 入门指南",
  "content": "这是我在 OpenSearch 中的第一个文档",
  "timestamp": "2025-09-18T10:00:00"
}'

# 执行搜索
curl -X GET "http://localhost:9200/my-first-index/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "content": "第一个文档"
    }
  }
}'

4. 访问控制台

打开浏览器访问 http://localhost:5601 即可使用 OpenSearch Dashboards 界面。

结语

OpenSearch 的出现，是开源社区的一次“自救”。它不仅延续了 Elasticsearch 的核心功能，还代表了另一种治理模式：由云厂商和社区共同维护，保证了开源协议的延续。

在搜索技术的版图里，Elasticsearch 与 OpenSearch 的分叉，注定会成为一个重要的历史节点。未来，两者可能会继续竞争，也可能各自发展出独特的生态。

🚀 下期预告

下一篇我们将介绍 OpenSearch 的另一个兄弟 Easysearch，一个衍生自开源协议 Apache 2.0 的 Elasticsearch 7.10.2 版本的轻量级搜索引擎，作为一个 ES 国产替代方案，看看它如何以其极致的速度和易用性在国内搜索领域占据一席之地。

💬 三连互动

1. 您是否考虑过从 Elasticsearch 迁移到 OpenSearch？
2. 在开源协议方面，您更倾向于哪种模式？Apache 2.0 还是 Elastic 的多重许可？
3. 对于云厂商与开源项目之间的关系，您有什么看法？

对搜索技术感兴趣的朋友，也欢迎加我微信（ID：lsy965145175）备注“搜索百科”，拉你进  搜索技术交流群，一起探讨与学习！

✨ 推荐阅读

• 搜索百科（3）：Elasticsearch — 搜索界的"流量明星"
• 搜索百科（2）：Apache Solr — 企业级搜索的开源先锋
• 搜索百科（1）：Lucene — 打开现代搜索世界的第一扇门

🔗 参考资源

• OpenSearch 官方文档
• OpenSearch 与 Elasticsearch 功能对比

原文：https://infinilabs.cn/blog/2025/search-wiki-4-opensearch/

在大模型席卷全球的行业背景下，基于检索结果增强的文本生成（RAG）备受关注。而作为 RAG 关键技术的向量数据库（VectorDB）正处在发展的十字路口。作为全球头部的 VectorDB 解决方案，OpenSearch 社区一直致力于前沿向量检索技术的研发。为了探讨 VectorDB 的发展趋势、应用场景、上下游技术生态，我们策划了这一场技术分享与线下见面会。希望可以给 VectorDB 玩家提供一个学习知识、结交朋友的平台。

在这场见面会中，我们会邀请来自于头部企业的向量检索技术研发专家、OpenSearch 社区的活跃贡献者以及一线人工智能科学家，来分享 VectorDB、大模型以及上下游相关技术的最新发展，以及对这个行业的未来的走向的见解。您将在这场会议中看到各个 VectorDB 头部企业的最新向量检索技术和产品，甚至有机会亲自作为用户去尝试。同时，我们还将举行圆桌讨论，您可以和各个相关行业的资深人士深入探讨 VectorDB 的未来，以及在这个行业中可能把握的机会。

时间：2024/04/13（周六） 14:00-18:30

地点：上海市长宁区新华路345弄4号楼 STOP SHOP（社友咖啡）

INIFINI Labs 议题推荐

《向量搜索基础设施 OpenSearch - 多集群管理的挑战与实践》By 曾嘉毅｜ INFINI Labs 联合创始人

摘要：数据规模不断增长和业务需求的多样化，推动了向量搜索技术的兴起。本次介绍聚焦于向量搜索的崛起和 OpenSearch 平台的能力，同时探讨业务数据集群发展趋势和常见挑战，包括管理多套集群、容量规划、监控、告警、治理、安全、开发、流量和排障等问题，提供解决方案和最佳实践。

活动整体议程

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：https://www.infinilabs.com

也欢迎大家微信扫码添加小助手（INFINI-Labs），加入用户群一起讨论交流。

当谈论到搜索引擎产品时，Elasticsearch 和 OpenSearch 是两个备受关注的选择。它们都以其出色的功能和灵活性而闻名，但在一些方面存在一些差异。在本文中，我们将从功能和延展性、工具与资源、价格和许可这三个角度对这两个产品进行论述。通过深入研究它们的特点和优势，您将能够更好地了解它们，从而为您的搜索需求做出明智的选择。让我们开始探索 Elasticsearch 和 OpenSearch 的世界，以便您能够为自己的项目或业务找到最佳的搜索解决方案。

功能和延展性

Elasticsearch 是一个功能强大的搜索引擎，它支持全文搜索、实时数据分析、数据聚合和可视化等功能。

1. 分布式架构：它使用分布式架构，可以处理大规模数据集，并以快速的速度返回查询结果。
2. 多种查询类型和过滤器：提供多种查询类型和过滤器，使用户能够进行复杂的数据分析和检索。
3. 高可用性和容错性：提供高可用性和容错性，通过复制和分片机制来确保数据的安全性和可靠性。
4. 强大的插件生态系统：帮助用户处理映射、分析、脚本引擎和发现等任务。通过使用这些插件，用户可以根据其特定的数据处理和分析需求进行功能扩展和定制。

OpenSearch 是从 Elasticsearch 分叉出来的版本，因此在许多方面与 Elasticsearch 相似。它保留了 Elasticsearch 的核心功能，并加入了一些新的功能和扩展性。下面主要讨论一些差异点：

1. 开源性和社区参与：OpenSearch 更注重开源性和社区参与，鼓励用户共同开发和改进系统。
2. 功能差异：OpenSearch 提供了一些额外的免费功能，如集中用户账户/访问控制、交叉集群复制、IP 过滤、可配置的数据保留期、异常检测、Tableau 连接器、JDBC 驱动程序、ODBC 驱动程序以及回归和分类等机器学习功能。
3. 插件生态系统差异：OpenSearch 中的某些功能作为插件捆绑在一起，需要用户额外学习和适应新工具。

服务与支持

Elasticsearch 拥有丰富的工具和资源，使用户能够更好地使用和管理搜索引擎。

1. 配套工具：丰富的生态系统，Logstash 用于数据摄取和转换，可以帮助用户为非结构化数据添加结构，进行字段匿名处理，并解析 IP 地址以获取位置信息。Beats 是一个专注于数据传输的工具，可以将数据从数千台机器发送到 Logstash 或 Elasticsearch。

2. 完善的文档资料和培训资源：

   a. 官方网站提供了产品指南、教程视频、博客文章、讨论论坛等丰富的学习材料。

   b. Elastic 还提供了 Slack 频道、YouTube 频道、以及定期举办的在线研讨会和培训活动，为用户提供即时的答疑和学习机会。

   c. 广泛的支持服务，包括社区支持、商业支持和培训服务。

OpenSearch 配套工具延展性更好，但是在学习资料和用户培训方面存在大部分空白，目前的服务与支持模式主要依赖于社区。

1. 配套工具：除去支持 Logstash 和 Beats 外，还有其他工具如 Fluentd、Fluent Bit、OpenTelemetry Collector 和 Data Prepper，来支持数据处理和传输。

2. 文档资料和培训资源：

   a. 文档资源：积极填补文档中的空白，并且每月举行两次社区会议，鼓励用户通过 GitHub 提交拉取请求、报告问题和提供反馈。

   b. 合作伙伴：提供 OpenSearch 的咨询支持和托管服务，其中就包括 INFINI Labs 在内，通过这些合作伙伴，用户可以获取与 OpenSearch 相关的专业服务和咨询，以满足其特定需求。

OpenSearch 的学习资源和培训材料相对较少，相比之下，Elasticsearch 的学习资料更加丰富和全面。然而，OpenSearch 社区积极发展中，未来可能会有更多的学习资源和支持服务可用。

价格和许可

Elasticsearch 和 OpenSearch 在价格和许可方面也存在差异。本文将从紧急支持和许可限制两个角度进行分析。

Elasticsearch：

1. 紧急支持：Elasticsearch 的高级许可证提供紧急支持，这意味着当出现集群崩溃、数据丢失或安全漏洞等问题时，公司能够提供即时的支持。
2. 许可限制：Elasticsearch 提供基于订阅模型的商业许可，其中包括从免费的基本许可到高级许可的多个层次。高级许可提供了额外的功能和支持，适合对性能和功能有更高要求的企业。

Opensearch：

1. 紧急支持：当前可以通过过第三方咨询公司或 AWS OpenSearch 等免费工具获得同样水平的支持，OpenSearch 有一个合作伙伴页面，列出了许多咨询公司，包括 INFINI Labs 的 OpenSearch 支持页面，他们提供 24 x 7 的支持。
2. 许可限制：OpenSearch 是基于 Apache 2.0 许可的开源软件，允许用户自由使用、修改和分发。它提供了免费的功能和灵活的定制，使用户能够根据自己的需求进行自定义和扩展。

总结

Elasticsearch 和 OpenSearch 都是强大而灵活的搜索引擎产品，但是存在一些差异。

总体来说，Elasticsearch 是一个成熟、功能强大的搜索引擎，拥有广泛的插件生态系统和丰富的学习资源。商业版本提供额外的功能和支持服务，适合需要高级功能和专业支持的企业。

OpenSearch 是从 Elasticsearch 分叉出来的版本，保留了核心功能，并添加了一些额外的功能。它更注重开源性和社区参与，适合更倾向于自主开发和定制的用户。

作者的话

希望这些信息能为您提供有价值的帮助，并使您更好地了解 Elasticsearch 和 OpenSearch。无论您选择哪个搜索引擎，都希望它能满足您的需求并取得成功。