无论才能、知识多么卓著,如果缺乏热情,则无异纸上画饼充饥,无补于事。
Elasticsearch

Elasticsearch

【搜索客社区日报】第2123期 (2025-09-29)

社区日报Muses 发表了文章 • 0 个评论 • 3521 次浏览 • 2025-09-29 15:18 • 来自相关话题

1、理解 Elasticsearch 中的分块策略 https://elasticstack.blog.csdn ... 72259 2、从 Uptime 到 Synthetics 在 Elastic 中的迁移手册 https://elasticstack.blog.csdn ... 84573 3、你的第一个 Elastic Agent:从单个查询到 AI 驱动的聊天 https://elasticstack.blog.csdn ... 14746 4、Elasticsearch 插件用于 UBI:在 Kibana 中分析用户数据 https://elasticstack.blog.csdn ... 59534 5、MCP 工具:自主代理的攻击向量与防御建议 https://elasticstack.blog.csdn ... 68195 编辑:Muse 更多资讯:http://news.searchkit.cn

【搜索客社区日报】第2119期 (2025-09-22)

社区日报Muses 发表了文章 • 0 个评论 • 6068 次浏览 • 2025-09-22 13:44 • 来自相关话题

1、使用 TwelveLabs 的 Marengo 视频嵌入模型与 Amazon Bedrock 和 Elasticsearch https://elasticstack.blog.csdn ... 92083 2、在 Elasticsearch 和 GCP 上的混合搜索和语义重排序 https://elasticstack.blog.csdn ... 52822 3、Elasticsearch 的 ES|QL 编辑器体验 vs. OpenSearch 的 PPL 事件分析器 https://elasticstack.blog.csdn ... 51492 4、ES 数据迁移之 INFINI Gateway https://www.infinilabs.cn/blog ... eway/ 5、AI Agent 主流的设计模式(ReAct,Reflection,LATS)其实没有很复杂。 https://mp.weixin.qq.com/s/7CZ6cHWQ-T9bmaWoJFwdwA 编辑:Muse 更多资讯:http://news.searchkit.cn

招聘!搜索运维工程师(Elasticsearch/Easysearch)-全职/北京/12-20K

求职招聘INFINI Labs 小助手 发表了文章 • 0 个评论 • 6151 次浏览 • 2025-09-22 12:33 • 来自相关话题

极限科技诚招全职搜索运维工程师(Elasticsearch/Easysearch)!

欢迎搜索技术热爱者加入我们,共同打造高效、智能的搜索解决方案!

在招岗位介绍

岗位名称

搜索运维工程师(Elasticsearch/Easysearch)

Base:北京
薪资待遇:12-20K,五险一金,双休等

岗位职责

  1. 负责客户现场的 Elasticsearch/Easysearch/OpenSearch 搜索引擎集群的日常维护、监控和优化,确保集群的高可用性和性能稳定;
  2. 协助客户进行搜索引擎集群的部署、配置及版本升级;
  3. 排查和解决 Elasticsearch/Easysearch/OpenSearch 集群中的各种技术问题,及时响应并处理集群异常;
  4. 根据业务需求设计和实施搜索索引的调优、数据迁移和扩展方案;
  5. 负责与客户沟通,提供技术支持及相关培训,确保客户需求得到有效满足;
  6. 制定并实施搜索引擎的备份、恢复和安全策略,保障数据安全;
  7. 与内部研发团队和外部客户进行协作,推动集群性能改进和功能优化。

岗位要求

  1. 全日制本科及以上学历,2 年以上运维工作经验;
  2. 拥有 Elasticsearch/Easysearch/OpenSearch 使用经验,熟悉搜索引擎的原理、架构和相关生态工具(如 Logstash、Kibana 等);
  3. 熟悉 Linux 操作系统的使用及常见性能调优方法;
  4. 熟练掌握 Shell 或 Python 等至少一种脚本语言,能够编写自动化运维脚本;
  5. 具有优秀的问题分析与解决能力,能够快速应对突发情况;
  6. 具备良好的沟通能力和团队合作精神,能够接受客户驻场工作;
  7. 提供 五险一金,享有带薪年假及法定节假日。

加分项

  1. 计算机科学、信息技术或相关专业;
  2. 具备丰富的大规模分布式系统运维经验;
  3. 熟悉 Elasticsearch/Easysearch/OpenSearch 分片、路由、查询优化等高级功能;
  4. 拥有 Elastic Certified Engineer 认证;
  5. 具备大规模搜索引擎集群设计、扩展和调优经验;
  6. 熟悉其他搜索引擎技术(如 Solr、Lucene)者优先;
  7. 熟悉大数据处理相关技术(比如: Kafka 、Flink 等)者优先。

简历投递

  1. 邮件:hello@infini.ltd(邮件标题请备注姓名 求职岗位)
  2. 微信:INFINI-Labs (加微请备注求职岗位)

关于极限科技(INFINI Labs)

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

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

官网:https://infinilabs.cn

我们在做什么

极限科技(INFINI Labs)正在致力于以下几个核心方向:

1、开发近实时搜索引擎 INFINI Easysearch INFINI Easysearch 是一个分布式的搜索型数据库,实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以替代 Elasticsearch,同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。详情参见:https://infinilabs.cn

2、打造下一代实时搜索引擎 INFINI Pizza INFINI Pizza 是一个分布式混合搜索数据库系统。我们的使命是充分利用现代硬件和人工智能的潜力,为企业提供量身定制的实时智能搜索体验。我们致力于满足具有挑战性的环境中高并发和高吞吐量的需求,同时提供无缝高效的搜索功能。详情参见:https://pizza.rs

3、为现代团队打造的统一搜索与 AI 智能助手 Coco AI Coco AI 是一款完全开源的统一搜索与 AI 助手平台,它通过统一搜索入口,连接企业内外部的异构数据源,融合大模型能力,帮助团队高效访问知识,智能决策协作。详情参见:https://coco.rs

4、积极参与全球开源生态建设 通过开源 Coco AI、Console、Gateway、Agent、Loadgen 等搜索领域产品和社区贡献,推动全球开源技术的发展,提升中国在全球开源领域的影响力。INFINI Labs Github 主页:https://github.com/infinilabs

5、提供专业服务 为客户提供包括搜索技术支持、迁移服务、定制解决方案和培训在内的全方位服务。

6、提供国产化搜索解决方案 针对中国市场的特殊需求,提供符合国产化标准的搜索产品和解决方案,帮助客户解决使用 Elasticsearch 时遇到的挑战。

极限科技(INFINI Labs)通过这些努力,旨在成为全球领先的实时搜索和数据分析解决方案提供商。

如何使用极限网关实现 Elasticsearch 集群迁移至 Easysearch

ElasticsearchINFINI Labs 小助手 发表了文章 • 0 个评论 • 6429 次浏览 • 2025-09-21 14:50 • 来自相关话题

之前有博客介绍过通过 Reindex 的方法将 Elasticsearch 的数据迁移到 Easysearch 集群,今天再介绍一个方法,通过 极限网关(INFINI Gateway) 来进行数据迁移。

测试环境

软件 版本
Easysearch 1.12.0
Elasticsearch 7.17.29
INFINI Gateway 1.29.2

迁移步骤

  1. 选定要迁移的索引
  2. 在目标集群建立索引的 mapping 和 setting
  3. 准备 INFINI Gateway 迁移配置
  4. 运行 INFINI Gateway 进行数据迁移

迁移实战

  1. 选定要迁移的索引

在 Elasticsearch 集群中选择目标索引:infinilabs 和 test1,没错,我们一次可以迁移多个。

  1. 在 Easysearch 集群使用源索引的 setting 和 mapping 建立目标索引。(略)
  2. INFINI Gateway 迁移配置准备

去 github 下载配置,修改下面的连接集群的部分

  1 env:
  2   LR_GATEWAY_API_HOST: 127.0.0.1:2900
  3   SRC_ELASTICSEARCH_ENDPOINT: http://127.0.0.1:9200
  4   DST_ELASTICSEARCH_ENDPOINT: http://127.0.0.1:9201
  5 path.data: data
  6 path.logs: log
  7 progress_bar.enabled: true
  8 configs.auto_reload: true
  9
 10 api:
 11   enabled: true
 12   network:
 13     binding: $[[env.LR_GATEWAY_API_HOST]]
 14
 15 elasticsearch:
 16   - name: source
 17     enabled: true
 18     endpoint: $[[env.SRC_ELASTICSEARCH_ENDPOINT]]
 19     basic_auth:
 20       username: elastic
 21       password: goodgoodstudy
 22
 23   - name: target
 24     enabled: true
 25     endpoint: $[[env.DST_ELASTICSEARCH_ENDPOINT]]
 26     basic_auth:
 27       username: admin
 28       password: 14da41c79ad2d744b90c

pipeline 部分修改要迁移的索引名称,我们迁移 infinilabs 和 test1 两个索引。

 31 pipeline:
 32   - name: source_scroll
 33     auto_start: true
 34     keep_running: false
 35     processor:
 36       - es_scroll:
 37           slice_size: 1
 38           batch_size: 5000
 39           indices: "infinilabs,test1"
 40           elasticsearch: source
 41           output_queue: source_index_dump
 42           partition_size: 1
 43           scroll_time: "5m"
  1. 迁移数据
./gateway-mac-arm64

#如果你保存的配置文件名称不叫 gateway.yml,则需要加参数 -config 文件名

数据导入完成后,网关 ctrl+c 退出。

至此,数据迁移就完成了。下一篇我们来介绍 INFINI Gateway 的数据比对功能。

有任何问题,欢迎加我微信沟通。

关于极限网关(INFINI Gateway)

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

官网文档:https://docs.infinilabs.com/gateway
开源地址:https://github.com/infinilabs/gateway

搜索百科(4):OpenSearch — 开源搜索的新选择

OpenSearchliaosy 发表了文章 • 0 个评论 • 6449 次浏览 • 2025-09-21 14:31 • 来自相关话题

大家好,我是 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 年 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:详细对比

特性 OpenSearch Elasticsearch
许可证 Apache 2.0(完全开源) SSPL/Elastic License/AGPLv3
起始版本 基于 Elasticsearch 7.10.2 从 7.11 开始协议变更
社区治理 开放治理模式,由社区驱动 由 Elastic NV 公司主导
安全性 所有安全功能默认开源 部分高级安全功能需要付费
AI/向量检索 近年快速跟进,兼容性较好 原生支持,功能逐步增强
部署选择 AWS OpenSearch Service / 自建 Elastic Cloud / 自建
升级路径 从 Elasticsearch 7.x 平滑迁移 原生升级路径
社区活跃度 社区逐渐壮大,受到纯开源拥护者欢迎 用户基础庞大,但分裂带来争议

快速开始: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)备注“搜索百科”,拉你进  搜索技术交流群,一起探讨与学习!

推荐阅读

🔗 参考资源

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

Easysearch 国产替代 Elasticsearch:8 大核心问题解读

Easysearchliaosy 发表了文章 • 0 个评论 • 7379 次浏览 • 2025-09-18 09:43 • 来自相关话题

近年来,随着数据安全与自主可控需求的不断提升,越来越多的企业开始关注国产化的搜索与日志分析解决方案。作为极限科技推出的国产 Elasticsearch 替代产品,Easysearch 凭借其对搜索场景的深入优化、轻量级架构设计以及对 ES 生态的高度兼容,成为众多企业替代 Elasticsearch 的新选择。

我们在近期与用户的交流中,整理出了大家最关心的八大问题,并将它们浓缩为一篇技术解读,希望帮助你快速了解 Easysearch 的优势与定位。

用户最关心的八大问题

  1. Easysearch 对数据量的支撑能力如何,能应对 PB 级数据存储吗?

答:完全可以。Easysearch 支持水平扩展,通过增加节点即可线性提升存储与计算能力。在实际应用中,已成功支撑 PB 级日志与检索数据。同时,其存储压缩率相比 Elasticsearch 7.10.2 平均高出 2.5~3 倍,显著节省硬件成本。

  1. 在高并发写入场景下,Easysearch 和 ES 的性能差异有多大?

答:在相同硬件配置下,使用 Nginx 日志进行 bulk 写入压测,Easysearch 在多种分片配置下的写入性能相比 Elasticsearch 7.10.2 提升 40%-70%,更适合高并发写入场景。

  1. 是否支持中文分词?需要额外插件吗?

答:中文分词一直是 Elasticsearch 用户的「必装插件」。而在 Easysearch 中,中文分词是开箱即用的,同时支持 ik、pinyin 等主流分词器,还能自定义词典,方便电商、内容平台等场景。

  1. 从 ES 迁移到 Easysearch 是否复杂?会影响业务吗?

答:迁移往往是国产替代的最大顾虑。为此,Easysearch 提供了 极限网关 工具,支持全量同步和实时增量同步。迁移过程中业务可继续读写,只需短暂切换连接地址,几乎无感知。

  1. 监控与运维工具是否完善?是否支持 Kibana?

答:Easysearch 提供完整的监控与运维体系。从 Easysearch 1.15.x 版本起自带 Web UI 管理控制台(类似简化版 Kibana),支持索引管理、查询调试、权限控制等功能。同时还提供 INFINI Console 实现多集群管理与深度监控等。也可以通过配置让 Kibana 连接 Easysearch(部分高级功能可能受限)。

  1. 小型团队技术能力有限,用 Easysearch 运维难度高吗?

答:Easysearch 的一大设计理念就是降低运维门槛。Easysearch 提供一键部署脚本,减少手动配置参数,支持自动分片均衡与故障节点恢复,无需专职运维人员也能稳定运行,非常适合技术资源有限的团队。

  1. Easysearch 是否支持数据备份与恢复?操作复杂吗?

答:支持快照(Snapshot),可备份到本地磁盘或对象存储(S3、OSS 等)。恢复时仅需执行快照恢复命令,满足企业级数据安全需求。

  1. 对比 ES,Easysearch 在使用体验上最大的不同是什么?

答:Easysearch 保持与 Elasticsearch 类似的接口与查询 DSL,用户几乎无学习成本即可上手。同时,它针对国产化环境和搜索场景做了优化,运维更轻量,成本更可控。

结语:Easysearch,国产化搜索的新选择

作为一款国产自主可控的搜索与日志分析引擎,Easysearch 不仅继承了 Elasticsearch 的核心能力,更在性能、易用性、资源效率和中文支持等方面进行了深度优化。对于希望实现国产化替代、降低运维成本、提升系统性能的企业来说,Easysearch 是一个值得认真考虑的新选择。

如果你正在评估 Elasticsearch 的替代方案,不妨从 Easysearch 开始,体验更轻量、更高效的搜索新架构。

如需了解更多技术细节与使用案例,欢迎访问官方文档与社区资源:

  1. Easysearch 官网文档
  2. Elasticsearch VS Easysearch 性能测试
  3. 使用 Easysearch,日志存储少一半
  4. Kibana OSS 7.10.2 连接 Easysearch
  5. 自建 ES 集群通过极限网关无缝迁移到云上
  6. INFINI Console 一站式的数据搜索分析与管理平台

搜索百科(3):Elasticsearch — 搜索界的“流量明星”

Elasticsearchliaosy 发表了文章 • 0 个评论 • 6014 次浏览 • 2025-09-16 11:20 • 来自相关话题

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

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

前两篇我们探讨了搜索技术的基石 Apache Lucene企业级搜索解决方案 Apache Solr。今天,我们来聊聊一个真正改变搜索游戏规则,但也充满争议的产品 — Elasticsearch

引言

如果说 Lucene 是幕后英雄,那么 Elasticsearch 就是舞台中央的明星。借助 REST API、分布式架构、强大的生态系统,它让搜索 + 分析成为“马上可用”的服务形式。

在日志平台、可观察性、安全监控、AI 与语义检索等领域,Elasticsearch 的名字几乎成了默认选项。

Elasticsearch 概述

Elasticsearch 是一个开源的分布式搜索和分析引擎,构建于 Apache Lucene 之上。作为一个检索平台,它可以实时存储结构化、非结构化和向量数据,提供快速的混合和向量搜索,支持可观测性与安全分析,并以高性能、高准确性和高相关性实现 AI 驱动的应用。

起源:从食谱搜索到全球“流量明星”

Elasticsearch 的故事始于以色列开发者 Shay Banon。2010 年,当时他在学习厨师课程的妻子需要一款能够快速搜索食谱的工具。虽然当时已经有 Solr 这样的搜索解决方案,但 Shay 认为它们对于分布式场景的支持不够完善。

基于之前开发 Compass(一个基于 Lucene 的搜索库)的经验,Shay 开始构建一个完全分布式的、基于 JSON 的搜索引擎。2010 年 2 月,Elasticsearch 的第一个版本发布。

随着用户日益增多、企业级需求增强,Shay 在 2012 年创立了 Elastic 公司,把 Elasticsearch 不仅作为开源项目,也逐渐商业化运营起来,包括提供托管服务、企业支持,加入 Logstash 日志处理、Kibana 可视化工具等,Elastic 公司也逐渐从一个纯搜索引擎项目演变为一个更广泛的“数据搜索与分析”平台。

协议变更:开源和商业化的博弈

Elasticsearch 的发展并非一帆风顺。其历史上最具转折性的事件当属与 AWS 的冲突及随之而来的开源协议变更

  1. 早期:Apache 2.0 协议

2010 年 Shay Banon 开源 Elasticsearch 时,最初采用的是 Apache 2.0 协议。Apache 2.0 属于宽松的自由协议,允许任何人免费使用、修改和商用(包括 SaaS 模式)。这帮助 Elasticsearch 快速壮大,成为事实上的“搜索引擎标准”。

  1. 协议变更:应对云厂商“白嫖”

随着 Elasticsearch 的流行,像 AWS(Amazon Web Services) 等云厂商直接将 Elasticsearch 做成托管服务,并从中获利。Elastic 公司认为这损害了他们的商业利益,因为云厂商“用开源赚钱,却没有回馈社区”。2021 年 1 月,Elastic 宣布 Elasticsearch 和 Kibana 不再采用 Apache 2.0,改为 双重协议:SSPL + Elastic License。这一步导致社区巨大分裂,AWS 带头将 Elasticsearch 分叉为 OpenSearch,并继续以 Apache 2.0 协议维护。

  1. 再次转向开源:AGPL v3

2024 年 3 月,Elastic 宣布新的版本(Elasticsearch 8.13 起)又新增 AGPL v3 作为一个开源许可选项。AGPL v3 既符合 OSI 真正开源标准,又能约束云厂商闭源托管服务,同时修复社区关系,Elastic 希望通过重新拥抱开源,减少分裂,吸引开发者回归。

Elasticsearch 从宽松到收紧,再到回归开源,是在社区生态与商业利益间寻找平衡的过程。

基本概念

要学习 Elasticsearch,得先了解其五大基本概览:集群、节点、分片、索引和文档。

  1. 集群(Cluster)

由一个或多个节点组成的整体,提供统一的搜索与存储服务。对外看起来像一个单一系统。

  1. 节点(Node)

集群中的一台服务器实例。节点有不同角色:

  • Master 节点:负责集群管理(分片分配、元数据维护)。
  • Data 节点:存储数据、处理搜索和聚合。
  • Coordinating 节点:接收请求并调度任务。
  • Ingest 节点:负责数据写入前的预处理。
  1. 索引(Index)

类似于传统数据库的“库”,按逻辑组织数据。一个索引往往对应一个业务场景(如日志、商品信息)。

  1. 分片(Shard)

为了让索引能水平扩展,Elasticsearch 会把索引拆分为多个 主分片,并为每个主分片创建 副本分片,提升高可用和查询性能。

  1. 文档(Document)

Elasticsearch 存储和检索的最小数据单元,通常是 JSON 格式。多个文档组成一个索引。

集群架构

Elasticsearch 通过 Master、Data、Coordinating、Ingest 等不同角色节点的协作,将数据切分成分片并分布式存储,实现了高可用、可扩展的搜索与分析引擎架构。

快速开始:5 分钟体验 Elasticsearch

1. 使用 Docker 启动

# 拉取最新镜像
docker pull docker.elastic.co/elasticsearch/elasticsearch:9.1.3

# 启动单节点集群
docker run -d --name elasticsearch \
  -p 9200:9200 -p 9300:9300 \
  -e "discovery.type=single-node" \
  -e "xpack.security.enabled=false" \
  docker.elastic.co/elasticsearch/elasticsearch:9.1.3

2. 验证安装

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

3. 索引文档

# 索引文档
curl -X POST "http://localhost:9200/myindex/_doc" -H 'Content-Type: application/json' -d'
{
"title": "Hello Elasticsearch",
"description": "An example document"
}'

3. 搜索文档

# 搜索文档
curl -X GET "http://localhost:9200/myindex/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "title": "Hello"
    }
  }
}'

结语

Elasticsearch 是搜索与分析领域标杆性的产品。它将 Lucene 的能力包装起来,加上分布式、易用以及与数据可视化、安全监控等功能的整合,使搜索引擎从专业技术逐渐变为“随手可用”的基础设施。

虽然协议变动、与 OpenSearch 的分叉引发争议,但它在企业与开发者群体中的实际应用价值依然难以替代。


🚀 下期预告

下一篇我们将介绍 OpenSearch,探讨这个 Elasticsearch 分支项目的发展现状、技术特点以及与 Elasticsearch 的详细对比。如果您有特别关注的问题,欢迎提前提出!

💬 三连互动

  1. 你或公司最近在用 Elasticsearch 吗?拿来做了什么场景?
  2. 在 Elasticsearch 和 OpenSearch 之间做过技术选型?
  3. 对 Elasticsearch 的许可证变化有什么看法?

对搜索技术感兴趣的朋友,也欢迎加我微信(ID:lsy965145175)备注“搜索百科”,拉你进  搜索技术交流群,一起探讨与学习!

✨ 推荐阅读

🔗 参考

原文:https://infinilabs.cn/blog/2025/search-wiki-3-elasticsearch/

搜索百科(2):Apache Solr — 企业级搜索的开源先锋

开源项目liaosy 发表了文章 • 0 个评论 • 5161 次浏览 • 2025-09-15 18:12 • 来自相关话题

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

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

上一篇我们认识了搜索技术的基石 Apache Lucene,今天我们将继续这个旅程,了解基于 Lucene 构建的第一个成功商业级搜索平台 —— Apache Solr

Solr 是什么?

Solr 是一款极速的开源多模态搜索平台,基于 Apache Lucene 的全文、向量和地理空间搜索能力构建而成。Solr 具备高可靠性、可扩展性和容错性,支持分布式索引、复制与负载均衡查询,提供自动故障转移与恢复、集中化配置等功能。如今,Solr 为全球众多大型互联网网站提供搜索和导航功能。

它的定位是:把 Lucene 打造成独立的企业级搜索服务。相比 Lucene 需要写代码调用,Solr 提供了 Web 管理界面、REST API 和配置文件,让开发者更容易上手。

起源:从网站搜索到 Apache 顶级项目

Solr(读作"solar")的故事始于 2004 年,当时 CNET 公司的开发人员 Yonik Seeley 需要为其新闻网站构建一个搜索功能。虽然 Lucene 提供了强大的核心搜索能力,但直接使用 Lucene 需要编写大量 Java 代码,缺乏开箱即用的功能。

Seeley 决定在 Lucene 之上构建一个更易用的搜索服务器,于是 Solr 诞生了。最初的目标很明确:通过 HTTP/XML 接口提供搜索服务,让任何编程语言都能轻松集成搜索功能。

2006 年,Solr 捐赠给 Apache 基金会,2007 年成为顶级项目。2010 年,Solr 与 Lucene 项目合并,形成了今天我们所知的 Apache Lucene/Solr 项目。

技术架构

Index(索引)

Apache Solr 的索引就像是用于管理结构化 / 非结构化数据的“数据库”。它以便于分析和全文检索的方式存储数据。

Query Parser(查询解析器)

所有由客户端提交的查询都会由查询解析器处理。

Response Handler(响应处理器)

响应处理器负责为客户端生成合适格式的响应(如 JSON/XML/CSV)。

Update Handler(更新处理器)

更新处理器用于索引操作,即对索引中的数据进行插入、更新和删除。例如,如果我们希望 MySQL 数据与 Apache Solr 保持同步,就需要创建一个负责同步的更新处理器。

功能亮点

  • 全文检索:高效支持关键词搜索、布尔查询、短语匹配等。
  • 分面搜索(Faceted Search):可以对搜索结果进行分类和聚合统计。
  • 分布式架构(SolrCloud):支持集群部署、自动分片、副本和容错。
  • 丰富的数据接口:提供 RESTful API,支持 JSON、XML、CSV 等多种格式的数据交互。
  • 扩展性与可定制性:通过插件机制支持多语言分词、排序、评分模型等个性化定制。
  • 地理位置搜索:内置空间搜索能力,支持基于经纬度的范围查询和排序。

对比: Solr vs Elasticsearch 如何选择?

虽然两者都基于 Lucene,但在设计哲学上有所不同:

特性 Apache Solr Elasticsearch
定位 企业级搜索服务器 分布式搜索和分析引擎
API 更标准化,遵循传统 REST 更灵活,JSON 原生
分布式 需要 ZooKeeper 协调 内置分布式协调
上手难度 相对简单,开箱即用 学习曲线较陡峭
生态系统 搜索功能更丰富 分析和可视化更强
适用场景 传统企业搜索、电商 日志分析、实时监控

简单来说:Solr 更像"精装房",开箱即用;Elasticsearch 更像"毛坯房",需要更多自定义但更灵活。

快速开始:5 分钟搭建 Solr 服务

1. 下载和安装

# 下载 8.x 版 Solr
wget https://dlcdn.apache.org/solr/solr/8.11.4/solr-8.11.4.tgz

# 解压
tar -xzf solr-8.11.4.tgz

# 启动 Solr(单机模式)
cd solr-8.11.4
bin/solr start

2. 创建 Core

# 创建测试 Core
bin/solr create -c test_core

# 查看 Core 状态
bin/solr status

3. 索引文档

# 使用 curl 索引 JSON 文档
curl http://localhost:8983/solr/test_core/update -d '
[
  {"id": "1", "title": "Solr 入门指南", "content": "Apache Solr 是企业级搜索平台"},
  {"id": "2", "title": "搜索技术演进", "content": "从 Lucene 到 Solr 的技术发展"}
]' -H 'Content-type:application/json'

# 提交更改
curl http://localhost:8983/solr/test_core/update -d '<commit/>' -H 'Content-type:application/xml'

4. 执行搜索

# 搜索"Solr"
curl "http://localhost:8983/solr/test_core/select?q=content:Solr"

# 使用 JSON 格式返回
curl "http://localhost:8983/solr/test_core/select?q=content:Solr&wt=json"

执行搜索返回结果:

访问 http://localhost:8983/solr 即可使用 Solr 的管理界面。

Dashboard:

Core Admin:

结语

从最初的公司内部工具,到成为全球范围内广泛使用的开源搜索引擎,Apache Solr 见证并推动了搜索技术的进化。尽管近年来 Elasticsearch、向量数据库和 AI 驱动的搜索技术逐渐崛起,但 Solr 依然是许多企业可靠且成熟的选择。它的故事不仅属于开源社区,也代表了搜索技术发展的一个重要阶段。


🚀 下期预告
在下一篇「搜索百科」中,我们将介绍它的明星兄弟 —— Elasticsearch

💬 三连互动

  1. 你现在还在用 Solr 吗?
  2. 在 Solr 和 Elasticsearch 之间做过技术选型?
  3. 遇到过有趣的 Solr 使用案例或挑战?

对搜索技术感兴趣的朋友,也欢迎加我微信(ID:lsy965145175)备注“搜索百科”,拉你进  搜索技术交流群,一起探讨与学习!

✨ 推荐阅读

🔗 参考

原文:https://infinilabs.cn/blog/2025/search-wiki-2-solr/

【搜索客社区日报】第2115期 (2025-09-15)

社区日报Muses 发表了文章 • 0 个评论 • 4863 次浏览 • 2025-09-15 10:49 • 来自相关话题

1、AI流程编排产品调研&实践 https://developer.damo-academy ... 25861 2、带地图的 RAG:多模态 + 地理空间 在 Elasticsearch 中 https://elasticstack.blog.csdn ... 52848 3、使用 LangExtract 和 Elasticsearch https://elasticstack.blog.csdn ... 07715 4、使用 OpenTelemetry 从你的日志中获取更多信息 https://elasticstack.blog.csdn ... 46828 5、Elasticsearch 索引字段删除,除了 Reindex 重建索引还有没有别的解决方案? https://mp.weixin.qq.com/s/IJxEQc59t4kn6ex_YGmYAQ 编辑:Muse 更多资讯:http://news.searchkit.cn

【搜索客社区日报】第2105期 (2025-09-01)

社区日报Muses 发表了文章 • 0 个评论 • 5057 次浏览 • 2025-09-01 12:17 • 来自相关话题

1、Observability:如何在隔离环境中部署 Elastic Agents https://elasticstack.blog.csdn ... 40009 2、Elasticsearch:Semantic text 字段类型 https://elasticstack.blog.csdn ... 88674 3、使用 ES|QL COMPLETION + 一个 LLM 在 5 分钟内编写一个 Chuck Norris 事实生成器 https://elasticstack.blog.csdn ... 73787 4、将 agents 连接到 Elasticsearch 使用模型上下文协议 - docker https://elasticstack.blog.csdn ... 51617 5、从炼金术到工程学:在AI浪潮中,我们如何告别RAG,拥抱真正的“上下文工程”? https://mp.weixin.qq.com/s/bZbiMDnKMEvKx18MVTYkBA 编辑:Muse 更多资讯:http://news.searchkit.cn

【搜索客社区日报】第2100期 (2025-08-25)

社区日报Muses 发表了文章 • 0 个评论 • 5289 次浏览 • 2025-08-25 10:45 • 来自相关话题

1、加速你的故障排查:使用 Elasticsearch 构建家电手册的 RAG 应用 https://elasticstack.blog.csdn ... 74533 2、使用 Ragas 评估你的 Elasticsearch LLM 应用 https://elasticstack.blog.csdn ... 99487 3、什么是 AI(人工智能)? https://elasticstack.blog.csdn ... 33166 4、Elasticsearch:什么是神经网络? https://elasticstack.blog.csdn ... 34162 5、传统 AI 与生成式 AI:IT 领导者指南 https://elasticstack.blog.csdn ... 33120 编辑:Muse 更多资讯:http://news.searchkit.cn
1、加速你的故障排查:使用 Elasticsearch 构建家电手册的 RAG 应用 https://elasticstack.blog.csdn ... 74533 2、使用 Ragas 评估你的 Elasticsearch LLM 应用 https://elasticstack.blog.csdn ... 99487 3、什么是 AI(人工智能)? https://elasticstack.blog.csdn ... 33166 4、Elasticsearch:什么是神经网络? https://elasticstack.blog.csdn ... 34162 5、传统 AI 与生成式 AI:IT 领导者指南 https://elasticstack.blog.csdn ... 33120 编辑:Muse 更多资讯:http://news.searchkit.cn

极限科技(INFINI Labs)招聘搜索运维工程师(Elasticsearch/Easysearch)

求职招聘INFINI Labs 小助手 发表了文章 • 0 个评论 • 5221 次浏览 • 2025-08-12 15:31 • 来自相关话题

极限科技诚招全职搜索运维工程师(Elasticsearch/Easysearch)!

欢迎搜索技术热爱者加入我们,共同打造高效、智能的搜索解决方案!

在招岗位介绍

岗位名称

搜索运维工程师(Elasticsearch/Easysearch)

Base:北京/西安
薪资待遇:10-15K,五险一金,双休等

岗位职责

  1. 负责客户现场的 Elasticsearch/Easysearch/OpenSearch 搜索引擎集群的日常维护、监控和优化,确保集群的高可用性和性能稳定;
  2. 协助客户进行搜索引擎集群的部署、配置及版本升级;
  3. 排查和解决 Elasticsearch/Easysearch/OpenSearch 集群中的各种技术问题,及时响应并处理集群异常;
  4. 根据业务需求设计和实施搜索索引的调优、数据迁移和扩展方案;
  5. 负责与客户沟通,提供技术支持及相关培训,确保客户需求得到有效满足;
  6. 制定并实施搜索引擎的备份、恢复和安全策略,保障数据安全;
  7. 与内部研发团队和外部客户进行协作,推动集群性能改进和功能优化。

岗位要求

  1. 全日制本科及以上学历,2 年以上运维工作经验;
  2. 拥有 Elasticsearch/Easysearch/OpenSearch 使用经验,熟悉搜索引擎的原理、架构和相关生态工具(如 Logstash、Kibana 等);
  3. 熟悉 Linux 操作系统的使用及常见性能调优方法;
  4. 熟练掌握 Shell 或 Python 等至少一种脚本语言,能够编写自动化运维脚本;
  5. 具有优秀的问题分析与解决能力,能够快速应对突发情况;
  6. 具备良好的沟通能力和团队合作精神,能够接受客户驻场工作;
  7. 提供 五险一金,享有带薪年假及法定节假日。

加分项

  1. 计算机科学、信息技术或相关专业;
  2. 具备丰富的大规模分布式系统运维经验;
  3. 熟悉 Elasticsearch/Easysearch/OpenSearch 分片、路由、查询优化等高级功能;
  4. 拥有 Elastic Certified Engineer 认证;
  5. 具备大规模搜索引擎集群设计、扩展和调优经验;
  6. 熟悉其他搜索引擎技术(如 Solr、Lucene)者优先;
  7. 熟悉大数据处理相关技术(比如: Kafka 、Flink 等)者优先。

简历投递

  1. 邮件:hello@infini.ltd(邮件标题请备注姓名+求职岗位)
  2. 微信:INFINI-Labs (加微请备注求职岗位)

关于极限科技(INFINI Labs)

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

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

官网:https://infinilabs.cn

我们在做什么

极限科技(INFINI Labs)正在致力于以下几个核心方向:

1、开发近实时搜索引擎 INFINI Easysearch
INFINI Easysearch 是一个分布式的搜索型数据库,实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以替代 Elasticsearch,同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。详情参见:https://infinilabs.cn

2、打造下一代实时搜索引擎 INFINI Pizza
INFINI Pizza 是一个分布式混合搜索数据库系统。我们的使命是充分利用现代硬件和人工智能的潜力,为企业提供量身定制的实时智能搜索体验。我们致力于满足具有挑战性的环境中高并发和高吞吐量的需求,同时提供无缝高效的搜索功能。详情参见:https://pizza.rs

3、为现代团队打造的统一搜索与 AI 智能助手 Coco AI
Coco AI 是一款完全开源的统一搜索与 AI 助手平台,它通过统一搜索入口,连接企业内外部的异构数据源,融合大模型能力,帮助团队高效访问知识,智能决策协作。详情参见:https://coco.rs

4、积极参与全球开源生态建设
通过开源 Coco AI、Console、Gateway、Agent、Loadgen 等搜索领域产品和社区贡献,推动全球开源技术的发展,提升中国在全球开源领域的影响力。INFINI Labs Github 主页:https://github.com/infinilabs

5、提供专业服务
为客户提供包括搜索技术支持、迁移服务、定制解决方案和培训在内的全方位服务。

6、提供国产化搜索解决方案
针对中国市场的特殊需求,提供符合国产化标准的搜索产品和解决方案,帮助客户解决使用 Elasticsearch 时遇到的挑战。

极限科技(INFINI Labs)通过这些努力,旨在成为全球领先的实时搜索和数据分析解决方案提供商。

ES 调优帖:Gateway 批量写入性能优化实践

ElasticsearchINFINI Labs 小助手 发表了文章 • 0 个评论 • 6380 次浏览 • 2025-08-06 17:32 • 来自相关话题

背景:bulk 优化的应用

在 ES 的写入优化里,bulk 操作被广泛地用于批量处理数据。bulk 操作允许用户一次提交多个数据操作,如索引、更新、删除等,从而提高数据处理效率。bulk 操作的实现原理是,将数据操作请求打包成 HTTP 请求,并批量提交给 Elasticsearch 服务器。这样,Elasticsearch 服务器就可以一次处理多个数据操作,从而提高处理效率。

这种优化的核心价值在于减少了网络往返的次数和连接建立的开销。每一次单独的写入操作都需要经历完整的请求-响应周期,而批量写入则是将多个操作打包在一起,用一次通信完成原本需要多次交互的工作。这不仅仅节省了时间,更重要的是释放了系统资源,让服务器能够专注于真正的数据处理,而不是频繁的协议握手和状态维护。

这样的批量请求的确是可以优化写入请求的效率,让 ES 集群获得更多的资源去做写入请求的集中处理。但是除了客户端与 ES 集群的通讯效率优化,还有其他中间过程能优化么?

Gateway 的优化点

bulk 的优化理念是将日常零散的写入需求做集中化的处理,尽量减低日常请求的损耗,完成资源最大化的利用。简而言之就是“好钢用在刀刃上”。

但是 ES 在收到 bulk 写入请求后,也是需要协调节点根据文档的 id 计算所属的分片来将数据分发到对应的数据节点的。这个过程也是有一定损耗的,如果 bulk 请求中数据分布的很散,每个分片都需要进行写入,原本 bulk 集中写入的需求优势则还是没有得到最理想化的提升。

gateway 的写入加速则对 bulk 的优化理念的最大化补全。

gateway 可以本地计算每个索引文档对应后端 Elasticsearch 集群的目标存放位置,从而能够精准的进行写入请求定位

在一批 bulk 请求中,可能存在多个后端节点的数据,bulk_reshuffle 过滤器用来将正常的 bulk 请求打散,按照目标节点或者分片进行拆分重新组装,避免 Elasticsearch 节点收到请求之后再次进行请求分发, 从而降低 Elasticsearch 集群间的流量和负载,也能避免单个节点成为热点瓶颈,确保各个数据节点的处理均衡,从而提升集群总体的索引吞吐能力。

整理的优化思路如下图:

优化实践

那我们来实践一下,看看 gateway 能提升多少的写入。

这里我们分 2 个测试场景:

  1. 基础集中写入测试,不带文档 id,直接批量写入。这个场景更像是日志或者监控数据采集的场景。
  2. 带文档 id 的写入测试,更偏向搜索场景或者大数据批同步的场景。

2 个场景都进行直接写入 ES 和 gateway 转发 ES 的效率比对。

测试材料除了需要备一个网关和一套 es 外,其余的内容如下:

测试索引 mapping 一致,名称区分:

PUT gateway_bulk_test
{
  "settings": {
    "number_of_shards": 6,
    "number_of_replicas": 0
  },
  "mappings": {
    "properties": {
      "timestamp": {
        "type": "date",
        "format": "strict_date_optional_time"
      },
      "field1": {
        "type": "keyword"
      },
      "field2": {
        "type": "keyword"
      },
      "field3": {
        "type": "keyword"
      },
      "field4": {
        "type": "integer"
      },
      "field5": {
        "type": "keyword"
      },
      "field6": {
        "type": "float"
      }
    }
  }
}

PUT bulk_test
{
  "settings": {
    "number_of_shards": 6,
    "number_of_replicas": 0
  },
  "mappings": {
    "properties": {
      "timestamp": {
        "type": "date",
        "format": "strict_date_optional_time"
      },
      "field1": {
        "type": "keyword"
      },
      "field2": {
        "type": "keyword"
      },
      "field3": {
        "type": "keyword"
      },
      "field4": {
        "type": "integer"
      },
      "field5": {
        "type": "keyword"
      },
      "field6": {
        "type": "float"
      }
    }
  }
}

gateway 的配置文件如下:

path.data: data
path.logs: log

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 200000
    network:
      binding: 0.0.0.0:8000

flow:
  - name: async_bulk
    filter:
      - bulk_reshuffle:
          when:
            contains:
              _ctx.request.path: /_bulk
          elasticsearch: prod
          level: node
          partition_size: 1
          fix_null_id: true
      - elasticsearch:
          elasticsearch: prod #elasticsearch configure reference name
          max_connection_per_node: 1000 #max tcp connection to upstream, default for all nodes
          max_response_size: -1 #default for all nodes
          balancer: weight
          refresh: # refresh upstream nodes list, need to enable this feature to use elasticsearch nodes auto discovery
            enabled: true
            interval: 60s
          filter:
            roles:
              exclude:
                - master

router:
  - name: my_router
    default_flow: async_bulk

elasticsearch:
  - name: prod
    enabled: true
    endpoints:
      - https://127.0.0.1:9221
      - https://127.0.0.1:9222
      - https://127.0.0.1:9223
    basic_auth:
      username: admin
      password: admin

pipeline:
  - name: bulk_request_ingest
    auto_start: true
    keep_running: true
    retry_delay_in_ms: 1000
    processor:
      - bulk_indexing:
          max_connection_per_node: 100
          num_of_slices: 3
          max_worker_size: 30
          idle_timeout_in_seconds: 10
          bulk:
            compress: false
            batch_size_in_mb: 10
            batch_size_in_docs: 10000
          consumer:
            fetch_max_messages: 100
          queue_selector:
            labels:
              type: bulk_reshuffle

测试脚本如下:

#!/usr/bin/env python3
"""
ES Bulk写入性能测试脚本

"""

import hashlib
import json
import random
import string
import time
from typing import List, Dict, Any

import requests
from concurrent.futures import ThreadPoolExecutor
from datetime import datetime
import urllib3

# 禁用SSL警告
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

class ESBulkTester:
    def __init__(self):
        # 配置变量 - 可修改
        self.es_configs = [
            {
                "name": "ES直连",
                "url": "https://127.0.0.1:9221",
                "index": "bulk_test",
                "username": "admin",  # 修改为实际用户名
                "password": "admin",  # 修改为实际密码
                "verify_ssl": False  # HTTPS需要SSL验证
            },
            {
                "name": "Gateway代理",
                "url": "http://localhost:8000",
                "index": "gateway_bulk_test",
                "username": None,  # 无需认证
                "password": None,
                "verify_ssl": False
            }
        ]
        self.batch_size = 10000  # 每次bulk写入条数
        self.log_interval = 100000  # 每多少次bulk写入输出日志

        # ID生成规则配置 - 前2位后5位
        self.id_prefix_start = 1
        self.id_prefix_end = 999      # 前3位: 01-999
        self.id_suffix_start = 1
        self.id_suffix_end = 9999   # 后4位: 0001-9999

        # 当前ID计数器
        self.current_prefix = self.id_prefix_start
        self.current_suffix = self.id_suffix_start

    def generate_id(self) -> str:
        """生成固定规则的ID - 前2位后5位"""
        id_str = f"{self.current_prefix:02d}{self.current_suffix:05d}"

        # 更新计数器
        self.current_suffix += 1
        if self.current_suffix > self.id_suffix_end:
            self.current_suffix = self.id_suffix_start
            self.current_prefix += 1
            if self.current_prefix > self.id_prefix_end:
                self.current_prefix = self.id_prefix_start

        return id_str

    def generate_random_hash(self, length: int = 32) -> str:
        """生成随机hash值"""
        random_string = ''.join(random.choices(string.ascii_letters + string.digits, k=length))
        return hashlib.md5(random_string.encode()).hexdigest()

    def generate_document(self) -> Dict[str, Any]:
        """生成随机文档内容"""
        return {
            "timestamp": datetime.now().isoformat(),
            "field1": self.generate_random_hash(),
            "field2": self.generate_random_hash(),
            "field3": self.generate_random_hash(),
            "field4": random.randint(1, 1000),
            "field5": random.choice(["A", "B", "C", "D"]),
            "field6": random.uniform(0.1, 100.0)
        }

    def create_bulk_payload(self, index_name: str) -> str:
        """创建bulk写入payload"""
        bulk_data = []

        for _ in range(self.batch_size):
            #doc_id = self.generate_id()
            doc = self.generate_document()

            # 添加index操作
            bulk_data.append(json.dumps({
                "index": {
                    "_index": index_name,
            #        "_id": doc_id
                }
            }))
            bulk_data.append(json.dumps(doc))

        return "\n".join(bulk_data) + "\n"

    def bulk_index(self, config: Dict[str, Any], payload: str) -> bool:
        """执行bulk写入"""
        url = f"{config['url']}/_bulk"
        headers = {
            "Content-Type": "application/x-ndjson"
        }

        # 设置认证信息
        auth = None
        if config.get('username') and config.get('password'):
            auth = (config['username'], config['password'])

        try:
            response = requests.post(
                url,
                data=payload,
                headers=headers,
                auth=auth,
                verify=config.get('verify_ssl', True),
                timeout=30
            )
            return response.status_code == 200
        except Exception as e:
            print(f"Bulk写入失败: {e}")
            return False

    def refresh_index(self, config: Dict[str, Any]) -> bool:
        """刷新索引"""
        url = f"{config['url']}/{config['index']}/_refresh"

        # 设置认证信息
        auth = None
        if config.get('username') and config.get('password'):
            auth = (config['username'], config['password'])

        try:
            response = requests.post(
                url,
                auth=auth,
                verify=config.get('verify_ssl', True),
                timeout=10
            )
            success = response.status_code == 200
            print(f"索引刷新{'成功' if success else '失败'}: {config['index']}")
            return success
        except Exception as e:
            print(f"索引刷新失败: {e}")
            return False

    def run_test(self, config: Dict[str, Any], round_num: int, total_iterations: int = 100000):
        """运行性能测试"""
        test_name = f"{config['name']}-第{round_num}轮"
        print(f"\n开始测试: {test_name}")
        print(f"ES地址: {config['url']}")
        print(f"索引名称: {config['index']}")
        print(f"认证: {'是' if config.get('username') else '否'}")
        print(f"每次bulk写入: {self.batch_size}条")
        print(f"总计划写入: {total_iterations * self.batch_size}条")
        print("-" * 50)

        start_time = time.time()
        success_count = 0
        error_count = 0

        for i in range(1, total_iterations + 1):
            payload = self.create_bulk_payload(config['index'])

            if self.bulk_index(config, payload):
                success_count += 1
            else:
                error_count += 1

            # 每N次输出日志
            if i % self.log_interval == 0:
                elapsed_time = time.time() - start_time
                rate = i / elapsed_time if elapsed_time > 0 else 0
                print(f"已完成 {i:,} 次bulk写入, 耗时: {elapsed_time:.2f}秒, 速率: {rate:.2f} bulk/秒")

        end_time = time.time()
        total_time = end_time - start_time
        total_docs = total_iterations * self.batch_size

        print(f"\n{test_name} 测试完成!")
        print(f"总耗时: {total_time:.2f}秒")
        print(f"成功bulk写入: {success_count:,}次")
        print(f"失败bulk写入: {error_count:,}次")
        print(f"总文档数: {total_docs:,}条")
        print(f"平均速率: {success_count/total_time:.2f} bulk/秒")
        print(f"文档写入速率: {total_docs/total_time:.2f} docs/秒")
        print("=" * 60)

        return {
            "test_name": test_name,
            "config_name": config['name'],
            "round": round_num,
            "es_url": config['url'],
            "index": config['index'],
            "total_time": total_time,
            "success_count": success_count,
            "error_count": error_count,
            "total_docs": total_docs,
            "bulk_rate": success_count/total_time,
            "doc_rate": total_docs/total_time
        }

    def run_comparison_test(self, total_iterations: int = 10000):
        """运行双地址对比测试"""
        print("ES Bulk写入性能测试开始")
        print(f"测试时间: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
        print("=" * 60)

        results = []
        rounds = 2  # 每个地址测试2轮

        # 循环测试所有配置
        for config in self.es_configs:
            print(f"\n开始测试配置: {config['name']}")
            print("*" * 40)

            for round_num in range(1, rounds + 1):
                # 运行测试
                result = self.run_test(config, round_num, total_iterations)
                results.append(result)

                # 每轮结束后刷新索引
                print(f"\n第{round_num}轮测试完成,执行索引刷新...")
                self.refresh_index(config)

                # 重置ID计数器
                if round_num == 1:
                    # 第1轮:使用初始ID范围(新增数据)
                    print("第1轮:新增数据模式")
                else:
                    # 第2轮:重复使用相同ID(更新数据模式)
                    print("第2轮:数据更新模式,复用第1轮ID")
                    self.current_prefix = self.id_prefix_start
                    self.current_suffix = self.id_suffix_start

                print(f"{config['name']} 第{round_num}轮测试结束\n")

        # 输出对比结果
        print("\n性能对比结果:")
        print("=" * 80)

        # 按配置分组显示结果
        config_results = {}
        for result in results:
            config_name = result['config_name']
            if config_name not in config_results:
                config_results[config_name] = []
            config_results[config_name].append(result)

        for config_name, rounds_data in config_results.items():
            print(f"\n{config_name}:")
            total_time = 0
            total_bulk_rate = 0
            total_doc_rate = 0

            for round_data in rounds_data:
                print(f"  第{round_data['round']}轮:")
                print(f"    耗时: {round_data['total_time']:.2f}秒")
                print(f"    Bulk速率: {round_data['bulk_rate']:.2f} bulk/秒")
                print(f"    文档速率: {round_data['doc_rate']:.2f} docs/秒")
                print(f"    成功率: {round_data['success_count']/(round_data['success_count']+round_data['error_count'])*100:.2f}%")

                total_time += round_data['total_time']
                total_bulk_rate += round_data['bulk_rate']
                total_doc_rate += round_data['doc_rate']

            avg_bulk_rate = total_bulk_rate / len(rounds_data)
            avg_doc_rate = total_doc_rate / len(rounds_data)

            print(f"  平均性能:")
            print(f"    总耗时: {total_time:.2f}秒")
            print(f"    平均Bulk速率: {avg_bulk_rate:.2f} bulk/秒")
            print(f"    平均文档速率: {avg_doc_rate:.2f} docs/秒")

        # 整体对比
        if len(config_results) >= 2:
            config_names = list(config_results.keys())
            config1_avg = sum([r['bulk_rate'] for r in config_results[config_names[0]]]) / len(config_results[config_names[0]])
            config2_avg = sum([r['bulk_rate'] for r in config_results[config_names[1]]]) / len(config_results[config_names[1]])

            if config1_avg > config2_avg:
                faster = config_names[0]
                rate_diff = config1_avg - config2_avg
            else:
                faster = config_names[1]
                rate_diff = config2_avg - config1_avg

            print(f"\n整体性能对比:")
            print(f"{faster} 平均性能更好,bulk速率高 {rate_diff:.2f} bulk/秒")
            print(f"性能提升: {(rate_diff/min(config1_avg, config2_avg)*100):.1f}%")

def main():
    """主函数"""
    tester = ESBulkTester()

    # 运行测试(每次bulk 1万条,300次bulk = 300万条文档)
    tester.run_comparison_test(total_iterations=300)

if __name__ == "__main__":
    main()

1. 日志场景:不带 id 写入

测试条件:

  1. bulk 写入数据不带文档 id
  2. 每批次 bulk 10000 条数据,总共写入 30w 数据

这里把

反馈结果:

性能对比结果:
================================================================================

ES直连:
  第1轮:
    耗时: 152.29秒
    Bulk速率: 1.97 bulk/秒
    文档速率: 19699.59 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 152.29秒
    平均Bulk速率: 1.97 bulk/秒
    平均文档速率: 19699.59 docs/秒

Gateway代理:
  第1轮:
    耗时: 115.63秒
    Bulk速率: 2.59 bulk/秒
    文档速率: 25944.35 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 115.63秒
    平均Bulk速率: 2.59 bulk/秒
    平均文档速率: 25944.35 docs/秒

整体性能对比:
Gateway代理 平均性能更好,bulk速率高 0.62 bulk/秒
性能提升: 31.7%

2. 业务场景:带文档 id 的写入

测试条件:

  1. bulk 写入数据带有文档 id,两次测试写入的文档 id 生成规则一致且重复。
  2. 每批次 bulk 10000 条数据,总共写入 30w 数据

这里把 py 脚本中 第 99 行 和 第 107 行的注释打开。

反馈结果:

性能对比结果:
================================================================================

ES直连:
  第1轮:
    耗时: 155.30秒
    Bulk速率: 1.93 bulk/秒
    文档速率: 19317.39 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 155.30秒
    平均Bulk速率: 1.93 bulk/秒
    平均文档速率: 19317.39 docs/秒

Gateway代理:
  第1轮:
    耗时: 116.73秒
    Bulk速率: 2.57 bulk/秒
    文档速率: 25700.06 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 116.73秒
    平均Bulk速率: 2.57 bulk/秒
    平均文档速率: 25700.06 docs/秒

整体性能对比:
Gateway代理 平均性能更好,bulk速率高 0.64 bulk/秒
性能提升: 33.0%

小结

不管是日志场景还是业务价值更重要的大数据或者搜索数据同步场景, gateway 的写入加速都能平稳的节省 25%-30% 的写入耗时。

关于极限网关(INFINI Gateway)

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

官网文档:https://docs.infinilabs.com/gateway
开源地址:https://github.com/infinilabs/gateway

作者:金多安,极限科技(INFINI Labs)搜索运维专家,Elastic 认证专家,搜索客社区日报责任编辑。一直从事与搜索运维相关的工作,日常会去挖掘 ES / Lucene 方向的搜索技术原理,保持搜索相关技术发展的关注。
原文:https://infinilabs.cn/blog/2025/gateway-bulk-write-performance-optimization/

elasticsearcg索引配置不变,doc数量不变却越写越慢

Elasticsearchkin122 回复了问题 • 2 人关注 • 3 个回复 • 6231 次浏览 • 2025-07-30 08:47 • 来自相关话题

【搜索客社区日报】第2055期 (2025-06-16)

社区日报Muses 发表了文章 • 0 个评论 • 2314 次浏览 • 2025-06-17 17:41 • 来自相关话题

1、Easysearch 索引备份之 Clone API https://infinilabs.cn/blog/202 ... -api/ 2、私有知识库 Coco AI 实战(一):Coco Server Linux 平台部署 https://infinilabs.cn/blog/202 ... on-1/、 3、风口|继MoE、MCP与A2A之后,下一个模型协作风口是MoA https://mp.weixin.qq.com/s/_yv9gdBKv1yDK0rQNtbbiQ 4、干货:手把手搭建ElasticSearch日志监控告警 https://mp.weixin.qq.com/s/JH2AIAnxdFSPhsG7h-9y_g 5、搭建持久化的 INFINI Console 与 Easysearch 容器环境 https://infinilabs.cn/blog/202 ... cker/ 编辑:Muse 更多资讯:http://news.searchkit.cn

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

活动liaosy 发表了文章 • 0 个评论 • 3372 次浏览 • 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

elasticsearcg索引配置不变,doc数量不变却越写越慢

回复

Elasticsearchkin122 回复了问题 • 2 人关注 • 3 个回复 • 6231 次浏览 • 2025-07-30 08:47 • 来自相关话题

【字节跳动】 深圳/上海招聘Elasticsearch研发工程师

回复

求职招聘tinycols 发起了问题 • 1 人关注 • 0 个回复 • 3699 次浏览 • 2024-12-05 16:57 • 来自相关话题

3月26日 OpenSearch Community Meeting 视频回放

回复

OpenSearchCharele 回复了问题 • 2 人关注 • 1 个回复 • 5526 次浏览 • 2024-04-05 16:58 • 来自相关话题

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

回复

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

【搜索客社区日报】第2123期 (2025-09-29)

社区日报Muses 发表了文章 • 0 个评论 • 3521 次浏览 • 2025-09-29 15:18 • 来自相关话题

1、理解 Elasticsearch 中的分块策略 https://elasticstack.blog.csdn ... 72259 2、从 Uptime 到 Synthetics 在 Elastic 中的迁移手册 https://elasticstack.blog.csdn ... 84573 3、你的第一个 Elastic Agent:从单个查询到 AI 驱动的聊天 https://elasticstack.blog.csdn ... 14746 4、Elasticsearch 插件用于 UBI:在 Kibana 中分析用户数据 https://elasticstack.blog.csdn ... 59534 5、MCP 工具:自主代理的攻击向量与防御建议 https://elasticstack.blog.csdn ... 68195 编辑:Muse 更多资讯:http://news.searchkit.cn

【搜索客社区日报】第2119期 (2025-09-22)

社区日报Muses 发表了文章 • 0 个评论 • 6068 次浏览 • 2025-09-22 13:44 • 来自相关话题

1、使用 TwelveLabs 的 Marengo 视频嵌入模型与 Amazon Bedrock 和 Elasticsearch https://elasticstack.blog.csdn ... 92083 2、在 Elasticsearch 和 GCP 上的混合搜索和语义重排序 https://elasticstack.blog.csdn ... 52822 3、Elasticsearch 的 ES|QL 编辑器体验 vs. OpenSearch 的 PPL 事件分析器 https://elasticstack.blog.csdn ... 51492 4、ES 数据迁移之 INFINI Gateway https://www.infinilabs.cn/blog ... eway/ 5、AI Agent 主流的设计模式(ReAct,Reflection,LATS)其实没有很复杂。 https://mp.weixin.qq.com/s/7CZ6cHWQ-T9bmaWoJFwdwA 编辑:Muse 更多资讯:http://news.searchkit.cn

招聘!搜索运维工程师(Elasticsearch/Easysearch)-全职/北京/12-20K

求职招聘INFINI Labs 小助手 发表了文章 • 0 个评论 • 6151 次浏览 • 2025-09-22 12:33 • 来自相关话题

极限科技诚招全职搜索运维工程师(Elasticsearch/Easysearch)!

欢迎搜索技术热爱者加入我们,共同打造高效、智能的搜索解决方案!

在招岗位介绍

岗位名称

搜索运维工程师(Elasticsearch/Easysearch)

Base:北京
薪资待遇:12-20K,五险一金,双休等

岗位职责

  1. 负责客户现场的 Elasticsearch/Easysearch/OpenSearch 搜索引擎集群的日常维护、监控和优化,确保集群的高可用性和性能稳定;
  2. 协助客户进行搜索引擎集群的部署、配置及版本升级;
  3. 排查和解决 Elasticsearch/Easysearch/OpenSearch 集群中的各种技术问题,及时响应并处理集群异常;
  4. 根据业务需求设计和实施搜索索引的调优、数据迁移和扩展方案;
  5. 负责与客户沟通,提供技术支持及相关培训,确保客户需求得到有效满足;
  6. 制定并实施搜索引擎的备份、恢复和安全策略,保障数据安全;
  7. 与内部研发团队和外部客户进行协作,推动集群性能改进和功能优化。

岗位要求

  1. 全日制本科及以上学历,2 年以上运维工作经验;
  2. 拥有 Elasticsearch/Easysearch/OpenSearch 使用经验,熟悉搜索引擎的原理、架构和相关生态工具(如 Logstash、Kibana 等);
  3. 熟悉 Linux 操作系统的使用及常见性能调优方法;
  4. 熟练掌握 Shell 或 Python 等至少一种脚本语言,能够编写自动化运维脚本;
  5. 具有优秀的问题分析与解决能力,能够快速应对突发情况;
  6. 具备良好的沟通能力和团队合作精神,能够接受客户驻场工作;
  7. 提供 五险一金,享有带薪年假及法定节假日。

加分项

  1. 计算机科学、信息技术或相关专业;
  2. 具备丰富的大规模分布式系统运维经验;
  3. 熟悉 Elasticsearch/Easysearch/OpenSearch 分片、路由、查询优化等高级功能;
  4. 拥有 Elastic Certified Engineer 认证;
  5. 具备大规模搜索引擎集群设计、扩展和调优经验;
  6. 熟悉其他搜索引擎技术(如 Solr、Lucene)者优先;
  7. 熟悉大数据处理相关技术(比如: Kafka 、Flink 等)者优先。

简历投递

  1. 邮件:hello@infini.ltd(邮件标题请备注姓名 求职岗位)
  2. 微信:INFINI-Labs (加微请备注求职岗位)

关于极限科技(INFINI Labs)

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

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

官网:https://infinilabs.cn

我们在做什么

极限科技(INFINI Labs)正在致力于以下几个核心方向:

1、开发近实时搜索引擎 INFINI Easysearch INFINI Easysearch 是一个分布式的搜索型数据库,实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以替代 Elasticsearch,同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。详情参见:https://infinilabs.cn

2、打造下一代实时搜索引擎 INFINI Pizza INFINI Pizza 是一个分布式混合搜索数据库系统。我们的使命是充分利用现代硬件和人工智能的潜力,为企业提供量身定制的实时智能搜索体验。我们致力于满足具有挑战性的环境中高并发和高吞吐量的需求,同时提供无缝高效的搜索功能。详情参见:https://pizza.rs

3、为现代团队打造的统一搜索与 AI 智能助手 Coco AI Coco AI 是一款完全开源的统一搜索与 AI 助手平台,它通过统一搜索入口,连接企业内外部的异构数据源,融合大模型能力,帮助团队高效访问知识,智能决策协作。详情参见:https://coco.rs

4、积极参与全球开源生态建设 通过开源 Coco AI、Console、Gateway、Agent、Loadgen 等搜索领域产品和社区贡献,推动全球开源技术的发展,提升中国在全球开源领域的影响力。INFINI Labs Github 主页:https://github.com/infinilabs

5、提供专业服务 为客户提供包括搜索技术支持、迁移服务、定制解决方案和培训在内的全方位服务。

6、提供国产化搜索解决方案 针对中国市场的特殊需求,提供符合国产化标准的搜索产品和解决方案,帮助客户解决使用 Elasticsearch 时遇到的挑战。

极限科技(INFINI Labs)通过这些努力,旨在成为全球领先的实时搜索和数据分析解决方案提供商。

如何使用极限网关实现 Elasticsearch 集群迁移至 Easysearch

ElasticsearchINFINI Labs 小助手 发表了文章 • 0 个评论 • 6429 次浏览 • 2025-09-21 14:50 • 来自相关话题

之前有博客介绍过通过 Reindex 的方法将 Elasticsearch 的数据迁移到 Easysearch 集群,今天再介绍一个方法,通过 极限网关(INFINI Gateway) 来进行数据迁移。

测试环境

软件 版本
Easysearch 1.12.0
Elasticsearch 7.17.29
INFINI Gateway 1.29.2

迁移步骤

  1. 选定要迁移的索引
  2. 在目标集群建立索引的 mapping 和 setting
  3. 准备 INFINI Gateway 迁移配置
  4. 运行 INFINI Gateway 进行数据迁移

迁移实战

  1. 选定要迁移的索引

在 Elasticsearch 集群中选择目标索引:infinilabs 和 test1,没错,我们一次可以迁移多个。

  1. 在 Easysearch 集群使用源索引的 setting 和 mapping 建立目标索引。(略)
  2. INFINI Gateway 迁移配置准备

去 github 下载配置,修改下面的连接集群的部分

  1 env:
  2   LR_GATEWAY_API_HOST: 127.0.0.1:2900
  3   SRC_ELASTICSEARCH_ENDPOINT: http://127.0.0.1:9200
  4   DST_ELASTICSEARCH_ENDPOINT: http://127.0.0.1:9201
  5 path.data: data
  6 path.logs: log
  7 progress_bar.enabled: true
  8 configs.auto_reload: true
  9
 10 api:
 11   enabled: true
 12   network:
 13     binding: $[[env.LR_GATEWAY_API_HOST]]
 14
 15 elasticsearch:
 16   - name: source
 17     enabled: true
 18     endpoint: $[[env.SRC_ELASTICSEARCH_ENDPOINT]]
 19     basic_auth:
 20       username: elastic
 21       password: goodgoodstudy
 22
 23   - name: target
 24     enabled: true
 25     endpoint: $[[env.DST_ELASTICSEARCH_ENDPOINT]]
 26     basic_auth:
 27       username: admin
 28       password: 14da41c79ad2d744b90c

pipeline 部分修改要迁移的索引名称,我们迁移 infinilabs 和 test1 两个索引。

 31 pipeline:
 32   - name: source_scroll
 33     auto_start: true
 34     keep_running: false
 35     processor:
 36       - es_scroll:
 37           slice_size: 1
 38           batch_size: 5000
 39           indices: "infinilabs,test1"
 40           elasticsearch: source
 41           output_queue: source_index_dump
 42           partition_size: 1
 43           scroll_time: "5m"
  1. 迁移数据
./gateway-mac-arm64

#如果你保存的配置文件名称不叫 gateway.yml,则需要加参数 -config 文件名

数据导入完成后,网关 ctrl+c 退出。

至此,数据迁移就完成了。下一篇我们来介绍 INFINI Gateway 的数据比对功能。

有任何问题,欢迎加我微信沟通。

关于极限网关(INFINI Gateway)

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

官网文档:https://docs.infinilabs.com/gateway
开源地址:https://github.com/infinilabs/gateway

搜索百科(4):OpenSearch — 开源搜索的新选择

OpenSearchliaosy 发表了文章 • 0 个评论 • 6449 次浏览 • 2025-09-21 14:31 • 来自相关话题

大家好,我是 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 年 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:详细对比

特性 OpenSearch Elasticsearch
许可证 Apache 2.0(完全开源) SSPL/Elastic License/AGPLv3
起始版本 基于 Elasticsearch 7.10.2 从 7.11 开始协议变更
社区治理 开放治理模式,由社区驱动 由 Elastic NV 公司主导
安全性 所有安全功能默认开源 部分高级安全功能需要付费
AI/向量检索 近年快速跟进,兼容性较好 原生支持,功能逐步增强
部署选择 AWS OpenSearch Service / 自建 Elastic Cloud / 自建
升级路径 从 Elasticsearch 7.x 平滑迁移 原生升级路径
社区活跃度 社区逐渐壮大,受到纯开源拥护者欢迎 用户基础庞大,但分裂带来争议

快速开始: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)备注“搜索百科”,拉你进  搜索技术交流群,一起探讨与学习!

推荐阅读

🔗 参考资源

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

Easysearch 国产替代 Elasticsearch:8 大核心问题解读

Easysearchliaosy 发表了文章 • 0 个评论 • 7379 次浏览 • 2025-09-18 09:43 • 来自相关话题

近年来,随着数据安全与自主可控需求的不断提升,越来越多的企业开始关注国产化的搜索与日志分析解决方案。作为极限科技推出的国产 Elasticsearch 替代产品,Easysearch 凭借其对搜索场景的深入优化、轻量级架构设计以及对 ES 生态的高度兼容,成为众多企业替代 Elasticsearch 的新选择。

我们在近期与用户的交流中,整理出了大家最关心的八大问题,并将它们浓缩为一篇技术解读,希望帮助你快速了解 Easysearch 的优势与定位。

用户最关心的八大问题

  1. Easysearch 对数据量的支撑能力如何,能应对 PB 级数据存储吗?

答:完全可以。Easysearch 支持水平扩展,通过增加节点即可线性提升存储与计算能力。在实际应用中,已成功支撑 PB 级日志与检索数据。同时,其存储压缩率相比 Elasticsearch 7.10.2 平均高出 2.5~3 倍,显著节省硬件成本。

  1. 在高并发写入场景下,Easysearch 和 ES 的性能差异有多大?

答:在相同硬件配置下,使用 Nginx 日志进行 bulk 写入压测,Easysearch 在多种分片配置下的写入性能相比 Elasticsearch 7.10.2 提升 40%-70%,更适合高并发写入场景。

  1. 是否支持中文分词?需要额外插件吗?

答:中文分词一直是 Elasticsearch 用户的「必装插件」。而在 Easysearch 中,中文分词是开箱即用的,同时支持 ik、pinyin 等主流分词器,还能自定义词典,方便电商、内容平台等场景。

  1. 从 ES 迁移到 Easysearch 是否复杂?会影响业务吗?

答:迁移往往是国产替代的最大顾虑。为此,Easysearch 提供了 极限网关 工具,支持全量同步和实时增量同步。迁移过程中业务可继续读写,只需短暂切换连接地址,几乎无感知。

  1. 监控与运维工具是否完善?是否支持 Kibana?

答:Easysearch 提供完整的监控与运维体系。从 Easysearch 1.15.x 版本起自带 Web UI 管理控制台(类似简化版 Kibana),支持索引管理、查询调试、权限控制等功能。同时还提供 INFINI Console 实现多集群管理与深度监控等。也可以通过配置让 Kibana 连接 Easysearch(部分高级功能可能受限)。

  1. 小型团队技术能力有限,用 Easysearch 运维难度高吗?

答:Easysearch 的一大设计理念就是降低运维门槛。Easysearch 提供一键部署脚本,减少手动配置参数,支持自动分片均衡与故障节点恢复,无需专职运维人员也能稳定运行,非常适合技术资源有限的团队。

  1. Easysearch 是否支持数据备份与恢复?操作复杂吗?

答:支持快照(Snapshot),可备份到本地磁盘或对象存储(S3、OSS 等)。恢复时仅需执行快照恢复命令,满足企业级数据安全需求。

  1. 对比 ES,Easysearch 在使用体验上最大的不同是什么?

答:Easysearch 保持与 Elasticsearch 类似的接口与查询 DSL,用户几乎无学习成本即可上手。同时,它针对国产化环境和搜索场景做了优化,运维更轻量,成本更可控。

结语:Easysearch,国产化搜索的新选择

作为一款国产自主可控的搜索与日志分析引擎,Easysearch 不仅继承了 Elasticsearch 的核心能力,更在性能、易用性、资源效率和中文支持等方面进行了深度优化。对于希望实现国产化替代、降低运维成本、提升系统性能的企业来说,Easysearch 是一个值得认真考虑的新选择。

如果你正在评估 Elasticsearch 的替代方案,不妨从 Easysearch 开始,体验更轻量、更高效的搜索新架构。

如需了解更多技术细节与使用案例,欢迎访问官方文档与社区资源:

  1. Easysearch 官网文档
  2. Elasticsearch VS Easysearch 性能测试
  3. 使用 Easysearch,日志存储少一半
  4. Kibana OSS 7.10.2 连接 Easysearch
  5. 自建 ES 集群通过极限网关无缝迁移到云上
  6. INFINI Console 一站式的数据搜索分析与管理平台

搜索百科(3):Elasticsearch — 搜索界的“流量明星”

Elasticsearchliaosy 发表了文章 • 0 个评论 • 6014 次浏览 • 2025-09-16 11:20 • 来自相关话题

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

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

前两篇我们探讨了搜索技术的基石 Apache Lucene企业级搜索解决方案 Apache Solr。今天,我们来聊聊一个真正改变搜索游戏规则,但也充满争议的产品 — Elasticsearch

引言

如果说 Lucene 是幕后英雄,那么 Elasticsearch 就是舞台中央的明星。借助 REST API、分布式架构、强大的生态系统,它让搜索 + 分析成为“马上可用”的服务形式。

在日志平台、可观察性、安全监控、AI 与语义检索等领域,Elasticsearch 的名字几乎成了默认选项。

Elasticsearch 概述

Elasticsearch 是一个开源的分布式搜索和分析引擎,构建于 Apache Lucene 之上。作为一个检索平台,它可以实时存储结构化、非结构化和向量数据,提供快速的混合和向量搜索,支持可观测性与安全分析,并以高性能、高准确性和高相关性实现 AI 驱动的应用。

起源:从食谱搜索到全球“流量明星”

Elasticsearch 的故事始于以色列开发者 Shay Banon。2010 年,当时他在学习厨师课程的妻子需要一款能够快速搜索食谱的工具。虽然当时已经有 Solr 这样的搜索解决方案,但 Shay 认为它们对于分布式场景的支持不够完善。

基于之前开发 Compass(一个基于 Lucene 的搜索库)的经验,Shay 开始构建一个完全分布式的、基于 JSON 的搜索引擎。2010 年 2 月,Elasticsearch 的第一个版本发布。

随着用户日益增多、企业级需求增强,Shay 在 2012 年创立了 Elastic 公司,把 Elasticsearch 不仅作为开源项目,也逐渐商业化运营起来,包括提供托管服务、企业支持,加入 Logstash 日志处理、Kibana 可视化工具等,Elastic 公司也逐渐从一个纯搜索引擎项目演变为一个更广泛的“数据搜索与分析”平台。

协议变更:开源和商业化的博弈

Elasticsearch 的发展并非一帆风顺。其历史上最具转折性的事件当属与 AWS 的冲突及随之而来的开源协议变更

  1. 早期:Apache 2.0 协议

2010 年 Shay Banon 开源 Elasticsearch 时,最初采用的是 Apache 2.0 协议。Apache 2.0 属于宽松的自由协议,允许任何人免费使用、修改和商用(包括 SaaS 模式)。这帮助 Elasticsearch 快速壮大,成为事实上的“搜索引擎标准”。

  1. 协议变更:应对云厂商“白嫖”

随着 Elasticsearch 的流行,像 AWS(Amazon Web Services) 等云厂商直接将 Elasticsearch 做成托管服务,并从中获利。Elastic 公司认为这损害了他们的商业利益,因为云厂商“用开源赚钱,却没有回馈社区”。2021 年 1 月,Elastic 宣布 Elasticsearch 和 Kibana 不再采用 Apache 2.0,改为 双重协议:SSPL + Elastic License。这一步导致社区巨大分裂,AWS 带头将 Elasticsearch 分叉为 OpenSearch,并继续以 Apache 2.0 协议维护。

  1. 再次转向开源:AGPL v3

2024 年 3 月,Elastic 宣布新的版本(Elasticsearch 8.13 起)又新增 AGPL v3 作为一个开源许可选项。AGPL v3 既符合 OSI 真正开源标准,又能约束云厂商闭源托管服务,同时修复社区关系,Elastic 希望通过重新拥抱开源,减少分裂,吸引开发者回归。

Elasticsearch 从宽松到收紧,再到回归开源,是在社区生态与商业利益间寻找平衡的过程。

基本概念

要学习 Elasticsearch,得先了解其五大基本概览:集群、节点、分片、索引和文档。

  1. 集群(Cluster)

由一个或多个节点组成的整体,提供统一的搜索与存储服务。对外看起来像一个单一系统。

  1. 节点(Node)

集群中的一台服务器实例。节点有不同角色:

  • Master 节点:负责集群管理(分片分配、元数据维护)。
  • Data 节点:存储数据、处理搜索和聚合。
  • Coordinating 节点:接收请求并调度任务。
  • Ingest 节点:负责数据写入前的预处理。
  1. 索引(Index)

类似于传统数据库的“库”,按逻辑组织数据。一个索引往往对应一个业务场景(如日志、商品信息)。

  1. 分片(Shard)

为了让索引能水平扩展,Elasticsearch 会把索引拆分为多个 主分片,并为每个主分片创建 副本分片,提升高可用和查询性能。

  1. 文档(Document)

Elasticsearch 存储和检索的最小数据单元,通常是 JSON 格式。多个文档组成一个索引。

集群架构

Elasticsearch 通过 Master、Data、Coordinating、Ingest 等不同角色节点的协作,将数据切分成分片并分布式存储,实现了高可用、可扩展的搜索与分析引擎架构。

快速开始:5 分钟体验 Elasticsearch

1. 使用 Docker 启动

# 拉取最新镜像
docker pull docker.elastic.co/elasticsearch/elasticsearch:9.1.3

# 启动单节点集群
docker run -d --name elasticsearch \
  -p 9200:9200 -p 9300:9300 \
  -e "discovery.type=single-node" \
  -e "xpack.security.enabled=false" \
  docker.elastic.co/elasticsearch/elasticsearch:9.1.3

2. 验证安装

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

3. 索引文档

# 索引文档
curl -X POST "http://localhost:9200/myindex/_doc" -H 'Content-Type: application/json' -d'
{
"title": "Hello Elasticsearch",
"description": "An example document"
}'

3. 搜索文档

# 搜索文档
curl -X GET "http://localhost:9200/myindex/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "title": "Hello"
    }
  }
}'

结语

Elasticsearch 是搜索与分析领域标杆性的产品。它将 Lucene 的能力包装起来,加上分布式、易用以及与数据可视化、安全监控等功能的整合,使搜索引擎从专业技术逐渐变为“随手可用”的基础设施。

虽然协议变动、与 OpenSearch 的分叉引发争议,但它在企业与开发者群体中的实际应用价值依然难以替代。


🚀 下期预告

下一篇我们将介绍 OpenSearch,探讨这个 Elasticsearch 分支项目的发展现状、技术特点以及与 Elasticsearch 的详细对比。如果您有特别关注的问题,欢迎提前提出!

💬 三连互动

  1. 你或公司最近在用 Elasticsearch 吗?拿来做了什么场景?
  2. 在 Elasticsearch 和 OpenSearch 之间做过技术选型?
  3. 对 Elasticsearch 的许可证变化有什么看法?

对搜索技术感兴趣的朋友,也欢迎加我微信(ID:lsy965145175)备注“搜索百科”,拉你进  搜索技术交流群,一起探讨与学习!

✨ 推荐阅读

🔗 参考

原文:https://infinilabs.cn/blog/2025/search-wiki-3-elasticsearch/

搜索百科(2):Apache Solr — 企业级搜索的开源先锋

开源项目liaosy 发表了文章 • 0 个评论 • 5161 次浏览 • 2025-09-15 18:12 • 来自相关话题

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

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

上一篇我们认识了搜索技术的基石 Apache Lucene,今天我们将继续这个旅程,了解基于 Lucene 构建的第一个成功商业级搜索平台 —— Apache Solr

Solr 是什么?

Solr 是一款极速的开源多模态搜索平台,基于 Apache Lucene 的全文、向量和地理空间搜索能力构建而成。Solr 具备高可靠性、可扩展性和容错性,支持分布式索引、复制与负载均衡查询,提供自动故障转移与恢复、集中化配置等功能。如今,Solr 为全球众多大型互联网网站提供搜索和导航功能。

它的定位是:把 Lucene 打造成独立的企业级搜索服务。相比 Lucene 需要写代码调用,Solr 提供了 Web 管理界面、REST API 和配置文件,让开发者更容易上手。

起源:从网站搜索到 Apache 顶级项目

Solr(读作"solar")的故事始于 2004 年,当时 CNET 公司的开发人员 Yonik Seeley 需要为其新闻网站构建一个搜索功能。虽然 Lucene 提供了强大的核心搜索能力,但直接使用 Lucene 需要编写大量 Java 代码,缺乏开箱即用的功能。

Seeley 决定在 Lucene 之上构建一个更易用的搜索服务器,于是 Solr 诞生了。最初的目标很明确:通过 HTTP/XML 接口提供搜索服务,让任何编程语言都能轻松集成搜索功能。

2006 年,Solr 捐赠给 Apache 基金会,2007 年成为顶级项目。2010 年,Solr 与 Lucene 项目合并,形成了今天我们所知的 Apache Lucene/Solr 项目。

技术架构

Index(索引)

Apache Solr 的索引就像是用于管理结构化 / 非结构化数据的“数据库”。它以便于分析和全文检索的方式存储数据。

Query Parser(查询解析器)

所有由客户端提交的查询都会由查询解析器处理。

Response Handler(响应处理器)

响应处理器负责为客户端生成合适格式的响应(如 JSON/XML/CSV)。

Update Handler(更新处理器)

更新处理器用于索引操作,即对索引中的数据进行插入、更新和删除。例如,如果我们希望 MySQL 数据与 Apache Solr 保持同步,就需要创建一个负责同步的更新处理器。

功能亮点

  • 全文检索:高效支持关键词搜索、布尔查询、短语匹配等。
  • 分面搜索(Faceted Search):可以对搜索结果进行分类和聚合统计。
  • 分布式架构(SolrCloud):支持集群部署、自动分片、副本和容错。
  • 丰富的数据接口:提供 RESTful API,支持 JSON、XML、CSV 等多种格式的数据交互。
  • 扩展性与可定制性:通过插件机制支持多语言分词、排序、评分模型等个性化定制。
  • 地理位置搜索:内置空间搜索能力,支持基于经纬度的范围查询和排序。

对比: Solr vs Elasticsearch 如何选择?

虽然两者都基于 Lucene,但在设计哲学上有所不同:

特性 Apache Solr Elasticsearch
定位 企业级搜索服务器 分布式搜索和分析引擎
API 更标准化,遵循传统 REST 更灵活,JSON 原生
分布式 需要 ZooKeeper 协调 内置分布式协调
上手难度 相对简单,开箱即用 学习曲线较陡峭
生态系统 搜索功能更丰富 分析和可视化更强
适用场景 传统企业搜索、电商 日志分析、实时监控

简单来说:Solr 更像"精装房",开箱即用;Elasticsearch 更像"毛坯房",需要更多自定义但更灵活。

快速开始:5 分钟搭建 Solr 服务

1. 下载和安装

# 下载 8.x 版 Solr
wget https://dlcdn.apache.org/solr/solr/8.11.4/solr-8.11.4.tgz

# 解压
tar -xzf solr-8.11.4.tgz

# 启动 Solr(单机模式)
cd solr-8.11.4
bin/solr start

2. 创建 Core

# 创建测试 Core
bin/solr create -c test_core

# 查看 Core 状态
bin/solr status

3. 索引文档

# 使用 curl 索引 JSON 文档
curl http://localhost:8983/solr/test_core/update -d '
[
  {"id": "1", "title": "Solr 入门指南", "content": "Apache Solr 是企业级搜索平台"},
  {"id": "2", "title": "搜索技术演进", "content": "从 Lucene 到 Solr 的技术发展"}
]' -H 'Content-type:application/json'

# 提交更改
curl http://localhost:8983/solr/test_core/update -d '<commit/>' -H 'Content-type:application/xml'

4. 执行搜索

# 搜索"Solr"
curl "http://localhost:8983/solr/test_core/select?q=content:Solr"

# 使用 JSON 格式返回
curl "http://localhost:8983/solr/test_core/select?q=content:Solr&wt=json"

执行搜索返回结果:

访问 http://localhost:8983/solr 即可使用 Solr 的管理界面。

Dashboard:

Core Admin:

结语

从最初的公司内部工具,到成为全球范围内广泛使用的开源搜索引擎,Apache Solr 见证并推动了搜索技术的进化。尽管近年来 Elasticsearch、向量数据库和 AI 驱动的搜索技术逐渐崛起,但 Solr 依然是许多企业可靠且成熟的选择。它的故事不仅属于开源社区,也代表了搜索技术发展的一个重要阶段。


🚀 下期预告
在下一篇「搜索百科」中,我们将介绍它的明星兄弟 —— Elasticsearch

💬 三连互动

  1. 你现在还在用 Solr 吗?
  2. 在 Solr 和 Elasticsearch 之间做过技术选型?
  3. 遇到过有趣的 Solr 使用案例或挑战?

对搜索技术感兴趣的朋友,也欢迎加我微信(ID:lsy965145175)备注“搜索百科”,拉你进  搜索技术交流群,一起探讨与学习!

✨ 推荐阅读

🔗 参考

原文:https://infinilabs.cn/blog/2025/search-wiki-2-solr/

【搜索客社区日报】第2115期 (2025-09-15)

社区日报Muses 发表了文章 • 0 个评论 • 4863 次浏览 • 2025-09-15 10:49 • 来自相关话题

1、AI流程编排产品调研&实践 https://developer.damo-academy ... 25861 2、带地图的 RAG:多模态 + 地理空间 在 Elasticsearch 中 https://elasticstack.blog.csdn ... 52848 3、使用 LangExtract 和 Elasticsearch https://elasticstack.blog.csdn ... 07715 4、使用 OpenTelemetry 从你的日志中获取更多信息 https://elasticstack.blog.csdn ... 46828 5、Elasticsearch 索引字段删除,除了 Reindex 重建索引还有没有别的解决方案? https://mp.weixin.qq.com/s/IJxEQc59t4kn6ex_YGmYAQ 编辑:Muse 更多资讯:http://news.searchkit.cn

【搜索客社区日报】第2105期 (2025-09-01)

社区日报Muses 发表了文章 • 0 个评论 • 5057 次浏览 • 2025-09-01 12:17 • 来自相关话题

1、Observability:如何在隔离环境中部署 Elastic Agents https://elasticstack.blog.csdn ... 40009 2、Elasticsearch:Semantic text 字段类型 https://elasticstack.blog.csdn ... 88674 3、使用 ES|QL COMPLETION + 一个 LLM 在 5 分钟内编写一个 Chuck Norris 事实生成器 https://elasticstack.blog.csdn ... 73787 4、将 agents 连接到 Elasticsearch 使用模型上下文协议 - docker https://elasticstack.blog.csdn ... 51617 5、从炼金术到工程学:在AI浪潮中,我们如何告别RAG,拥抱真正的“上下文工程”? https://mp.weixin.qq.com/s/bZbiMDnKMEvKx18MVTYkBA 编辑:Muse 更多资讯:http://news.searchkit.cn

【搜索客社区日报】第2100期 (2025-08-25)

社区日报Muses 发表了文章 • 0 个评论 • 5289 次浏览 • 2025-08-25 10:45 • 来自相关话题

1、加速你的故障排查:使用 Elasticsearch 构建家电手册的 RAG 应用 https://elasticstack.blog.csdn ... 74533 2、使用 Ragas 评估你的 Elasticsearch LLM 应用 https://elasticstack.blog.csdn ... 99487 3、什么是 AI(人工智能)? https://elasticstack.blog.csdn ... 33166 4、Elasticsearch:什么是神经网络? https://elasticstack.blog.csdn ... 34162 5、传统 AI 与生成式 AI:IT 领导者指南 https://elasticstack.blog.csdn ... 33120 编辑:Muse 更多资讯:http://news.searchkit.cn
1、加速你的故障排查:使用 Elasticsearch 构建家电手册的 RAG 应用 https://elasticstack.blog.csdn ... 74533 2、使用 Ragas 评估你的 Elasticsearch LLM 应用 https://elasticstack.blog.csdn ... 99487 3、什么是 AI(人工智能)? https://elasticstack.blog.csdn ... 33166 4、Elasticsearch:什么是神经网络? https://elasticstack.blog.csdn ... 34162 5、传统 AI 与生成式 AI:IT 领导者指南 https://elasticstack.blog.csdn ... 33120 编辑:Muse 更多资讯:http://news.searchkit.cn

极限科技(INFINI Labs)招聘搜索运维工程师(Elasticsearch/Easysearch)

求职招聘INFINI Labs 小助手 发表了文章 • 0 个评论 • 5221 次浏览 • 2025-08-12 15:31 • 来自相关话题

极限科技诚招全职搜索运维工程师(Elasticsearch/Easysearch)!

欢迎搜索技术热爱者加入我们,共同打造高效、智能的搜索解决方案!

在招岗位介绍

岗位名称

搜索运维工程师(Elasticsearch/Easysearch)

Base:北京/西安
薪资待遇:10-15K,五险一金,双休等

岗位职责

  1. 负责客户现场的 Elasticsearch/Easysearch/OpenSearch 搜索引擎集群的日常维护、监控和优化,确保集群的高可用性和性能稳定;
  2. 协助客户进行搜索引擎集群的部署、配置及版本升级;
  3. 排查和解决 Elasticsearch/Easysearch/OpenSearch 集群中的各种技术问题,及时响应并处理集群异常;
  4. 根据业务需求设计和实施搜索索引的调优、数据迁移和扩展方案;
  5. 负责与客户沟通,提供技术支持及相关培训,确保客户需求得到有效满足;
  6. 制定并实施搜索引擎的备份、恢复和安全策略,保障数据安全;
  7. 与内部研发团队和外部客户进行协作,推动集群性能改进和功能优化。

岗位要求

  1. 全日制本科及以上学历,2 年以上运维工作经验;
  2. 拥有 Elasticsearch/Easysearch/OpenSearch 使用经验,熟悉搜索引擎的原理、架构和相关生态工具(如 Logstash、Kibana 等);
  3. 熟悉 Linux 操作系统的使用及常见性能调优方法;
  4. 熟练掌握 Shell 或 Python 等至少一种脚本语言,能够编写自动化运维脚本;
  5. 具有优秀的问题分析与解决能力,能够快速应对突发情况;
  6. 具备良好的沟通能力和团队合作精神,能够接受客户驻场工作;
  7. 提供 五险一金,享有带薪年假及法定节假日。

加分项

  1. 计算机科学、信息技术或相关专业;
  2. 具备丰富的大规模分布式系统运维经验;
  3. 熟悉 Elasticsearch/Easysearch/OpenSearch 分片、路由、查询优化等高级功能;
  4. 拥有 Elastic Certified Engineer 认证;
  5. 具备大规模搜索引擎集群设计、扩展和调优经验;
  6. 熟悉其他搜索引擎技术(如 Solr、Lucene)者优先;
  7. 熟悉大数据处理相关技术(比如: Kafka 、Flink 等)者优先。

简历投递

  1. 邮件:hello@infini.ltd(邮件标题请备注姓名+求职岗位)
  2. 微信:INFINI-Labs (加微请备注求职岗位)

关于极限科技(INFINI Labs)

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

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

官网:https://infinilabs.cn

我们在做什么

极限科技(INFINI Labs)正在致力于以下几个核心方向:

1、开发近实时搜索引擎 INFINI Easysearch
INFINI Easysearch 是一个分布式的搜索型数据库,实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以替代 Elasticsearch,同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。详情参见:https://infinilabs.cn

2、打造下一代实时搜索引擎 INFINI Pizza
INFINI Pizza 是一个分布式混合搜索数据库系统。我们的使命是充分利用现代硬件和人工智能的潜力,为企业提供量身定制的实时智能搜索体验。我们致力于满足具有挑战性的环境中高并发和高吞吐量的需求,同时提供无缝高效的搜索功能。详情参见:https://pizza.rs

3、为现代团队打造的统一搜索与 AI 智能助手 Coco AI
Coco AI 是一款完全开源的统一搜索与 AI 助手平台,它通过统一搜索入口,连接企业内外部的异构数据源,融合大模型能力,帮助团队高效访问知识,智能决策协作。详情参见:https://coco.rs

4、积极参与全球开源生态建设
通过开源 Coco AI、Console、Gateway、Agent、Loadgen 等搜索领域产品和社区贡献,推动全球开源技术的发展,提升中国在全球开源领域的影响力。INFINI Labs Github 主页:https://github.com/infinilabs

5、提供专业服务
为客户提供包括搜索技术支持、迁移服务、定制解决方案和培训在内的全方位服务。

6、提供国产化搜索解决方案
针对中国市场的特殊需求,提供符合国产化标准的搜索产品和解决方案,帮助客户解决使用 Elasticsearch 时遇到的挑战。

极限科技(INFINI Labs)通过这些努力,旨在成为全球领先的实时搜索和数据分析解决方案提供商。

ES 调优帖:Gateway 批量写入性能优化实践

ElasticsearchINFINI Labs 小助手 发表了文章 • 0 个评论 • 6380 次浏览 • 2025-08-06 17:32 • 来自相关话题

背景:bulk 优化的应用

在 ES 的写入优化里,bulk 操作被广泛地用于批量处理数据。bulk 操作允许用户一次提交多个数据操作,如索引、更新、删除等,从而提高数据处理效率。bulk 操作的实现原理是,将数据操作请求打包成 HTTP 请求,并批量提交给 Elasticsearch 服务器。这样,Elasticsearch 服务器就可以一次处理多个数据操作,从而提高处理效率。

这种优化的核心价值在于减少了网络往返的次数和连接建立的开销。每一次单独的写入操作都需要经历完整的请求-响应周期,而批量写入则是将多个操作打包在一起,用一次通信完成原本需要多次交互的工作。这不仅仅节省了时间,更重要的是释放了系统资源,让服务器能够专注于真正的数据处理,而不是频繁的协议握手和状态维护。

这样的批量请求的确是可以优化写入请求的效率,让 ES 集群获得更多的资源去做写入请求的集中处理。但是除了客户端与 ES 集群的通讯效率优化,还有其他中间过程能优化么?

Gateway 的优化点

bulk 的优化理念是将日常零散的写入需求做集中化的处理,尽量减低日常请求的损耗,完成资源最大化的利用。简而言之就是“好钢用在刀刃上”。

但是 ES 在收到 bulk 写入请求后,也是需要协调节点根据文档的 id 计算所属的分片来将数据分发到对应的数据节点的。这个过程也是有一定损耗的,如果 bulk 请求中数据分布的很散,每个分片都需要进行写入,原本 bulk 集中写入的需求优势则还是没有得到最理想化的提升。

gateway 的写入加速则对 bulk 的优化理念的最大化补全。

gateway 可以本地计算每个索引文档对应后端 Elasticsearch 集群的目标存放位置,从而能够精准的进行写入请求定位

在一批 bulk 请求中,可能存在多个后端节点的数据,bulk_reshuffle 过滤器用来将正常的 bulk 请求打散,按照目标节点或者分片进行拆分重新组装,避免 Elasticsearch 节点收到请求之后再次进行请求分发, 从而降低 Elasticsearch 集群间的流量和负载,也能避免单个节点成为热点瓶颈,确保各个数据节点的处理均衡,从而提升集群总体的索引吞吐能力。

整理的优化思路如下图:

优化实践

那我们来实践一下,看看 gateway 能提升多少的写入。

这里我们分 2 个测试场景:

  1. 基础集中写入测试,不带文档 id,直接批量写入。这个场景更像是日志或者监控数据采集的场景。
  2. 带文档 id 的写入测试,更偏向搜索场景或者大数据批同步的场景。

2 个场景都进行直接写入 ES 和 gateway 转发 ES 的效率比对。

测试材料除了需要备一个网关和一套 es 外,其余的内容如下:

测试索引 mapping 一致,名称区分:

PUT gateway_bulk_test
{
  "settings": {
    "number_of_shards": 6,
    "number_of_replicas": 0
  },
  "mappings": {
    "properties": {
      "timestamp": {
        "type": "date",
        "format": "strict_date_optional_time"
      },
      "field1": {
        "type": "keyword"
      },
      "field2": {
        "type": "keyword"
      },
      "field3": {
        "type": "keyword"
      },
      "field4": {
        "type": "integer"
      },
      "field5": {
        "type": "keyword"
      },
      "field6": {
        "type": "float"
      }
    }
  }
}

PUT bulk_test
{
  "settings": {
    "number_of_shards": 6,
    "number_of_replicas": 0
  },
  "mappings": {
    "properties": {
      "timestamp": {
        "type": "date",
        "format": "strict_date_optional_time"
      },
      "field1": {
        "type": "keyword"
      },
      "field2": {
        "type": "keyword"
      },
      "field3": {
        "type": "keyword"
      },
      "field4": {
        "type": "integer"
      },
      "field5": {
        "type": "keyword"
      },
      "field6": {
        "type": "float"
      }
    }
  }
}

gateway 的配置文件如下:

path.data: data
path.logs: log

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 200000
    network:
      binding: 0.0.0.0:8000

flow:
  - name: async_bulk
    filter:
      - bulk_reshuffle:
          when:
            contains:
              _ctx.request.path: /_bulk
          elasticsearch: prod
          level: node
          partition_size: 1
          fix_null_id: true
      - elasticsearch:
          elasticsearch: prod #elasticsearch configure reference name
          max_connection_per_node: 1000 #max tcp connection to upstream, default for all nodes
          max_response_size: -1 #default for all nodes
          balancer: weight
          refresh: # refresh upstream nodes list, need to enable this feature to use elasticsearch nodes auto discovery
            enabled: true
            interval: 60s
          filter:
            roles:
              exclude:
                - master

router:
  - name: my_router
    default_flow: async_bulk

elasticsearch:
  - name: prod
    enabled: true
    endpoints:
      - https://127.0.0.1:9221
      - https://127.0.0.1:9222
      - https://127.0.0.1:9223
    basic_auth:
      username: admin
      password: admin

pipeline:
  - name: bulk_request_ingest
    auto_start: true
    keep_running: true
    retry_delay_in_ms: 1000
    processor:
      - bulk_indexing:
          max_connection_per_node: 100
          num_of_slices: 3
          max_worker_size: 30
          idle_timeout_in_seconds: 10
          bulk:
            compress: false
            batch_size_in_mb: 10
            batch_size_in_docs: 10000
          consumer:
            fetch_max_messages: 100
          queue_selector:
            labels:
              type: bulk_reshuffle

测试脚本如下:

#!/usr/bin/env python3
"""
ES Bulk写入性能测试脚本

"""

import hashlib
import json
import random
import string
import time
from typing import List, Dict, Any

import requests
from concurrent.futures import ThreadPoolExecutor
from datetime import datetime
import urllib3

# 禁用SSL警告
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

class ESBulkTester:
    def __init__(self):
        # 配置变量 - 可修改
        self.es_configs = [
            {
                "name": "ES直连",
                "url": "https://127.0.0.1:9221",
                "index": "bulk_test",
                "username": "admin",  # 修改为实际用户名
                "password": "admin",  # 修改为实际密码
                "verify_ssl": False  # HTTPS需要SSL验证
            },
            {
                "name": "Gateway代理",
                "url": "http://localhost:8000",
                "index": "gateway_bulk_test",
                "username": None,  # 无需认证
                "password": None,
                "verify_ssl": False
            }
        ]
        self.batch_size = 10000  # 每次bulk写入条数
        self.log_interval = 100000  # 每多少次bulk写入输出日志

        # ID生成规则配置 - 前2位后5位
        self.id_prefix_start = 1
        self.id_prefix_end = 999      # 前3位: 01-999
        self.id_suffix_start = 1
        self.id_suffix_end = 9999   # 后4位: 0001-9999

        # 当前ID计数器
        self.current_prefix = self.id_prefix_start
        self.current_suffix = self.id_suffix_start

    def generate_id(self) -> str:
        """生成固定规则的ID - 前2位后5位"""
        id_str = f"{self.current_prefix:02d}{self.current_suffix:05d}"

        # 更新计数器
        self.current_suffix += 1
        if self.current_suffix > self.id_suffix_end:
            self.current_suffix = self.id_suffix_start
            self.current_prefix += 1
            if self.current_prefix > self.id_prefix_end:
                self.current_prefix = self.id_prefix_start

        return id_str

    def generate_random_hash(self, length: int = 32) -> str:
        """生成随机hash值"""
        random_string = ''.join(random.choices(string.ascii_letters + string.digits, k=length))
        return hashlib.md5(random_string.encode()).hexdigest()

    def generate_document(self) -> Dict[str, Any]:
        """生成随机文档内容"""
        return {
            "timestamp": datetime.now().isoformat(),
            "field1": self.generate_random_hash(),
            "field2": self.generate_random_hash(),
            "field3": self.generate_random_hash(),
            "field4": random.randint(1, 1000),
            "field5": random.choice(["A", "B", "C", "D"]),
            "field6": random.uniform(0.1, 100.0)
        }

    def create_bulk_payload(self, index_name: str) -> str:
        """创建bulk写入payload"""
        bulk_data = []

        for _ in range(self.batch_size):
            #doc_id = self.generate_id()
            doc = self.generate_document()

            # 添加index操作
            bulk_data.append(json.dumps({
                "index": {
                    "_index": index_name,
            #        "_id": doc_id
                }
            }))
            bulk_data.append(json.dumps(doc))

        return "\n".join(bulk_data) + "\n"

    def bulk_index(self, config: Dict[str, Any], payload: str) -> bool:
        """执行bulk写入"""
        url = f"{config['url']}/_bulk"
        headers = {
            "Content-Type": "application/x-ndjson"
        }

        # 设置认证信息
        auth = None
        if config.get('username') and config.get('password'):
            auth = (config['username'], config['password'])

        try:
            response = requests.post(
                url,
                data=payload,
                headers=headers,
                auth=auth,
                verify=config.get('verify_ssl', True),
                timeout=30
            )
            return response.status_code == 200
        except Exception as e:
            print(f"Bulk写入失败: {e}")
            return False

    def refresh_index(self, config: Dict[str, Any]) -> bool:
        """刷新索引"""
        url = f"{config['url']}/{config['index']}/_refresh"

        # 设置认证信息
        auth = None
        if config.get('username') and config.get('password'):
            auth = (config['username'], config['password'])

        try:
            response = requests.post(
                url,
                auth=auth,
                verify=config.get('verify_ssl', True),
                timeout=10
            )
            success = response.status_code == 200
            print(f"索引刷新{'成功' if success else '失败'}: {config['index']}")
            return success
        except Exception as e:
            print(f"索引刷新失败: {e}")
            return False

    def run_test(self, config: Dict[str, Any], round_num: int, total_iterations: int = 100000):
        """运行性能测试"""
        test_name = f"{config['name']}-第{round_num}轮"
        print(f"\n开始测试: {test_name}")
        print(f"ES地址: {config['url']}")
        print(f"索引名称: {config['index']}")
        print(f"认证: {'是' if config.get('username') else '否'}")
        print(f"每次bulk写入: {self.batch_size}条")
        print(f"总计划写入: {total_iterations * self.batch_size}条")
        print("-" * 50)

        start_time = time.time()
        success_count = 0
        error_count = 0

        for i in range(1, total_iterations + 1):
            payload = self.create_bulk_payload(config['index'])

            if self.bulk_index(config, payload):
                success_count += 1
            else:
                error_count += 1

            # 每N次输出日志
            if i % self.log_interval == 0:
                elapsed_time = time.time() - start_time
                rate = i / elapsed_time if elapsed_time > 0 else 0
                print(f"已完成 {i:,} 次bulk写入, 耗时: {elapsed_time:.2f}秒, 速率: {rate:.2f} bulk/秒")

        end_time = time.time()
        total_time = end_time - start_time
        total_docs = total_iterations * self.batch_size

        print(f"\n{test_name} 测试完成!")
        print(f"总耗时: {total_time:.2f}秒")
        print(f"成功bulk写入: {success_count:,}次")
        print(f"失败bulk写入: {error_count:,}次")
        print(f"总文档数: {total_docs:,}条")
        print(f"平均速率: {success_count/total_time:.2f} bulk/秒")
        print(f"文档写入速率: {total_docs/total_time:.2f} docs/秒")
        print("=" * 60)

        return {
            "test_name": test_name,
            "config_name": config['name'],
            "round": round_num,
            "es_url": config['url'],
            "index": config['index'],
            "total_time": total_time,
            "success_count": success_count,
            "error_count": error_count,
            "total_docs": total_docs,
            "bulk_rate": success_count/total_time,
            "doc_rate": total_docs/total_time
        }

    def run_comparison_test(self, total_iterations: int = 10000):
        """运行双地址对比测试"""
        print("ES Bulk写入性能测试开始")
        print(f"测试时间: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
        print("=" * 60)

        results = []
        rounds = 2  # 每个地址测试2轮

        # 循环测试所有配置
        for config in self.es_configs:
            print(f"\n开始测试配置: {config['name']}")
            print("*" * 40)

            for round_num in range(1, rounds + 1):
                # 运行测试
                result = self.run_test(config, round_num, total_iterations)
                results.append(result)

                # 每轮结束后刷新索引
                print(f"\n第{round_num}轮测试完成,执行索引刷新...")
                self.refresh_index(config)

                # 重置ID计数器
                if round_num == 1:
                    # 第1轮:使用初始ID范围(新增数据)
                    print("第1轮:新增数据模式")
                else:
                    # 第2轮:重复使用相同ID(更新数据模式)
                    print("第2轮:数据更新模式,复用第1轮ID")
                    self.current_prefix = self.id_prefix_start
                    self.current_suffix = self.id_suffix_start

                print(f"{config['name']} 第{round_num}轮测试结束\n")

        # 输出对比结果
        print("\n性能对比结果:")
        print("=" * 80)

        # 按配置分组显示结果
        config_results = {}
        for result in results:
            config_name = result['config_name']
            if config_name not in config_results:
                config_results[config_name] = []
            config_results[config_name].append(result)

        for config_name, rounds_data in config_results.items():
            print(f"\n{config_name}:")
            total_time = 0
            total_bulk_rate = 0
            total_doc_rate = 0

            for round_data in rounds_data:
                print(f"  第{round_data['round']}轮:")
                print(f"    耗时: {round_data['total_time']:.2f}秒")
                print(f"    Bulk速率: {round_data['bulk_rate']:.2f} bulk/秒")
                print(f"    文档速率: {round_data['doc_rate']:.2f} docs/秒")
                print(f"    成功率: {round_data['success_count']/(round_data['success_count']+round_data['error_count'])*100:.2f}%")

                total_time += round_data['total_time']
                total_bulk_rate += round_data['bulk_rate']
                total_doc_rate += round_data['doc_rate']

            avg_bulk_rate = total_bulk_rate / len(rounds_data)
            avg_doc_rate = total_doc_rate / len(rounds_data)

            print(f"  平均性能:")
            print(f"    总耗时: {total_time:.2f}秒")
            print(f"    平均Bulk速率: {avg_bulk_rate:.2f} bulk/秒")
            print(f"    平均文档速率: {avg_doc_rate:.2f} docs/秒")

        # 整体对比
        if len(config_results) >= 2:
            config_names = list(config_results.keys())
            config1_avg = sum([r['bulk_rate'] for r in config_results[config_names[0]]]) / len(config_results[config_names[0]])
            config2_avg = sum([r['bulk_rate'] for r in config_results[config_names[1]]]) / len(config_results[config_names[1]])

            if config1_avg > config2_avg:
                faster = config_names[0]
                rate_diff = config1_avg - config2_avg
            else:
                faster = config_names[1]
                rate_diff = config2_avg - config1_avg

            print(f"\n整体性能对比:")
            print(f"{faster} 平均性能更好,bulk速率高 {rate_diff:.2f} bulk/秒")
            print(f"性能提升: {(rate_diff/min(config1_avg, config2_avg)*100):.1f}%")

def main():
    """主函数"""
    tester = ESBulkTester()

    # 运行测试(每次bulk 1万条,300次bulk = 300万条文档)
    tester.run_comparison_test(total_iterations=300)

if __name__ == "__main__":
    main()

1. 日志场景:不带 id 写入

测试条件:

  1. bulk 写入数据不带文档 id
  2. 每批次 bulk 10000 条数据,总共写入 30w 数据

这里把

反馈结果:

性能对比结果:
================================================================================

ES直连:
  第1轮:
    耗时: 152.29秒
    Bulk速率: 1.97 bulk/秒
    文档速率: 19699.59 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 152.29秒
    平均Bulk速率: 1.97 bulk/秒
    平均文档速率: 19699.59 docs/秒

Gateway代理:
  第1轮:
    耗时: 115.63秒
    Bulk速率: 2.59 bulk/秒
    文档速率: 25944.35 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 115.63秒
    平均Bulk速率: 2.59 bulk/秒
    平均文档速率: 25944.35 docs/秒

整体性能对比:
Gateway代理 平均性能更好,bulk速率高 0.62 bulk/秒
性能提升: 31.7%

2. 业务场景:带文档 id 的写入

测试条件:

  1. bulk 写入数据带有文档 id,两次测试写入的文档 id 生成规则一致且重复。
  2. 每批次 bulk 10000 条数据,总共写入 30w 数据

这里把 py 脚本中 第 99 行 和 第 107 行的注释打开。

反馈结果:

性能对比结果:
================================================================================

ES直连:
  第1轮:
    耗时: 155.30秒
    Bulk速率: 1.93 bulk/秒
    文档速率: 19317.39 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 155.30秒
    平均Bulk速率: 1.93 bulk/秒
    平均文档速率: 19317.39 docs/秒

Gateway代理:
  第1轮:
    耗时: 116.73秒
    Bulk速率: 2.57 bulk/秒
    文档速率: 25700.06 docs/秒
    成功率: 100.00%
  平均性能:
    总耗时: 116.73秒
    平均Bulk速率: 2.57 bulk/秒
    平均文档速率: 25700.06 docs/秒

整体性能对比:
Gateway代理 平均性能更好,bulk速率高 0.64 bulk/秒
性能提升: 33.0%

小结

不管是日志场景还是业务价值更重要的大数据或者搜索数据同步场景, gateway 的写入加速都能平稳的节省 25%-30% 的写入耗时。

关于极限网关(INFINI Gateway)

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

官网文档:https://docs.infinilabs.com/gateway
开源地址:https://github.com/infinilabs/gateway

作者:金多安,极限科技(INFINI Labs)搜索运维专家,Elastic 认证专家,搜索客社区日报责任编辑。一直从事与搜索运维相关的工作,日常会去挖掘 ES / Lucene 方向的搜索技术原理,保持搜索相关技术发展的关注。
原文:https://infinilabs.cn/blog/2025/gateway-bulk-write-performance-optimization/

【搜索客社区日报】第2055期 (2025-06-16)

社区日报Muses 发表了文章 • 0 个评论 • 2314 次浏览 • 2025-06-17 17:41 • 来自相关话题

1、Easysearch 索引备份之 Clone API https://infinilabs.cn/blog/202 ... -api/ 2、私有知识库 Coco AI 实战(一):Coco Server Linux 平台部署 https://infinilabs.cn/blog/202 ... on-1/、 3、风口|继MoE、MCP与A2A之后,下一个模型协作风口是MoA https://mp.weixin.qq.com/s/_yv9gdBKv1yDK0rQNtbbiQ 4、干货:手把手搭建ElasticSearch日志监控告警 https://mp.weixin.qq.com/s/JH2AIAnxdFSPhsG7h-9y_g 5、搭建持久化的 INFINI Console 与 Easysearch 容器环境 https://infinilabs.cn/blog/202 ... cker/ 编辑:Muse 更多资讯:http://news.searchkit.cn

【搜索客社区日报】第2035期 (2025-05-12)

社区日报Muses 发表了文章 • 0 个评论 • 4338 次浏览 • 2025-05-12 11:29 • 来自相关话题

活动推荐🔥:【5月15日 北京】本次 Workshop 活动将围绕 “搜索服务统一治理” “流量管控” “服务编排” 三大核心板块展开,深入探讨如何通过 INFINI Labs 产品为企业提供高效、灵活的搜索基础设施管理方案。欢迎大家免费报名参加。 https://hdxu.cn/128g7 1、Elasticsearch中的三种分页策略深度解析:原理、使用及对比 https://blog.csdn.net/qq_26664 ... 98228 2、Easysearch 基础运维扫盲指南:从 HTTP 到 HTTPS、认证与安全访问全解析 https://mp.weixin.qq.com/s/HR7E7HAfS4ntpSkD_r5_Zw 3、MySQL数据实时接入Easysearch,零代码迁移全流程 https://mp.weixin.qq.com/s/bVGf8v6RAQljficJrjEISw 4、字节跳动开源了一款 Deep Research 项目 https://mp.weixin.qq.com/s/ejE6bfR_lFQutPy-u_pzmQ 5、最强中文TTS接入MCP-Server,效果再次封神! https://mp.weixin.qq.com/s/ivjDIwYXIqxyV3kOvJ2VhQ 编辑:Muse 更多资讯:http://news.searchkit.cn