当谈论到搜索引擎产品时，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。无论您选择哪个搜索引擎，都希望它能满足您的需求并取得成功。

最近某客户在使用 Easysearch 做聚合时，报出 OOM 导致掉节点的问题，当时直接让客户试着调整 indices.breaker.request.limit ，但是不起作用，于是又看了下 Easysearch 在断路器相关的代码，并自己测试了下。

断路器的种类和作用

Easysearch 内部有个 Circuit breaker 机制，目的是防止各种请求的负载过大导致 OutOfMemoryError，比较常用的断路器有 7 种，分别是：

• Parent circuit breaker 父断路器
• Field data circuit breaker fielddata 断路器
• Request circuit breaker 请求断路器
• In flight requests circuit breaker 传输请求断路器
• Accounting requests circuit breaker lucene 内存占用断路器
• Script compilation circuit breaker 脚本编译断路器
• Regex circuit breaker 正则表达式断路器

其中在执行消耗内存较多的聚合查询时，Request circuit breaker 用得最多。

复现测试

我在模拟客户场景测试聚合查询时，发现断路器并没有覆盖查询的整个流程，仍然会有 OOM 的风险。我测试了一个高基数 5 百万的 Terms aggregation，就没有触发断路，而是在等待了 1 分多钟后直接 OOM 了。我的测试环境是单节点 内存配置为 -Xmx1g，测试索引只有 1 个 shard。

测试语句如下：

curl -X GET "localhost:9211/leader-01/_search?pretty" -H 'Content-Type: application/json' -d'
{
"size": 1,
  "aggs": {
    "a": {
      "terms": { "field": "agent.id.keyword", "size": 5000000 }
    }
  }
}' > a.txt

Easysearch OOM 日志：

内存泄漏分析

使用 MemoryAnalyzer 分析生成的 jvm 堆转储文件：

最大的内存占用来自 Java 线程java.lang.Thread @ 0x7c8bb1d00。这个线程浅层(Shallow)保留的对象占用了 112.8MB 内存。但该线程实际保留(Retained)的对象内存占用高达 851 MB，成为整个内存占用的绝对大头。

进一步查看 Leak Suspects：

非常明确的给出了具体的内存泄露的对象：StringTerms$Bucket[7500010]

数组长度达到了七百五十万，占用内存：731,001,720 字节（占总内存的 68.65%）。

按照提示的GlobalOrdinalsStringTermsAggregator.java:586 行，去查看代码，实际上是将收集完的OrdBucket 转换为 StringTerms.Bucket，并且有一个 copy BytesRef的操作。

至此，原因和解决办法都清楚了，只要在转换之前预估一下将要增长的内存并调用断路器检测一下内存，一旦超出允许范围就快速触发 CircuitBreakingException，避免长时间等待后 OOM 引起的节点宕机了。

最新版 Elasticsearch 对比

作为对比，我又测试了下 Elasticsearch 最新版本 8.12.2，同样的测试环境和测试方法，结果依然是 OOM：

从这里可以看出 Elasticsearch 即使是最新版的断路器机制也还有很多改进的余地，比如增加对有 OOM 风险查询的覆盖率，还有就是在触发 GC 时，对 GC 堆内存回收的判断过于简单。

Easysearch 最新版本的改进

Easysearch 刚刚发布的 1.7.1 版本已经增加了上面的改进，后面也会持续改进查询聚合操作的内存控制，最新版本的跨集群复制（CCR）也增加了对 source_reuse 索引的支持，能更好的满足客户降本增效的需求，欢迎大家下载试用。

附官网下载链接：https://www.infinilabs.com/download/?product=easysearch

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎，核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比，Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档：https://www.infinilabs.com/docs/latest/easysearch

作者：张磊，原文：https://www.infinilabs.com/blog/2024/easysearch-kernel-improvement-case-study-on-oom-memory-overflow-optmization/

INFINI Labs 产品又更新啦~，包括 Console，Gateway，Agent 1.23.0 和 Easysearch 1.7.1。本次各产品更新了很多亮点功能，如 Console 优化实例管理中增加磁盘空闲空间显示，Easysearch 改进 HierarchyCircuitBreakerService 并添加断路器、改进跨集群复制的数据加载，增加对 source_reuse 索引的支持等。欢迎大家下载体验。

以下是本次更新的详细说明。

INFINI Easysearch v1.7.1

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎，核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。

Easysearch 本次更新如下：

Bug fix

• 修复 source_reuse 与字段别名冲突
• 改进 HierarchyCircuitBreakerService 并添加断路器
• 修复 _meta 不为空且 启用 source_reuse 时的映射解析错误
• 修复 source_reuse 下对多值还原不正确的问题

Improvements

• 改进 HierarchyCircuitBreakerService 并添加断路器
• 改进跨集群复制的数据加载，增加对 source_reuse 索引的支持

INFINI Console v1.23.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管， 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验： http://demo.infini.cloud (用户名/密码：readonly/readonly)。

Console 本次更新如下：

Bug fix

• 修复数据迁移中数据分片范围因精度导致数据溢出显示为负数
• 修复删除实例队列后消费的 Offset 未重置问题
• 修复网友提出的各种问题，如集群设置默认打开节点、索引采集等

Improvements

• 优化初始化配置向导，分步骤执行
• 优化实例管理中增加磁盘空闲空间显示
• 优化实例队列名称显示

INFINI Gateway v1.23.0

INFINI Gateway 是一个面向搜索场景的高性能数据网关，所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway 可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

Gateway 本次更新如下：

Bug fix

• 修复删除实例队列后消费的 Offset 未重置问题

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs） 中的对应项目中提交 Feature Request 或提交 Bug。

• 下载地址： https://www.infinilabs.com/download

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

欢迎加入 Discord 聊天室：https://discord.gg/4tKTMkkvVX

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

关于极限科技（INFINI Labs）

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

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

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

Elasticsearch（简称：ES） 和传统关系型数据库有很多区别， 比如传统数据中普遍都有一个叫“最大连接数”的设置。目的是使数据库系统工作在可控的负载下，避免出现负载过高，资源耗尽，谁也无法登录的局面。

那 ES 在这方面有类似参数吗？答案是没有，这也是为何 ES 会被流量打爆的原因之一。

针对大并发访问 ES 服务，造成 ES 节点 OOM，服务中断的情况，极限科技旗下的 INFINI Gateway 产品（以下简称 “极限网关”）可从两个方面入手，保障 ES 服务的可用性。

1. 限制最大并发访问连接数。
2. 限制非重要索引的请求速度，保障重要业务索引的访问速度。

下面我们来详细聊聊。

架构图

所有访问 ES 的请求都发给网关，可部署多个网关。

限制最大连接数

在网关配置文件中，默认有最大并发连接数限制，默认最大 10000。

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: $[[env.GW_BINDING]]
      # See `gateway.disable_reuse_port_by_default` for more information.
      reuse_port: true

使用压测程序测试，看看到达10000个连接后，能否限制新的连接。 超过的连接请求，被丢弃。更多信息参考官方文档。

限制索引写入速度

我们先看看不做限制的时候，测试环境的写入速度，在 9w - 15w docs/s 之间波动。虽然峰值很高，但不稳定。 接下来，我们通过网关把写入速度控制在最大 1w docs/s 。 对网关的配置文件 gateway.yml ，做以下修改。

env: # env 下添加
    THROTTLE_BULK_INDEXING_MAX_BYTES: 40485760 #40MB/s
    THROTTLE_BULK_INDEXING_MAX_REQUESTS: 10000 #10k docs/s
    THROTTLE_BULK_INDEXING_ACTION: retry #retry,drop
    THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES: 10 #1000
    THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS: 100 #10

router: # route 部分修改 flow
  - name: my_router
    default_flow: default_flow
    tracing_flow: logging_flow
    rules:
      - method:
          - "*"
        pattern:
          - "/_bulk"
          - "/{any_index}/_bulk"
        flow:
          - write_flow

flow: #flow 部分增加下面两段    
  - name: write_flow
    filter:
      - flow:
          flows:
            - bulking_indexing_limit
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

再次压测，test-index 索引写入速度被限制在了 1w docs/s 。

限制多个索引写入速度

上面的配置是针对 test-index 索引的写入速度控制。如果想添加其他的索引，新增一段配置即可。 比如，我允许 abc 索引写入达到 2w docs/s，test-index 索引最多不超过 1w docs/s ，可配置如下。

  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "abc":
              max_requests: 20000
              action: drop
              message: "abc doc写入超阈值" #触发限流告警message自定义
              log_warn_message: true
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

限速效果如下

限制读请求速度

我们先看看不做限制的时候，测试环境的读取速度，7w qps 。 接下来我们通过网关把读取速度控制在最大 1w qps 。 继续对网关的配置文件 gateway.yml 做以下修改。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"                                      rules:      
            - pattern: "/(?P<index_name>abc)/_search"                          
              max_qps: 10000
              group: index_name                                    
      - elasticsearch: 
          elasticsearch: prod                            
          max_connection_per_node: 1000

再次进行测试，读取速度被限制在了 1w qps 。

限制多个索引读取速度

上面的配置是针对 abc 索引的写入速度控制。如果想添加其他的索引，新增一段配置即可。 比如，我允许 abc 索引读取达到 1w qps，test-index 索引最多不超过 2w qps ，可配置如下。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"
          rules:
            - pattern: "/(?P<index_name>abc)/_search"
              max_qps: 10000
              group: index_name
            - pattern: "/(?P<index_name>test-index)/_search"
              max_qps: 20000
              group: index_name
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000

多个网关限速

限速是每个网关自身的控制，如果有多个网关，那么后端 ES 集群收到的请求数等于多个网关限速的总和。 本次介绍就到这里了。相信大家在使用 ES 的过程中也遇到过各种各样的问题。欢迎大家来我们这个平台分享自己的问题、解决方案等。如有任何问题，请随时联系我，期待与您交流！