用了Elasticsearch,一口气上5T
Elasticsearch

Elasticsearch

Elasticsearch 国产化

Easysearchyangmf2040 发表了文章 • 0 个评论 • 286 次浏览 • 2 天前 • 来自相关话题

背景

Elasticsearch 这些年来在搜索领域一直是领头羊。国内也有非常多的企业在使用 Elasticsearch 来做查询搜索、数据分析、安全分析等等。甚至一些很重要的行业、系统都在使用 Elasticsearch。在使用 Elasticsearch 的道路上狂飙的时候,我们也观察到了一些问题:

  1. Elasticsearch 不再是开源软件了。
  2. Elastic 公司退出了中国直销市场,不提供本土化支持了。
  3. 国家对信创、自主可控的战略化布局。
  4. 国际形势从合作共赢到自闭对垒。
  5. Elasticsearch 软件本身安全问题频发。
  6. Elasticsearch 软件在性能、稳定性和扩展性方面存在很大的提升空间。

基于以上这些问题,推出一个 Elasticsearch 国产化解决方案就很有必要了。我们的解决方案是推出一款名为 Easysearch 的软件,作为 Elasticsearch 国产化替代 。
出发点是在兼容原 Elasticsearch 软件的基础之上,完善更多的企业级功能,同时提高产品的性能、稳定性和扩展性。
下面我将从几个方面简单介绍下 Easysearch 软件。

兼容性

支持原生 Elasticsearch 的 DSL 查询语法,原业务代码无需调整。 支持 SQL ,方便熟悉 SQL 的开发人员上手分析数据。 兼容 Elasticsearch 的 SDK。 兼容现有索引存储格式。 支持冷热架构和索引生命周期,真正做到无缝衔接。

功能增强

提供企业级的安全管理,可对接 LDAP、AD 认证。 重构分布式架构,保持稳定的同时,能支持更大规模的数据。 在不降低性能的同时,实现更高压缩比的数据压缩,直接节省磁盘 40% 以上。 支持 KNN、异步搜索、数据脱敏、可搜索快照、审计等企业级功能。

容灾

支持基于 CDC 的集群复制技术,实现同版本间的容灾。
支持基于请求双写的复制技术,实现跨版本容灾。

信创

全面适配国产 CPU、操作系统,并获得厂家认证。

迁移方案

支持原索引存储格式,可通过快照备份直接恢复到 Easysearch 集群。
提供迁移工具,直接可视化操作迁移数据。

简单的介绍就到这里了,更多信息请访问:https://www.infinilabs.com/products/easysearch

最后

如有需要请联系我,让我们一起位祖国的信创事业添砖加瓦。

OpenSearch 与 Elasticsearch:哪个开源搜索引擎适合您?

OpenSearchHansoph 发表了文章 • 0 个评论 • 400 次浏览 • 4 天前 • 来自相关话题

当谈论到搜索引擎产品时,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 内存溢出优化案例一则

Easysearchliaosy 发表了文章 • 0 个评论 • 377 次浏览 • 4 天前 • 来自相关话题

最近某客户在使用 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

about 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/

如何防止 Elasticsearch 服务 OOM?

Easysearchyangmf2040 发表了文章 • 0 个评论 • 1803 次浏览 • 2024-02-26 10:12 • 来自相关话题

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 的过程中也遇到过各种各样的问题。欢迎大家来我们这个平台分享自己的问题、解决方案等。如有任何问题,请随时联系我,期待与您交流!

【 INFINI Workshop 北京站】1月18日一起动手实验玩转 Easysearch

活动liaosy 发表了文章 • 0 个评论 • 1833 次浏览 • 2023-12-15 16:22 • 来自相关话题

与 INFINI Labs 的技术专家面对面,第一时间了解极限实验室的发布最新产品和功能特性,通过动手实战,快速掌握最前沿的搜索技术,并用于实际项目中。欢迎大家扫描海报二维码免费报名参加。

活动时间:2024-01-18 13:30~17:30

活动地点:北京市海淀区 Wework 辉煌时代大厦 3 楼 3E 会议室

分享议题

  • Easysearch 总体介绍及搭建实战
  • 基于 INFINI Console 实现跨版本、跨引擎统一管控
  • Elasticsearch -> Easysearch 在线迁移实操

参会提示

  • 请务必自备电脑(Windows 系统环境请提前安装好 Linux 虚拟机)
  • 请提前在 INFINI Labs 官网下载对应平台最新安装包(INFINI Easysearch、INFINI Gateway、INFINI Console)
  • 下载地址:https://www.infinilabs.com/download
  • 如有任何疑问可添加 INFINI Labs 小助手(微信号: INFINI-Labs)进行联系

20231214-095304-qrcode.jpeg

ElasticSearch自动补全,中文不准确的问题,请大家帮我看一下

ElasticsearchGod_lockin 回复了问题 • 2 人关注 • 1 个回复 • 2473 次浏览 • 2023-11-21 22:17 • 来自相关话题

【 INFINI Workshop 北京站】1月18日一起动手实验玩转 Easysearch

活动liaosy 发表了文章 • 0 个评论 • 1833 次浏览 • 2023-12-15 16:22 • 来自相关话题

与 INFINI Labs 的技术专家面对面,第一时间了解极限实验室的发布最新产品和功能特性,通过动手实战,快速掌握最前沿的搜索技术,并用于实际项目中。欢迎大家扫描海报二维码免费报名参加。

活动时间:2024-01-18 13:30~17:30

活动地点:北京市海淀区 Wework 辉煌时代大厦 3 楼 3E 会议室

分享议题

  • Easysearch 总体介绍及搭建实战
  • 基于 INFINI Console 实现跨版本、跨引擎统一管控
  • Elasticsearch -> Easysearch 在线迁移实操

参会提示

  • 请务必自备电脑(Windows 系统环境请提前安装好 Linux 虚拟机)
  • 请提前在 INFINI Labs 官网下载对应平台最新安装包(INFINI Easysearch、INFINI Gateway、INFINI Console)
  • 下载地址:https://www.infinilabs.com/download
  • 如有任何疑问可添加 INFINI Labs 小助手(微信号: INFINI-Labs)进行联系

20231214-095304-qrcode.jpeg

ElasticSearch自动补全,中文不准确的问题,请大家帮我看一下

回复

ElasticsearchGod_lockin 回复了问题 • 2 人关注 • 1 个回复 • 2473 次浏览 • 2023-11-21 22:17 • 来自相关话题

Elasticsearch 国产化

Easysearchyangmf2040 发表了文章 • 0 个评论 • 286 次浏览 • 2 天前 • 来自相关话题

背景

Elasticsearch 这些年来在搜索领域一直是领头羊。国内也有非常多的企业在使用 Elasticsearch 来做查询搜索、数据分析、安全分析等等。甚至一些很重要的行业、系统都在使用 Elasticsearch。在使用 Elasticsearch 的道路上狂飙的时候,我们也观察到了一些问题:

  1. Elasticsearch 不再是开源软件了。
  2. Elastic 公司退出了中国直销市场,不提供本土化支持了。
  3. 国家对信创、自主可控的战略化布局。
  4. 国际形势从合作共赢到自闭对垒。
  5. Elasticsearch 软件本身安全问题频发。
  6. Elasticsearch 软件在性能、稳定性和扩展性方面存在很大的提升空间。

基于以上这些问题,推出一个 Elasticsearch 国产化解决方案就很有必要了。我们的解决方案是推出一款名为 Easysearch 的软件,作为 Elasticsearch 国产化替代 。
出发点是在兼容原 Elasticsearch 软件的基础之上,完善更多的企业级功能,同时提高产品的性能、稳定性和扩展性。
下面我将从几个方面简单介绍下 Easysearch 软件。

兼容性

支持原生 Elasticsearch 的 DSL 查询语法,原业务代码无需调整。 支持 SQL ,方便熟悉 SQL 的开发人员上手分析数据。 兼容 Elasticsearch 的 SDK。 兼容现有索引存储格式。 支持冷热架构和索引生命周期,真正做到无缝衔接。

功能增强

提供企业级的安全管理,可对接 LDAP、AD 认证。 重构分布式架构,保持稳定的同时,能支持更大规模的数据。 在不降低性能的同时,实现更高压缩比的数据压缩,直接节省磁盘 40% 以上。 支持 KNN、异步搜索、数据脱敏、可搜索快照、审计等企业级功能。

容灾

支持基于 CDC 的集群复制技术,实现同版本间的容灾。
支持基于请求双写的复制技术,实现跨版本容灾。

信创

全面适配国产 CPU、操作系统,并获得厂家认证。

迁移方案

支持原索引存储格式,可通过快照备份直接恢复到 Easysearch 集群。
提供迁移工具,直接可视化操作迁移数据。

简单的介绍就到这里了,更多信息请访问:https://www.infinilabs.com/products/easysearch

最后

如有需要请联系我,让我们一起位祖国的信创事业添砖加瓦。

OpenSearch 与 Elasticsearch:哪个开源搜索引擎适合您?

OpenSearchHansoph 发表了文章 • 0 个评论 • 400 次浏览 • 4 天前 • 来自相关话题

当谈论到搜索引擎产品时,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 内存溢出优化案例一则

Easysearchliaosy 发表了文章 • 0 个评论 • 377 次浏览 • 4 天前 • 来自相关话题

最近某客户在使用 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

about 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/

如何防止 Elasticsearch 服务 OOM?

Easysearchyangmf2040 发表了文章 • 0 个评论 • 1803 次浏览 • 2024-02-26 10:12 • 来自相关话题

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 的过程中也遇到过各种各样的问题。欢迎大家来我们这个平台分享自己的问题、解决方案等。如有任何问题,请随时联系我,期待与您交流!

【 INFINI Workshop 北京站】1月18日一起动手实验玩转 Easysearch

活动liaosy 发表了文章 • 0 个评论 • 1833 次浏览 • 2023-12-15 16:22 • 来自相关话题

与 INFINI Labs 的技术专家面对面,第一时间了解极限实验室的发布最新产品和功能特性,通过动手实战,快速掌握最前沿的搜索技术,并用于实际项目中。欢迎大家扫描海报二维码免费报名参加。

活动时间:2024-01-18 13:30~17:30

活动地点:北京市海淀区 Wework 辉煌时代大厦 3 楼 3E 会议室

分享议题

  • Easysearch 总体介绍及搭建实战
  • 基于 INFINI Console 实现跨版本、跨引擎统一管控
  • Elasticsearch -> Easysearch 在线迁移实操

参会提示

  • 请务必自备电脑(Windows 系统环境请提前安装好 Linux 虚拟机)
  • 请提前在 INFINI Labs 官网下载对应平台最新安装包(INFINI Easysearch、INFINI Gateway、INFINI Console)
  • 下载地址:https://www.infinilabs.com/download
  • 如有任何疑问可添加 INFINI Labs 小助手(微信号: INFINI-Labs)进行联系

20231214-095304-qrcode.jpeg