与 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）进行联系

最近一次高并发写入压测中，我们遇到了一个非常诡异的 BKD merge 崩溃。从报错看，很像 Easysearch 2.1.2 在 merge 阶段把 segment 读成了错误状态。典型错误是这样的：

java.lang.ArrayIndexOutOfBoundsException: Index -3 out of bounds for length 8
java.lang.ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8

异常栈最终落在 Lucene BKD 相关路径上：

• BKDReader.readNodeData()
• BKDWriter.merge()
• Lucene90PointsWriter.merge()

如果只看栈，很容易把问题归到 Easysearch 的 BKD merge 逻辑。但排查到最后，结论恰恰相反。

问题不在 Easysearch 的代码，而在 JDK 运行时。 更精确地说，是某个特定 Oracle GraalVM 21 构建中的 JVMCI/Graal JIT 路径，把 Lucene BKD 的热点代码执行错了。

1、为什么这个问题难查

它有几个特别迷惑人的特征：

• 只在高并发写入压测下触发
• 服务重启后的前几轮最容易复现
• 同一进程里，删了索引重新压，后面复现率反而下降
• 不是固定字段，多个数字类型字段都中过招
• ZSTD 和 best_compression 两种 codec 下都能复现

实际命中过的字段包括 @timestamp、size、status、_seq_no。所以这不是某个字段、某种 codec 或某个 mapping 的偶发问题。

2、第一层排除：merge reader 不是第一现场

一开始我们确实怀疑 merge reader，毕竟异常直接出现在 merge 路径上。但日志顺序很快给出了相反的证据。在 merge 真正崩溃之前，source segment 已经先出现了这些异常信号：

1. point-sort-restore-multiple-zero-ords
2. source-write-point-doc-mismatch
3. pointCount > docCount
4. pack-index-negative-code
5. reader-invalid-start-pos
6. 最后才是 ArrayIndexOutOfBoundsException

这意味着两件事：merge reader 不是第一现场，source segment 在写出阶段就已经坏了。merge reader 只是读到了已经损坏的 BKD index，并在那个阶段暴露了异常。

3、第二层排除：Easysearch 自己的 BKD 写入逻辑也没有先出错

继续往前追溯，我们发现问题比 OneDimensionBKDWriter.add() 还要早。真正的异常出现在排序/回填链路上：

• PointValuesWriter
• MutablePointTreeReaderUtils.sort()
• StableMSBRadixSorter

关键证据来自两个探针：

• point-sort-restore-multiple-zero-ords
• unwrittenSlotCount == source-write-point-doc-mismatch delta

这说明在某次排序/回填过程中，有一部分槽位根本没有被写入，默认值 0 被 restore 回填到 ords[]，再通过 docIDs[0] 放大成大量 docID=0，最终导致 pointCount > docCount，source segment 进入错误状态。

到这一步，排查重点已经不是“Easysearch 的 BKD merge 逻辑存在缺陷”，而是 Lucene points 排序链路的执行结果和源码语义不一致。

4、真正的转折点：抓到了 reorder() 自身的 coverage 异常

真正把方向扭转过来的，不是又一次复现，而是一个更早的探针：

• point-sort-reorder-coverage-mismatch

这个探针验证的是：StableMSBRadixSorter.reorder() 是否真的按源码应有的次数完整执行。

我们抓到的典型样本之一如下：

• targetSegment=_x
• field=status
• k=7
• expectedLoopCount=9800
• actualIterationCount=8204
• firstCoverageMismatchBucket=201
• firstCoverageExpected=9788
• firstCoverageActual=8192

更关键的是，同一条日志里还带出了这个信息：

skippedSourceSamples=[201:[{ord=8192,bucket=201,docID=9090,byteAtK=200}, ...]]

这条信息非常重要，因为它说明：bucket 201 理论上应该处理 9788 条，实际只处理了前 8192 条，但从 ord=8192 往后的样本，读出来仍然还是 bucket=201。这直接推翻了“后半段数据被污染后改桶”的旧解释，指向了一个更直接的结论：reorder() 自己的 coverage 被截断了。

另一个样本中出现了同类边界：firstCoverageExpected=31822，firstCoverageActual=16384。

到这里，一个很不自然的特征浮现出来：8192、16384——这些明显的 2 的幂边界，更像是运行时或 JIT 执行异常，而不是普通业务逻辑 bug。

5、哪段代码最可疑

此时怀疑对象已经不是泛泛的“BKD 整体有问题”，而是 Lucene 中的这段热点循环：

for (int i = 0; i < HISTOGRAM_SIZE; ++i) {
  final int limit = endOffsets[i];
  for (int h1 = fixedStartOffsets[i]; h1 < limit; h1++) {
    final int b = getBucket(from + h1, k);
    final int h2 = startOffsets[b]++;
    save(from + h1, from + h2);
  }
}
restore(from, to);

代码位于 org.apache.lucene.util.StableMSBRadixSorter#reorder(...)。

按源码语义，这段代码应该完整扫描每个 bucket 的范围，并最终把全部结果 restore 回去。但我们抓到的事实是：expectedLoopCount != actualIterationCount，某些 bucket 只跑到 8192 / 16384 就停了，随后出现未写槽位，restore 把默认 0 回填，最终 source segment 进入错误状态。

如果这是 Java 源码本身的稳定逻辑 bug，它在解释执行时也应该稳定触发，而不应该强烈依赖某个 JDK/JIT 组合。后面的 JVM 对照实验基本排除了这个可能性。

6、最强证据：只换 JDK / JIT 路径，结果就变了

这次排查中最有说服力的，不是某一条日志，而是对照实验。

基线组：旧版 Oracle GraalVM 21，默认 JVMCI/Graal JIT

环境：

• Oracle GraalVM 21+35.1
• 21+35-jvmci-23.1-b15
• Linux aarch64 / ARM64
• UseJVMCICompiler = true

结果：很快复现，命中了 point-sort-reorder-coverage-mismatch、point-sort-reorder-underfilled、point-sort-restore-multiple-zero-ords，随后 merge 报 ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8。

对照组：关闭 JVMCI/Graal JIT 或纯解释执行

只改 JVM 参数，不改代码和压测口径：

• -XX:-UseJVMCICompiler
• -Xint

结果一致：都没有再出现上述探针和异常。

这三组对照的意义很直接：如果这是 Easysearch 或 Lucene 的纯 Java 逻辑 bug，解释执行也应该能稳定复现。但现实是基线组复现，关闭 JVMCI 和纯解释执行都不复现。问题显然高度依赖 JIT 路径。

版本对照：较新的 GraalVM 21 构建在当前测试中未复现

这里需要补充一条重要的边界条件。我们后来又测试了一个较新的 GraalVM 版本：

java version "21.0.9" 2025-10-21 LTS
Java(TM) SE Runtime Environment Oracle GraalVM 21.0.9+7.1 (build 21.0.9+7-LTS-jvmci-23.1-b79)

在当前压测中，这个版本没有再出现 merge 错误。

因此结论必须写得更精确：已知会复现的是较早的 21+35-jvmci-23.1-b15，已知在当前测试中未复现的是较新的 21.0.9+7-LTS-jvmci-23.1-b79。更准确的工程判断不是“GraalVM 21 整体都有问题”，而是某个特定 GraalVM 21 构建有问题，较新的构建很可能已经修复或规避了该问题。这里仍需保持严谨：只能说“在当前压测中未复现”，还不能直接说“已经被完整证明没有问题”。

平台边界：不能写成 ARM 专属

除了前面详细展开的 Linux aarch64 / ARM64 主要实验环境外，有用户反馈在以下环境中也出现过同类问题：

• 操作系统：openEuler
• 内核：4.19.90-2112.8.0.0131.oe1.x86_64
• 架构：x86_64

这是用户的测试环境，不是我们能够独立完整复现并逐项展开的。但这条信息已经足够说明：当前不能把问题简单写成“ARM 平台专属”。更准确的说法是：我们在 ARM64 上系统性复现并完成了主要对照实验，另外也有 openEuler x86_64 测试环境的同类现象反馈，因此平台边界目前还没有被完全钉死。

7、更强的同机对照：换成 Oracle HotSpot 21.0.10 后，全量写入跑完也没有问题

为了进一步排除“是不是所有 Java 21 都会这样”，我们在同一台服务器上把 /infini/easysearch/jdk 从 Oracle GraalVM 21 换成普通 Oracle HotSpot 21.0.10，恢复默认 JVM 参数，用同样的写入压测继续验证。

其中一轮的结果很有说服力：

• 索引：nginx_zstd3_40mt4
• codec：ZSTD
• threads=16
• bulk_size=1000
• target_docs=181463624

最终 after_count=181463624，delta_written=181463624，全量文档写入完成，服务端没有出现任何 BKD merge 错误。

这条结果至少说明：同一台机器、同一套 Easysearch、同样的数据规模和写入模型，只要把 JDK 从 Oracle GraalVM 21 换成 Oracle HotSpot 21.0.10，问题就不再出现。

到这一步，工程判断已经比较清晰了：不是 Easysearch 自身逻辑导致，也不是所有 Oracle JDK 21 都会出错，更像是特定 Oracle GraalVM 21 构建相关的 JVMCI/Graal JIT 路径问题。

8、最关键的外部对照：Elasticsearch 8.19.5 也复现了

如果说前面的结论还能被质疑为“Easysearch 某些实现差异触发的”，那么后面的外部对照基本排除了这个方向。

我们在同一台服务器上部署了 Elasticsearch 8.19.5（Lucene 9.12.2），JDK 也切到相同的 Oracle GraalVM 21，执行同类写入压测。结果 Elasticsearch 也复现了同样的 BKD merge 崩溃。

关键异常完全一致：

java.lang.ArrayIndexOutOfBoundsException: Index -4 out of bounds for length 8

栈也一样落在 BKDReader.readNodeData、BKDWriter$MergeReader.collectNextLeaf、BKDWriter$MergeReader.next。

这条证据的力度很强：不是 Easysearch 独有的问题，不是当前这套 Lucene 代码路径独有的问题，Elasticsearch 8.19.5 + Lucene 9.12.2 在同类 GraalVM 21 环境下也会出现同类异常。到这一步，再把问题归因于 Easysearch 本身的代码逻辑，已经缺乏依据了。

9、这次排查最终说明了什么

把整条证据链串起来，当前阶段的结论已经比较清楚。

已验证的事实：

• 问题不是 merge reader 先制造坏数据，source segment 在更早阶段就已经进入错误状态
• 不是单字段问题，也不是 ZSTD 或 best_compression 专属
• 已抓到 StableMSBRadixSorter.reorder() 自身的 coverage 异常
• 关闭 UseJVMCICompiler 后问题不复现，-Xint 下也不复现
• 同机切到 Oracle HotSpot 21.0.10 后，Easysearch 全量写入跑完未见 BKD merge 异常
• Elasticsearch 8.19.5 + Lucene 9.12.2 在同类 GraalVM 21 环境下也复现
• 较新的 21.0.9+7-LTS-jvmci-23.1-b79 在当前压测中未复现
• 某用户的 openEuler x86_64 测试环境中也出现过同类错误，因此不能写成 ARM 专属

工程结论：

从工程证据来看，Easysearch 本身的代码逻辑没有问题。

当前最符合事实的结论是：问题高度相关于特定 Oracle GraalVM 21 构建，更具体地，是该构建相关的 JVMCI/Graal JIT 路径。它把 Lucene BKD 相关热点代码执行到了错误状态。已知较早构建 21+35-jvmci-23.1-b15 可复现，已知较新的 21.0.9+7-LTS-jvmci-23.1-b79 在当前测试中未复现。平台边界目前尚未完全钉死，不能再简单写成仅限 ARM64。

换句话说，这不是“Easysearch 的 BKD merge 实现有 bug”，而是特定 JDK/JIT 运行时把本来正确的 Lucene BKD 代码执行错了。

10、建议版本与规避方案

如果你在生产或测试环境中运行 Easysearch 或 Elasticsearch，并且使用的是某些 Oracle GraalVM 21 构建，且启用了默认的 JVMCI/Graal JIT，那么在高并发写入、频繁 merge、BKD 热点路径被充分打热的场景下，需要特别警惕这类问题。

现阶段比较明确的建议是：

1. 避免继续使用已经验证可复现的旧版构建：Oracle GraalVM 21+35.1 或 21+35-jvmci-23.1-b15
2. 优先升级到当前测试中未复现的版本：Oracle GraalVM 21.0.9+7.1（即 21.0.9+7-LTS-jvmci-23.1-b79）
3. 如果短期内不方便升级 GraalVM，直接切换到普通 Oracle HotSpot 21.0.10

直接落到版本号上会更清晰：

• 已确认应避开：21+35-jvmci-23.1-b15
• 当前更推荐：21.0.9+7-LTS-jvmci-23.1-b79

原因很简单：前者我们已经复现了，后者在当前压测中没有复现。当然，这里的“推荐”是基于当前测试结果，不代表上游已经正式确认该问题已被修复。

11、最后

这次排查最大的价值，不是“又复现了一次 BKD merge 崩溃”，而是把一个看起来像 Easysearch 代码 bug 的现象，收敛成了一个有明确边界的运行时问题。

它至少说明两件事：

• 栈顶报错的位置不一定是真正的第一现场
• 真正有说服力的不是猜测，而是对照实验

这次结论之所以成立，不是因为主观判断，而是因为我们已经拿到了足够强的工程证据：同机 HotSpot 不复现，关闭 JVMCI 不复现，解释执行不复现，Elasticsearch 也复现，较新的 GraalVM 21.0.9+7.1 在当前测试中未复现，且某用户的 openEuler x86_64 测试环境也出现过同类错误。

所以，这一次，问题确实不在 Easysearch，而在特定版本的 JDK/JIT 运行时。

关于 Easysearch

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

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

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

相关文章：

• Easysearch 国产替代 Elasticsearch：8 大核心问题解读
• Elasticsearch VS Easysearch 性能测试
• 从 Elastic 迁移到 Easysearch 指引
• Elasticsearch 磁盘空间异常：一次成功的故障排除案例分享
• Easysearch、Elasticsearch、Amazon OpenSearch 快照兼容对比

公司简介

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

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

官网：https://infinilabs.cn

招聘信息

售前解决方案工程师（北京）

岗位职责：

1、深入分析客户业务场景与搜索需求，协助销售团队理解客户痛点，提供匹配的企业级搜索基础设施与整体架构建议 ;
2、负责公司产品与解决方案的售前技术支持，包括技术交流、方案编写、成本估算、产品演示及 PPT 制作与讲解 ;
3、协助销售进行客户需求调研、业务场景分析，提供基于分布式搜索引擎的技术方案与专业咨询 ;
4、参与客户培训与技术指导，提供现场售前技术支持，提升客户技术认知与产品信任度 ;
5、主导现场 POC，协调资源完成功能与非功能性测试，撰写测试报告并推动项目进展 ;
6、收集并反馈客户产品使用意见与需求，协助产品团队持续优化产品功能与用户体验 。

岗位要求：

1、全日制本科及以上学历，计算机、信息技术或相关专业优先 ;
2、3 年以上数据库、大数据或相关技术领域工作经验 ;
3、了解 Elasticsearch / Easysearch / OpenSearch 等搜索引擎，或熟悉至少一种主流数据库（如 MySQL、Oracle、MongoDB 等） ;
4、具备大型企业信息化项目经验，了解行业技术趋势、商业模式与主流 IT 服务商 ;
5、具备良好的沟通表达能力、应变能力，能独立与客户进行技术交流并精准把握需求 ;
6、具备客户需求深度挖掘与引导能力，能结合产品优势编写项目方案与技术建议书 ;
7、学习能力强，善于知识整合，具备良好的团队协作精神 。

加分项：

1、985 / 211 院校毕业优先 ;
2、拥有技术博客或在 AI、搜索、大数据、数据库等领域有内容输出经验 ;
3、持有 Elastic Certified Engineer（ECE）认证 ;
4、具备大规模搜索引擎集群设计、扩展与性能调优经验 ;
5、熟悉大数据相关技术栈，如 Kafka、Flink 等 ;
6、熟悉其他搜索引擎技术（如 Solr、Lucene）者优先 。

区域销售经理（北京）

岗位职责：

1、深耕 TO B 业务：专注于金融行业（特别是银行及证券）或央国企（特别是能源、大制造行业），建立并维护与该行业关键客户的良好关系，深入挖掘客户对企业搜索解决方案的需求 ;
2、攻坚克难，促成交易：面对复杂多变的销售环境，展现出强大的攻坚克难能力，有效应对客户异议，推动销售项目从初期接触到最终成交的全过程 ;
3、客户关系管理：建立并管理高价值的客户关系网络，通过定期的沟通、拜访及活动策划，增强客户粘性，促进长期合作 ;
4、解决方案设计与呈现：基于客户具体需求，结合公司产品与技术优势，设计并呈现定制化的解决方案，有效展现产品价值及实施效果 ;
5、技术学习与传递：快速学习并掌握最新的企业搜索、AI 搜索技术趋势、产品特性及竞争对手动态，能够准确、专业地向客户传达技术价值，提升客户信任度 ;
6、业绩达成与团队协作：确保达成公司设定的个人销售目标，同时与售前技术支支持、售后服务等部门紧密合作，确保项目顺利交付及客户满意度 。

岗位要求：

1、全日制本科及以上学历 ;
2、3 年以上 IT 解决方案或软件销售经验，具有 1 年以上金融或央国企相关行业销售背景 ;
3、面对挑战不退缩，能够积极寻找解决方案，推动项目进展直至成功 ;
4、了解所在行业业务流程及 IT 架构，能够快速学习并掌握新技术 ;
5、工作态度认真负责，勤奋敬业，能够承受一定的工作压力，确保任务按时按质完成 ;
6、良好的团队合作精神，能够与跨部门团队有效协作，共同达成目标 ;
7、销售提成额外签署补充协议 。

加分项：

1、计算机科学、信息技术或相关专业 ;
2、985 / 211 院校毕业优先 ;
3、了解开源行业及生态，理解相关技术及商业逻辑 ;
4、有数据库或大数据相关产品及解决方案销售经验 。

市场专员（北京）

岗位职责：

1、负责公司企业搜索、AI 搜索解决方案的技术生态运营工作，包括国内及全球市场 ;
2、负责市场活动策划，包括但不限于线上活动、线下活动、品牌合作等，提升品牌形象 ;
3、以技术角度，整合上下游合作伙伴资源，建立产品在市场上的知名度 ;
4、规划产品技术生态运营工作，包括自运营技术社区、展会合作、新媒体媒体投放等 ;
5、积极通过数字化体现运营价值，驱动产品知名度，配合一线最终实现销售业绩提升 ;
6、负责市场调研及相关情报搜集整理，同竞品的分析对比和信息搜集，根据市场反馈和数据，分析结果 ;
7、熟练使用 AI 工具做内容创作、 AI 作图、素材制作等，支持内容传播与活动落地 。

岗位要求：

1、市场运营或计算机科学、信息技术相关专业全日制本科或以上学历 ;
2、1-3 年以上科技产品公司市场运营经验 ;
3、具有良好的数据敏感度，善于从数据中发现问题点、机会点，具备良好的分析问题、解决问题的能力 ;
4、主导或参与过软件企业重大发布会、大型行业展会，或专题系列的技术巡展 ;
5、结果导向，执行力强，擅长跨部门协同，以获客转化为核心目标 。

加分项：

1、985 / 211 院校毕业优先 ;
2、有海外留学经验，英文阅读沟通能力强 ;
3、有数据分析基础，熟练使用 Python ;
4、有广告、AI 营销、IT 媒体或产业联盟工作经验优先 ;
5、熟悉使用 Office 办公软件，了解 PS、PR、剪映等设计软件者优先 ;
6、有在软件开发、数据库或大数据领域 维护运营博客或自媒体经验优先 。

客户成功经理（长沙）

岗位职责：

1、负责客户全生命周期的成功管理，包括 Onboarding、产品培训、日常维护、使用跟踪及定期回访，确保客户持续获得价值 ;
2、主动服务，发现那些客户需要帮助，提前介入，提供主动关怀，及时响应客户问题与需求，推动问题闭环解决 ;
3、筛选或发现优质客户，促进增购、续约购，给销售团队提供最佳信息 ;
4、技术学习与传递：快速学习并掌握最新的企业搜索、AI 搜索技术趋势、产品特性及竞争对手动态，能够准确、专业地向客户传达技术价值，提升客户信任度 ;
5、沟通与项目管理：协调内部资源（销售，售后服务，产品、开发等部门），提高客户满意度 ;
6、收集客户反馈与需求，输出产品优化建议，与产品团队紧密协作推动产品迭代 。

岗位要求：

1、全日制本科及以上学历，限 2026 年应届生 ;
2、快速学习能力，熟悉和理解行业客户的业务逻辑及IT架构（如金融、能源、制造业等） ;
3、具备一定的数据分析能力，通过客户使用数据预判需求或风险 ;
4、工作态度认真负责，勤奋敬业 ;
5、良好的团队合作精神，能够与跨部门团队有效协作，共同达成目标 。

加分项：

1、计算机科学、信息技术或相关专业 ;
2、985 / 211 院校毕业优先 ;
3、有过 数据库类或大数据类技术性工作经验 ;
4、熟悉 AI、搜索、大数据、数据库等相关行业知识 。

UI/交互设计实习生（长沙）

岗位职责：

1、负责产品界面与交互设计，优化用户体验 ;
2、支持运营活动视觉输出，熟练使用AI工具产出创意素材 ;
3、参与官网、海报等设计工作 ;
4、结合数据反馈优化设计，提升转化效果 ;
5、与产品、开发团队协作推进方案落地 。

岗位要求：

1、985 / 211 全日制本科及以上学历在读，视觉传达、人机交互、数字媒体艺术等相关专业优先 ;
2、关注设计趋势，学习能力强，能快速掌握新工具与方法 ;
3、具备较强的审美能力、逻辑思维能力、沟通表达能力以及对细节的极致追求 ;
4、应聘者请准备好自己的作品，请将作品集与简历一同发送 。

加分项：

1、有设计社区（Behance、Dribbble、站酷等）作品或运营经验 ;
2、有动效设计或动画制作经验 。

软件测试实习生（长沙）

岗位职责：

1、参与项目和日常产品需求分析，把控需求和系统分析质量和风险 ;
2、负责完成产品功能特性的测试设计以及测试用例的编写 ;
3、组织测试实施工作，跟进测试的进展和完成情况，记录测试结果并准备测试报告 ;
4、通过抓包或日志分析，能够对常见bug进行基本定位 ;
5、不断改进测试流程和方法，以提高质量和效率 ;
6、关注产品质量和客户需求，确保稳定、可靠和用户友好的软件交付 。

岗位要求：

1、985 / 211 全日制本科及以上学历在读，计算机以及相关专业 ;
2、熟悉软件测试基础理论、测试流程及常用测试方法 ;
3、良好的英文读写能力，能够有效的阅读和学习英文技术资料 ;
4、很强的自我驱动学习能力和技术钻研能力，具备优秀的沟通技巧，很好的责任心与高执行力 ;
5、能够承受压力，在快节奏的环境中高效工作 。

加分项：

1、熟悉 Go 或 Java 或 Python 编程语言，熟练 Linux，Git 常用命令 ;
2、熟悉 AI、搜索、大数据、数据库等相关行业知识 ;
3、熟悉 Easysearch / Elasticsearch / OpenSearch 等搜索引擎 。

内容运营实习生（长沙）

岗位职责：

1、负责社区内容的策划、文案、编辑，围绕团队成果产出技术解读文章，通过公众号、博客、社区等形式进行内容运营，提升公司的影响力 ;
2、支持市场营销中的内容输出，善于利用 AI 工具提供有吸引力的设计创意与素材 ;
3、参与其他新媒体相关工作，如视频号、小红书、抖音账号等内容创作和运营 ;
4、数据化运营，包括分析官网访问、下载等数据指标，根据数据反馈及时调整策略，提升运营效果 ;
5、定期与社区用户、媒体沟通，保持通畅的聆听反馈机制 ;
6、参与策划、组织及执行团队主办或承办的各类社区活动 。

岗位要求：

1、985 / 211 全日制本科及以上学历在读，新闻、营销、传媒、计算机等相关专业优先 ;
2、需要公众号运营、短视频运营相关工作经验；熟练掌握排版、拍摄、剪辑等各项能力 ;
3、具备较强的创意和策划能力、应变能力、语言和文字表达能力以及敏锐的市场触角 ;
4、对搜索技术、互联网产品及工具类信息怀有浓厚兴趣，具备快速学习并熟练掌握相关知识的能力，能够紧跟行业动态 。

加分项：

1、具有用户增长、数据分析、数据挖掘、信息检索经验者优先 ;
2、具有开源社区、开发者社区、开源媒体运营经验者优先 。

更多职位请访问 Boss 直聘

简历投递

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

我们期待有才华、有激情的你加入我们，一起探索数据搜索的未来，共同创造无限可能！

在搜索引擎领域，压缩算法的选择一直是一个经典的权衡难题：

• 选择高压缩率（如 best_compression / DEFLATE），磁盘省了，但查询解压慢；
• 选择高速编码（如默认 LZ4），查询快了，但磁盘占用大。

Easysearch 引入了基于 JDK 21 FFM（Foreign Function & Memory API） 直连本地 ZSTD 动态库的加速方案，试图打破这一困局。为了验证效果，我们在完全对等的环境下，对 Easysearch（ZSTD）和 Elasticsearch 7.10.2（best_compression）进行了一次严格的查询吞吐对比测试。

结果令人振奋——即使在系统明显背景负载下，Easysearch 也没有因为高压缩而变慢，反而在查询吞吐上实现了近 5 倍提升。

测试环境

为确保对比公平，两套集群的硬件资源、JVM 配置、数据规模、索引结构完全对齐：

压缩机制对比：best_compression 映射到 Lucene BEST_COMPRESSION；在 stored fields 路径上，压缩实现为 DeflateWithPresetDictCompressionMode，内部使用 java.util.zip.Deflater/Inflater（即 DEFLATE）。 Easysearch ZSTD 当前走 JDK 21 FFM 绑定本地 zstd 库（java.lang.foreign）；index.compression.zstd.jni=true 为当前这套实现的启用方式。

查询模型：JMeter 随机 match 查询，随机命中 service_name、method、error_code、url 四个字段，每次返回 10 条文档。

压测起始负载（_cat/nodes 快照）：

说明：压测并非在空闲机上进行，而是在已有明显背景负载的生产式环境下完成。

核心结果

1. 查询吞吐量（QPS）：在高背景负载下，Easysearch 仍领先 372%

稳态阶段（3 轮平均），Easysearch 的查询吞吐是 Elasticsearch 的 4.7 倍：

注：压测期间服务器存在明显背景负载（其他进程占用较高），该 CPU 指标是系统总占用，不等价于“仅搜索进程”的纯业务 CPU 对比。

在系统总 CPU 均接近 90% 的背景下，Easysearch 仍达到接近 5 倍吞吐。

2. 响应时间：从近 1 秒降到 164 毫秒

用户体感上，这意味着：同样一个搜索请求，Elasticsearch 还在等解压，Easysearch 已经把结果送到了客户端。

3. 各轮次详细数据

4. CPU 使用效率：每 1% CPU 产出的 QPS 差距惊人

单看 CPU 占用率，两者似乎差不多（89.59% vs 92.43%）。但如果换一个视角——每消耗 1% CPU 能产出多少 QPS，差距就一目了然了：

这意味着什么？

• ES 使用 DEFLATE（best_compression）时，解压路径更可能成为 CPU 热点；结合 ES 的高 CPU（92.43%）与较低 QPS，说明单位 CPU 产出偏低；
• Easysearch 使用 ZSTD（JDK21 FFM/native）时，解压开销更小；在相近 CPU 水位（89.59%）下获得更高 QPS，单位 CPU 产出明显更高。

换句话说，当前这组实测更支持“ZSTD 在该查询模型下单位 CPU 产出更高”。

5. 存储空间：ZSTD 并未膨胀

两者存储空间接近。若按 _cat/indices 的 1 位小数展示是 1.8GB vs 1.9GB；若按 _stats/store 字节值计算，差异约 2.5%。因此可以认为 ZSTD 在 level=3 下与 DEFLATE best_compression 压缩率接近。

为什么 ZSTD 能做到"又小又快"？

传统认知中，压缩率和解压速度是一对矛盾。但 ZSTD 算法天然具备非对称压缩的特性：

在搜索引擎场景中，查询会触发存储字段（_source）读取与解压路径，命中文件系统页缓存时，可能不发生实际磁盘 I/O，但仍需进行 _source 解压。 当查询涉及较多 _source 读取时：

• DEFLATE 的解压开销成为 CPU 瓶颈，拖慢了整体吞吐；
• ZSTD（JDK21 FFM/native） 的解压速度在该场景下明显更优，单次请求的解压 CPU 成本更低，从而释放出更多 CPU 资源用于并发查询处理。

这就是为什么 Easysearch 在 CPU 占用更低（89.59% vs 92.43%）的情况下，反而能处理近 5 倍的查询量。

一张图总结

结论

Easysearch 的 ZSTD 压缩方案证明了一个事实：即使在高背景负载下，高压缩率和高查询性能依然可以兼得。

在 1000 万条 nginx 日志、且系统存在明显背景负载的实测中：

• 查询吞吐提升 372%，从 533 QPS 跃升至 2518 QPS
• 平均响应时间下降 79%，从 779ms 降至 164ms
• CPU 使用效率提升 388%，每 1% CPU 产出 28.10 QPS vs 5.76 QPS
• CPU 占用绝对值下降 2.84 个百分点（相对下降约 3.07%）
• 磁盘占用与 DEFLATE best_compression 接近（按字节口径约 +2.5%）

对于日志分析、可观测性、安全审计等需要兼顾存储成本和查询性能的场景，Easysearch ZSTD 是一个不需要妥协的选择。

ZSTD 使用方法

1) 新建索引时启用 ZSTD

curl -k -u 'admin:<password>' -X PUT 'https://127.0.0.1:9200/<index-name>' \
  -H 'Content-Type: application/json' -d '{
    "settings": {
      "index.codec": "ZSTD",
      "index.compression.zstd.jni": true
    }
  }'

可选参数：

• index.compression.zstd.level（默认 3）

说明：

• index.compression.zstd.dict 固定为 true，无需单独配置
• index.compression.zstd.dict 不作为独立开关来调整

2) 老索引切换到 ZSTD（推荐 reindex）

index.codec 是静态设置（打开状态不可动态改；可在关闭索引后调整）。
index.compression.zstd.jni 是 final 设置（关闭索引后也不可修改）。
如果老索引要启用 index.compression.zstd.jni=true，建议新建目标索引后 reindex 迁移： 如果对已有索引执行 PUT /<index-name>/_settings 直接修改，会报错：final <index-name> setting [index.compression.zstd.jni], not updateable。

# 先创建目标索引（启用 ZSTD）
curl -k -u 'admin:<password>' -X PUT 'https://127.0.0.1:9200/<target-index>' \
  -H 'Content-Type: application/json' -d '{
    "settings": {
      "index.codec": "ZSTD",
      "index.compression.zstd.jni": true
    }
  }'

# 再迁移数据
curl -k -u 'admin:<password>' -X POST 'https://127.0.0.1:9200/_reindex' \
  -H 'Content-Type: application/json' -d '{
    "source": { "index": "<source-index>" },
    "dest":   { "index": "<target-index>" }
  }'

3) 校验是否生效

curl -k -u 'admin:<password>' \
  'https://127.0.0.1:9200/<index-name>/_settings?include_defaults=true&pretty'

重点确认：

• index.codec = ZSTD
• index.compression.zstd.jni = true

关于 Easysearch

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

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

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

相关文章：

• Easysearch 2.0.0 性能测试
• Easysearch 压缩模式深度比较：ZSTD + source_reuse 的优势分析
• Easysearch 压缩功能的显著提升：从 8.7GB 到 1.4GB

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

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

在之前的几期中，我们认识了搜索技术的基石 Lucene、企业级搜索先锋 Solr、搜索界的“流量明星” Elasticsearch 以及它的分叉兄弟 OpenSearch 和 ES 国产替代方案 Easysearch。它们大多基于 Lucene 构建，形成了庞大且功能丰富的生态。

今天，我们将介绍一位“非主流”选手：一款基于 Rust 编写、主打“快”和“简单”的现代搜索引擎——Meilisearch。它以全新的姿态，为开发者带来了不同的搜索体验。

Meilisearch 概述

Meilisearch 是一款开源的、用 Rust 编写的即时搜索引擎。它提供了一个快速、轻量且可定制的搜索 API，旨在为用户提供毫秒级的搜索体验。

它的核心优势在于为应用内搜索和电商搜索等对延迟敏感的场景提供了出色的用户体验。

• 首次发布：2020 年
• 最新版本：1.24.0（截止 2025 年 10 月）
• 核心语言：Rust
• 开源协议：MIT License
• 官方网址：https://www.meilisearch.com/
• GitHub 仓库：https://github.com/meilisearch/meilisearch

诞生故事

Meilisearch 的故事始于 2018 年，当时法国工程师 Quentin de Quelen 在开发一个电商项目时，发现现有的搜索引擎要么太重量级，要么配置太复杂。他想要一个"开箱即用"的搜索解决方案，能够快速集成到应用中，并提供优秀的搜索体验。

于是，他决定用 Rust 语言从头编写一个搜索引擎。选择 Rust 是因为其出色的性能、内存安全性和并发能力，非常适合构建高性能的搜索核心。

项目最初只是一个内部工具，但随着功能的完善和社区的反馈，Meilisearch 在 2019 年正式开源，并迅速获得了开发者的青睐。2020 年，团队获得了 150 万美元的种子轮融资，正式成立了 Meilisearch 公司。

核心特性

Meilisearch 在设计上做了大量的取舍，专注于核心的搜索功能，但做到了极致。

• 极速响应：核心目标是实现 50 毫秒以下的响应时间，即使在大型数据集中也能提供“所见即所得”的搜索体验。
• 零配置：开箱即用，部署和索引数据都非常简单，不需要预定义 Schema 或复杂的配置文件。
• 相关的默认值：内置一个强大的 相关性排名（Relevance Ranking） 算法，结合 Typos（拼写错误）、Word Proximity（词语距离）和 Attributes（字段权重）等因素，无需额外调优即可获得高质量的搜索结果。
• 语言无关性：支持多种语言的分词与搜索，能很好地处理中文、日文等非拉丁语系文本。
• 无分布式架构：为了追求极致的速度和简单性，Meilisearch 被设计为单机搜索引擎，不支持开箱即用的分布式集群，这简化了运维，但也限制了其 PB 级数据的处理能力。

对比优势：Meilisearch vs Lucene/ES 体系

Meilisearch 与基于 Lucene 的 Elasticsearch 体系，在设计哲学上有着本质区别:

总结：

• 如果你的应用需要超低延迟、简单部署、数据量在 GB 级别，并且搜索是应用的核心功能，Meilisearch 是一个极佳的选择。
• 如果你的需求涉及日志分析、大规模数据存储、集群高可用和复杂的聚合分析，那么 Elasticsearch 仍然是更成熟和全面的解决方案。

快速上手：5 分钟体验 Meilisearch

部署 Meilisearch 非常简单，你甚至不需要 Docker，只需一个命令即可运行。

1. 运行 Meilisearch

# 安装 Meilisearch
curl -L https://install.meilisearch.com | sh
# 启动 Meilisearch
meilisearch --master-key 'aStrongMasterKey'

# 或使用 Docker
docker run -it --rm -p 7700:7700 getmeili/meilisearch:latest --master-key 'aStrongMasterKey'

2. 添加索引（创建 Index）

Meilisearch 不需要预先定义索引结构（Schema-less）。

curl -X POST 'http://localhost:7700/indexes' \
  -H 'Authorization: Bearer aStrongMasterKey' \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "uid": "movies",
    "primaryKey": "id"
}'

3. 索引文档（添加 Documents）

curl -X POST 'http://localhost:7700/indexes/movies/documents' \
  -H 'Authorization: Bearer aStrongMasterKey' \
  -H 'Content-Type: application/json' \
  --data-binary '[
    {"id": 1, "title": "泰坦尼克号", "genres": ["剧情", "爱情"]},
    {"id": 2, "title": "黑客帝国", "genres": ["科幻", "动作"]}
]'

4. 执行搜索

# 搜索关键词 "泰坦"
curl -X GET 'http://localhost:7700/indexes/movies/search?q=泰坦'

返回结果：

{
  "hits": [
    {
      "id": 1,
      "title": "泰坦尼克号",
      "genres": ["剧情", "爱情"]
    }
  ],
  "offset": 0,
  "limit": 20,
  "estimatedTotalHits": 1,
  "processingTimeMs": 1,
  "query": "泰坦"
}

注意 processingTimeMs: 1，这是 Meilisearch 速度的最好证明！

5. 场景演示

结语

Meilisearch 的出现，代表了新一代搜索引擎对于开发者体验和即时性的追求。它在应用内搜索领域展现了强大的竞争力，证明了不必依赖 Lucene 的庞大体系，也能打造出极致性能的搜索产品。

虽然它还无法完全取代 Elasticsearch 在日志分析、可观测性等大型分布式场景的地位，但在许多新兴应用和对搜索速度有极高要求的场景中，它无疑是一个值得尝试的开源新星。

🚀 下期预告

下一篇我们将把目光转向搜索领域的云端先锋 —— Algolia。作为搜索即服务（Search-as-a-Service）的开创者，Algolia 如何以其卓越的 API 设计、惊人的搜索速度和精准的相关性排序，重新定义云端搜索体验？

💬 三连互动

1. 你会把 ES/Solr 换成 Meilisearch 吗？
2. 在你的应用中，搜索延迟达到多少毫秒你会觉得无法接受？
3. 在什么场景下你会考虑使用 Meilisearch 而不是 Elasticsearch？

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

✨ 推荐阅读

• 搜索百科（5）：Easysearch — 自主可控的国产分布式搜索引擎
• 搜索百科（4）：OpenSearch — 开源搜索的新选择
• 搜索百科（3）：Elasticsearch — 搜索界的"流量明星"
• 搜索百科（2）：Apache Solr — 企业级搜索的开源先锋
• 搜索百科（1）：Lucene — 打开现代搜索世界的第一扇门

🔗 参考资源

• Meilisearch 官方文档
• Meilisearch vs Elasticsearch

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

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

在上一篇我们介绍了 OpenSearch —— 那个因协议争议而诞生的开源搜索分支。今天，我们把目光转向国内，聊聊极限科技研发的一款轻量级搜索引擎：Easysearch。

引言

在搜索技术的世界里，从 Lucene 的出现到 Solr、Elasticsearch 的崛起，搜索引擎技术已经发展了二十余年。然而，随着开源协议的变更与国际形势的变化，国产自主搜索引擎的需求愈发迫切。在这样的背景下，Easysearch 作为一款自主可控、轻量高效、兼容 Elasticsearch 的分布式搜索引擎应运而生，为国内企业带来了全新的选择。

Easysearch 概述

Easysearch 是一款分布式搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析、AI 集成等。Easysearch 衍生自开源协议 Apache 2.0 的 Elasticsearch 7.10 版本，并不断往前迭代更新，紧跟 Lucene 最新版本的更新。Easysearch 可以替代 Elasticsearch，同时添加和完善多项企业级功能。

• 首次发布：2023 年 4 月
• 最新版本：1.15.4（截止 2025 年 10 月）
• 主导企业：极限科技 (INFINI Labs)
• 官方网址：https://easysearch.cn

诞生背景：为什么要有 Easysearch？

Easysearch 由极限科技（INFINI Labs）团队推出。项目的起点源于团队长期在搜索引擎和大数据领域的深厚实践积累，团队深刻认识到国内企业在使用 Elasticsearch 时普遍面临以下痛点：

1. 开源协议变化带来的商业风险 —— Elastic 于 2021 年将许可更改为 SSPL，导致社区分裂，增加了企业在合规和商用上的不确定性；
2. 高并发与高可靠性场景下对稳定可控方案的需求 —— 企业级应用亟需一个性能可靠、可深度优化的搜索基础设施；
3. 技术栈自主可控的迫切需求 —— 随着国产化进程加快，国内生态中缺乏轻量化、易部署、且完全可控的搜索引擎产品；
4. 本地化服务与快速响应能力的缺口 —— 国内企业更需要本地团队提供高效的技术支持与服务，对本土化、个性化功能需求能得到及时响应与反馈。

基于这些考虑，Easysearch 在设计之初就明确了目标：构建一款兼容 Elasticsearch API、简洁易用、性能出众且完全自主可控的国产搜索引擎。

核心特性

• 轻量级：安装包大小不到 60 MB，安装部署简洁，资源占用低，开箱即用；
• 跨平台：支持主流操作系统和 CPU 架构，支持国产信创运行环境；
• 高性能：针对不同场景进行的极致优化，可用更少硬件成本获得更高服务性能，降本增效。
• 稳定可靠：修复大量内核问题，解决内存泄露，集群卡顿、查询缓慢等问题，久经严苛业务环境考验。
• 安全增强：默认就提供完整的企业级安全功能，支持 LDAP/AD 集成，支持索引、文档、字段粒度细权管控。
• 兼容性强：兼容 Elasticsearch 7.x 的 REST API 和数据格式，迁移成本低；
• 可视化运维：无需 Kibana 即可通过内置 Web UI 插件界面管理索引、节点与监控指标等。

对比优势

快速开始：5 分钟体验 Easysearch

1. 使用 Docker 启动

# 直接运行镜像使用随机密码（数据及配置未持久化）
docker run --name easysearch \
--ulimit memlock=-1:-1 \
-p 9200:9200 \
infinilabs/easysearch:1.15.4

2. 验证集群状态

curl -ku "username:password" -X GET "https://localhost:9200/"

返回结果示例：

{
  "name": "easysearch-node",
  "cluster_name": "easysearch-6yhwn91v80gf",
  "cluster_uuid": "Gfu_fuF1QViJfeUWVbiFCA",
  "version": {
    "distribution": "easysearch",
    "number": "1.15.4",
    "distributor": "INFINI Labs",
    "build_hash": "9110128946b0af3de639966cfa74b5498346949d",
    "build_date": "2025-10-14T03:30:41.948590Z",
    "build_snapshot": false,
    "lucene_version": "8.11.4",
    "minimum_wire_lucene_version": "7.7.0",
    "minimum_lucene_index_compatibility_version": "7.7.0"
  },
  "tagline": "You Know, For Easy Search!"
}

3. 索引与搜索示例

# 写入文档
curl -ku "username:password" -X POST "https://localhost:9200/my_index/_doc" -H 'Content-Type: application/json' -d'
{
  "title": "Easysearch 入门",
  "content": "这是一个轻量级搜索引擎的示例文档。",
  "tags": ["搜索", "国产", "轻量级"]
}'

# 搜索文档
curl -ku "username:password" -X GET "https://localhost:9200/my_index/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "content": "搜索引擎"
    }
  }
}'

4. 使用 Easysearch UI

Easysearch 提供了轻量级界面化管理功能，不再依赖第三方组件即可对集群进行管理，真正做到开箱即用。如果你安装了 Easysearch UI 插件或者下载捆绑包，可通过 https://localhost:9200/\_ui/ 访问，进行节点、索引、分片、查询调试和监控查看等管理。

图 1：系统登录

图 2：集群概览

图 3：节点列表

图 4：节点概览

图 5：索引列表

图 6：索引概览

图 7：分片管理

图 8：开发工具

以上仅列出了一些基本功能，其他如安全管理、主从复制、备份管理、生命周期管理等更多高级功能由于篇幅限制不一一展示，有兴趣的朋友可自行部署探索。

结语

Easysearch 的诞生，不仅填补了国产搜索引擎在分布式与轻量化领域的空白，也让更多企业在面对开源协议变动与外部技术依赖时，拥有了更加安全、灵活、可控的选择。

它既是国产替代方案的有力代表，更是新一代搜索技术生态的积极探索者，为企业级实时搜索与分析带来新的可能。

🚀 下期预告

下一篇我们将介绍 一款 AI 驱动的现代搜索引擎 - Meilisearch，基于 Rust 构建的开源搜索引擎，性能高、部署简单。号称比 Elasticsearch 快 10 倍，真的这么牛吗？

💬 三连互动

1. 你是否在使用或考虑国产搜索替代方案？
2. 在实际项目中，你最看重搜索引擎的哪些特性？（性能、兼容性、运维、成本）
3. 对 Easysearch 有什么功能上的期待？

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

✨ 推荐阅读

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

🔗 参考资源

• Easysearch 官方文档
• Easysearch 安装指南
• Elasticsearch VS Easysearch 性能测试
• 国产搜索引擎崛起：Elasticsearch 国产化加速

原文：https://infinilabs.cn/blog/2025/search-wiki-5-easysearch/

极限科技诚招全职搜索运维工程师（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）通过这些努力，旨在成为全球领先的实时搜索和数据分析解决方案提供商。