XERJ 与 Elasticsearch 对比基准 Scorecard 深度解析:bench-matrix.mjs、88 项指标与四个已知短板

📅 发布时间:2026/10/17 11:32:46
XERJ 与 Elasticsearch 对比基准 Scorecard 深度解析:bench-matrix.mjs、88 项指标与四个已知短板
【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载本篇技术指南围绕 XERJ 仓库中由demo/playbooks/bench-matrix.mjs自动生成的基准记分卡 demo/playbooks/SCORECARD.md 展开逐行解读其评分规则、三条测量方法论、88 项指标结果并深入源码分析唯一四处 LOSE混合读写场景 p99的根因。读完本文你将掌握这套单机、同机、同负载对比基准的复现命令、每一项指标的可信边界以及 XERJ 当前真实的性能强弱分布。一、Scorecard 是什么一份由代码生成的、可 CI 门禁的对比记分卡SCORECARD.md不是手工整理的市场宣传材料而是由运行器 demo/playbooks/bench-matrix.mjs 在同一台机器localhost上让 XERJ:9200与 Elasticsearch:9201以完全相同的负载跑完全部测量后自动写出的产物。运行条件被严格固定单节点、关闭安全认证--insecure/ security-off避免 TLS 与认证链路干扰延迟读数语料合成 LLM 遥测数据字段形态贴近真实业务分布由 demo/data/extras/generate_demo_corpus.py 以random.seed(42)生成落盘到 demo/data/extras/chat-events.ndjson。该文件共4008 条不同事件读路径测量时循环灌入100k 文档并发客户端为1输出每一行一个指标给出 XERJ 值、ES 值、归一化 ratio 与 WIN/LOSE 判定运行器主函数末尾任何 LOSE 都会让进程以退出码 1 结束if (loses.length) { … process.exit(1); }因此整份记分卡可以直接作为 CI 回归门禁ci-check.sh 亦按此思路编排 smoke liveness benchmark 检查。字段映射MAPPING与语料字段一一对应timestamp(date)、model/intent/status/tenant/top_doc(keyword)、cache_hit(boolean)、prompt_tokens/context_tokens/completion_tokens/latency_ms(integer)、cost_usd(double)共 12 个字段、24 小时日内分布峰值在 13 时附近生成脚本中每种模型还带有成本系数与延迟基数使聚合结果有真实统计形态而非均匀噪声。二、评分语义ratio 归一化、TIE 噪声带与 CI 门禁记分卡的判定全部站在 XERJ 视角WIN XERJ 更好延迟更低 / docs·s 更高 / 磁盘更小 / 召回更高ratio 经过归一化使得1× 表示 XERJ 更好。具体到不同维度方向相反写入吞吐docs/s、kNN recall10数值越大越好ratio XERJ/ES读延迟ms、混合读写 p99、磁盘占用数值越小越好ratio ES/XERJ。判定分三级对应scoreRow的实现判定条件是否导致 CI 失败WIN明确优于对方且不在噪声带内否TIE双方都有效且|Δ| ≤ max(0.30ms, 20% × min)否LOSE明确劣于对方是混合写场景除外见第四节N/A任一方返回 4xx如unsupported (400)或结果不可比否值得注意的三类边界情形同值 TIEconstant_score0.99×、exists(cost_usd)0.98×这类纯过滤、无排序计算的查询双方都到 0.3ms 量级落在噪声带内记为 TIE不会被误判为回归。N/A 不等于 ES 缺功能combined_fields与match_phrase_prefix两行 ES 返回 400是因为语料把top_doc声明为keyword见 bench-matrix.mjs而 ES 将这两类查询限制在text字段——是字段类型校验更宽松XERJ 接受并在 keyword 上执行并非 ES 能力缺失。官方基准页 landing/benchmarks/elasticsearch.html 对此有明确披露。正确性护栏所有 JSON_search请求都会被注入track_total_hits: trueES 默认截断在 10000 的关系值会让命中数不可比并在打分前用signalMismatch对比两端的命中数与每个顶层聚合的数值——任一端静默 no-opHTTP 200 但 0 命中都会把该行标记为 N/A 而非按延迟授奖杜绝更快但算错了的虚假 WIN。三、三条测量方法论如何让亚毫秒延迟可比原文档用三个引用块披露了方法论它们是读懂整张表的前提也是这套基准的诚实性设计3.1 传输层不用 Node 全局 fetchundici读/混合/kNN 延迟全部走一个精简 keep-alive HTTP 客户端Node 核心http 每 host 共享的http.AgentmaxSockets: 256见 bench-matrix.mjs对两个引擎完全相同的代码路径与请求头Agent 只按host:port区分。原因在代码注释中写得很清楚undici fetch 每次请求约增加~1.5ms 纯客户端开销会把两个引擎亚毫秒级的服务端耗时全部压进同一个噪声带。用同一个客户端实测size:0均值、30 万文档客户端XERJESundici fetch1.61ms2.77mshttp keep-alive0.126ms0.283mskeep-alive 客户端才暴露出两引擎真实的服务端往返差距约 2.2×。原始 TCP socket 更瘦XERJ 0.054ms但无法解析 chunked 响应所以统一用 Node 核心 http 解析器同时支持 content-length 与 chunked对 ES 也公平。写路径ingest / mixed / kNN 批量装载则对两个引擎统一使用curl。3.2 无缓存执行两个引擎每次都真算每次读请求都带request_cachefalse且 XERJ 以XERJ_DISABLE_QUERY_CACHE1启动两个引擎每次迭代都实际执行查询禁止整结果缓存克隆。查询体从不按迭代变异两端的底层 filter/OS 缓存保持开启对等。读行显示 p50判据并附 p99。3.3 混合读写开放式绝对截止时间调度iso-load背景写进程是OPEN-LOOP每 250ms 绝对截止时间启动一个BATCH10k 的_bulk报价40,000 docs/s对两引擎字节级一致不依赖每次 bulk 的耗时闭环写进程恰恰会在引擎卡顿时减少其写负载。最多 3 个 bulk 在飞某次 tick 发现 2 在飞则跳过并计一次overrun。每一行混合指标都带写模式与实际达成速率标注只有双方都在报价目标的 ±5% 内才声明 iso-load。本次运行XERJ 达成 39,626/s发射 2,080,000 文档、0 overrun、窗口末可见 2,380,000ES 达成 39,688/s发射 2,090,000、0 overrun、可见 2,370,000——注意可见数按各自语义统计ES_count不含未 refresh 文档不代表 memtable 深度。四、完整指标矩阵88 行与 SCORECARD.md 逐行一致4.1 写入与读查询dimensionXERJESratioverdictingest 100k × c1 (docs/s)191,286111,0731.72×WINread q: match_all (p50 ms)0.35 (p99 1.10)0.32 (p99 0.45)0.93×TIEread q: match_none (p50 ms)0.11 (p99 0.25)0.25 (p99 0.38)2.24×TIEread q: match(model) (p50 ms)0.33 (p99 0.43)0.42 (p99 1.20)1.25×TIEread q: match_phrase(top_doc) (p50 ms)0.33 (p99 0.46)0.43 (p99 1.03)1.28×TIEread q: match_phrase_prefix (p50 ms)2.07 (p99 5.05)unsupported (400)—N/Aread q: match_bool_prefix (p50 ms)0.34 (p99 0.45)0.69 (p99 1.59)2.00×WINread q: multi_match (p50 ms)0.42 (p99 0.52)0.84 (p99 2.26)2.02×WINread q: combined_fields (p50 ms)5.04 (p99 5.46)unsupported (400)—N/Aread q: query_string (p50 ms)0.60 (p99 0.71)1.44 (p99 2.69)2.41×WINread q: simple_query_string (p50 ms)0.34 (p99 0.42)0.39 (p99 1.14)1.14×TIEread q: more_like_this (p50 ms)0.34 (p99 0.44)0.40 (p99 0.81)1.20×TIEread q: term(status) (p50 ms)0.33 (p99 0.44)0.38 (p99 1.04)1.16×TIEread q: terms(model) (p50 ms)0.35 (p99 0.72)0.67 (p99 0.82)1.93×WINread q: range(latency_ms) (p50 ms)0.27 (p99 0.75)0.65 (p99 0.76)2.41×WINread q: range(timestamp) (p50 ms)0.31 (p99 0.46)0.34 (p99 0.82)1.10×TIEread q: range(cost_usd) (p50 ms)0.28 (p99 0.94)0.76 (p99 1.20)2.67×WINread q: prefix(model) (p50 ms)0.33 (p99 0.41)1.26 (p99 2.34)3.85×WINread q: wildcard(model) (p50 ms)0.33 (p99 0.42)1.33 (p99 2.50)4.01×WINread q: regexp(model) (p50 ms)0.28 (p99 0.40)1.35 (p99 2.50)4.86×WINread q: fuzzy(model) (p50 ms)0.48 (p99 0.57)0.59 (p99 0.73)1.23×TIEread q: exists(cost_usd) (p50 ms)0.34 (p99 0.42)0.33 (p99 0.46)0.98×TIEread q: ids (p50 ms)0.14 (p99 0.28)0.27 (p99 0.37)1.96×TIEread q: term(cache_hit) (p50 ms)0.35 (p99 0.74)0.39 (p99 0.48)1.10×TIEread q: bool mustfiltershouldmust_not (p50 ms)1.24 (p99 1.54)2.03 (p99 5.06)1.64×WINread q: constant_score (p50 ms)0.33 (p99 0.42)0.33 (p99 0.44)0.99×TIEread q: boosting (p50 ms)1.41 (p99 1.87)2.56 (p99 5.27)1.82×WINread q: dis_max (p50 ms)0.34 (p99 0.44)0.81 (p99 0.94)2.40×WINread q: function_score (p50 ms)1.59 (p99 1.92)5.03 (p99 5.06)3.16×WINread q: pinned (p50 ms)1.09 (p99 1.23)1.44 (p99 1.95)1.32×WIN阅读提示全文匹配match_all双方都在 0.3ms 量级TIE而 ES 的 0.32ms 甚至略低——这正说明该基准没有系统性地偏向任何一方XERJ 的优势集中在需要扫描倒排/字典的查询族prefix 3.85×、wildcard 4.01×、regexp 4.86×、query_string 2.41×、range 2.41–2.67×以及需要现场打分/合并的复合查询function_score 3.16×、boosting 1.82×。4.2 聚合metric / bucket / pipelinedimensionXERJESratioverdictread agg: avg (p50 ms)0.11 (p99 0.22)1.70 (p99 2.21)15.12×WINread agg: sum (p50 ms)0.11 (p99 0.21)1.86 (p99 2.18)16.56×WINread agg: min (p50 ms)0.11 (p99 0.22)0.28 (p99 0.39)2.46×TIEread agg: max (p50 ms)0.11 (p99 0.21)0.29 (p99 0.85)2.57×TIEread agg: stats (p50 ms)0.12 (p99 0.52)1.83 (p99 2.22)15.85×WINread agg: extended_stats (p50 ms)0.27 (p99 0.34)2.04 (p99 2.57)7.56×WINread agg: value_count (p50 ms)0.11 (p99 0.21)1.39 (p99 1.59)12.45×WINread agg: cardinality (p50 ms)0.49 (p99 1.03)1.29 (p99 1.59)2.62×WINread agg: percentiles (p50 ms)0.26 (p99 0.75)6.93 (p99 10.05)26.67×WINread agg: percentile_ranks (p50 ms)0.23 (p99 0.75)6.98 (p99 10.05)30.14×WINread agg: median_absolute_deviation (p50 ms)0.44 (p99 0.74)10.05 (p99 12.10)23.09×WINread agg: matrix_stats (p50 ms)2.50 (p99 5.06)12.62 (p99 20.96)5.05×WINread agg: scripted_metric (p50 ms)0.25 (p99 0.61)5.03 (p99 5.12)19.78×WINread agg: top_hits (sub) (p50 ms)2.06 (p99 2.65)5.04 (p99 5.23)2.44×WINread agg: terms (p50 ms)0.27 (p99 0.68)0.36 (p99 1.45)1.33×TIEread agg: rare_terms (p50 ms)0.27 (p99 0.37)5.04 (p99 6.58)18.91×WINread agg: significant_terms (p50 ms)0.11 (p99 0.22)1.70 (p99 5.04)15.03×WINread agg: histogram (p50 ms)1.80 (p99 2.29)2.31 (p99 5.07)1.28×WINread agg: date_histogram (p50 ms)0.18 (p99 0.26)0.36 (p99 0.69)2.02×TIEread agg: auto_date_histogram (p50 ms)0.20 (p99 0.27)2.09 (p99 5.05)10.63×WINread agg: variable_width_histogram (p50 ms)0.51 (p99 0.59)6.69 (p99 10.04)12.99×WINread agg: range (p50 ms)0.16 (p99 0.24)0.34 (p99 0.90)2.16×TIEread agg: date_range (p50 ms)0.17 (p99 0.24)0.33 (p99 1.22)1.91×TIEread agg: filter (p50 ms)0.93 (p99 1.02)2.26 (p99 5.04)2.43×WINread agg: filters (p50 ms)0.13 (p99 0.23)0.30 (p99 0.97)2.32×TIEread agg: missing (p50 ms)0.11 (p99 0.22)0.81 (p99 1.16)7.14×WINread agg: global (p50 ms)0.15 (p99 0.27)1.45 (p99 1.64)9.95×WINread agg: adjacency_matrix (p50 ms)0.89 (p99 1.70)1.84 (p99 5.07)2.07×WINread agg: composite (p50 ms)0.35 (p99 0.93)5.03 (p99 5.06)14.29×WINread agg: random_sampler (p50 ms)0.66 (p99 0.84)0.54 (p99 0.66)0.82×TIEread agg: termsavg(cost) (p50 ms)0.86 (p99 1.10)2.40 (p99 5.04)2.79×WINread pipe: sum_bucket (p50 ms)0.86 (p99 0.93)2.31 (p99 2.62)2.67×WINread pipe: avg_bucket (p50 ms)0.87 (p99 0.95)2.13 (p99 5.06)2.45×WINread pipe: max_bucket (p50 ms)0.86 (p99 0.95)2.17 (p99 5.11)2.51×WINread pipe: stats_bucket (p50 ms)0.86 (p99 0.94)2.11 (p99 5.06)2.45×WINread pipe: percentiles_bucket (p50 ms)0.86 (p99 0.99)2.22 (p99 5.04)2.58×WINread pipe: derivative (p50 ms)0.88 (p99 0.96)2.37 (p99 5.09)2.71×WINread pipe: cumulative_sum (p50 ms)0.86 (p99 0.94)2.15 (p99 5.05)2.49×WINread pipe: moving_fn (p50 ms)0.88 (p99 0.96)2.32 (p99 5.04)2.64×WINread pipe: serial_diff (p50 ms)0.86 (p99 1.03)2.25 (p99 5.05)2.61×WINread pipe: bucket_script (p50 ms)0.97 (p99 1.09)3.08 (p99 5.04)3.16×WINread pipe: bucket_selector (p50 ms)0.88 (p99 0.97)2.26 (p99 5.04)2.58×WINread pipe: bucket_sort (p50 ms)0.87 (p99 0.96)2.19 (p99 5.05)2.51×WIN阅读提示聚合是 XERJ 最强势的战场——sum/avg/stats/value_count都在 0.11–0.12ms12×percentiles26.67×、percentile_ranks30.14×、median_absolute_deviation23.09×把 ES 的 6.9–10ms 压到 0.2–0.4ms。从源码看这与 XERJ 的列式 doc-values 路径直接相关聚合走列存而非整文档物化engine/crates/xerj-engine/src/fast_aggs.rs中 memtable 侧亦以all_docs_with_sources_arc兜底见下节。唯一反例是random_sampler0.82× TIE属于采样型聚合双方都很快落入噪声带。4.3 搜索特性、混合读写、kNN 与磁盘dimensionXERJESratioverdictread feat: sort-heavy (p50 ms)1.61 (p99 1.93)2.46 (p99 5.11)1.53×WINread feat: deep fromsize (from 500) (p50 ms)0.77 (p99 1.10)0.65 (p99 1.47)0.85×TIEread feat: search_after (p50 ms)1.70 (p99 1.93)2.28 (p99 5.07)1.34×WINread feat: highlight (p50 ms)0.34 (p99 0.45)0.49 (p99 1.21)1.45×TIEread feat: _count (p50 ms)0.14 (p99 0.20)unsupported (400)—N/Aread feat: _msearch (p50 ms)0.16 (p99 0.22)0.28 (p99 0.57)1.79×TIEread feat: _mget (p50 ms)0.07 (p99 0.19)0.15 (p99 0.63)2.23×TIEmixed match_all (p99 ms, under write) [iso-load open-loop 40,000/s: XERJ ach 39,626/s, ES ach 39,688/s]13.573.450.25×LOSEmixed bool (p99 ms, under write) [iso-load open-loop 40,000/s: XERJ ach 39,626/s, ES ach 39,688/s]13.456.760.50×LOSEmixed range (p99 ms, under write) [iso-load open-loop 40,000/s: XERJ ach 39,626/s, ES ach 39,688/s]10.273.680.36×LOSEmixed terms (p99 ms, under write) [iso-load open-loop 40,000/s: XERJ ach 39,626/s, ES ach 39,688/s]10.743.570.33×LOSEmixed cardinality (p99 ms, under write) [iso-load open-loop 40,000/s: XERJ ach 39,626/s, ES ach 39,688/s]10.6120.131.90×WINkNN k10 (p50 ms)1.762.081.18×TIEkNN recall10100.0%100.0%1.00×WINindex on-disk size176.2 MB283.0 MB1.61×WIN阅读提示_count的 N/A 同样不是 ES 能力缺口——ES 8.13.4 支持_count但该端点不接受request_cache参数bench-matrix.mjs 将其发往/perf/_count?request_cachefalseES 因而 400XERJ 接受未知参数并作答属于宽松校验而非能力优势。kNN 的 recall10 为 100.0%是基于 128 维、5 万向量的独立索引以客户端暴力余弦 top-10 为精确基准knnBench查询向量对两个引擎完全相同。磁盘占用以_stats的store.size_in_bytes为同一口径bench-matrix.mjs避免用du误比较不同数据目录。五、四个 LOSE 的根因混合读写下的 memtable 锁竞争这是原文档明确标注的已知、已文档化的架构差距四行mixed … (under write)的 p99 落在 10–13.6ms而 ES 只有 3.4–6.8msratio 0.25×–0.50×。它被排除在 CI 门禁之外单独跟踪追踪文档为 demo/playbooks/MIXED_READ_UNDER_WRITE_FINDING_2026-07-08.md。结合源码可以把根因链讲清楚读的卡顿是锁竞争不是 CPU 竞争。文档记录了 gdb 现场20.9s 的读期间 CPU 只有 ~306%约 3/32 核363 个线程中 358–362 个处于睡眠态堆栈显示读端阻塞在FtsMemtable每分片parking_lot::RwLock的RwLock::read→lock_shared_slow写端阻塞在RwLock::write→wait_for_readers——经典的 writer-preference 级联新读者排在有等待写者之后。为什么慢读会撞上写锁对于带 term/range/bool 过滤器的size:0聚合memtable 侧走mem_snapshot的DocsForScan分支engine/crates/xerj-engine/src/index.rs需要物化 memtable 内每一个文档all_docs_with_sources_arc()见 fast_aggs.rs再在s.read()持锁期间完成折叠。写入洪峰下 memtable 几乎持有全部近期文档于是该路径是 O(全部 memtable 文档) 且长时间持锁——segment 侧同款问题已在 commit 5098645 用列式过滤解决7.8s→~10msmemtable 侧尚未处理。文档同时记录了一次重要的诚实性修正早期复现用显式_id写入每文档取一次分片写锁把卡顿放大了约 100×真实基准用 auto-id 的{index:{}}批量路径每 ~512 文档 chunk 一次写锁。因此本轮 10–13.6ms 才是代表性量级先前 62–152ms 的数字不代表基准场景。附带一个待验证的竞态标记store_exception: No such file or directory暗示读快照未在读取期间钉住 segment 文件的 reader-vs-GC 竞态合并完成后的延迟删除宽限期与超长读的交叉文档明确要求先做最小复现、不要过度声称。修复方向在文档中亦有规划给 memtable 过滤聚合加列式 position fold仅枚举匹配位置、缩短锁持有并以ES-compat YAML 全绿 auto-id 复现混合 p99 回到低两位数 ms 无 store_exception为硬门槛。六、跳过的查询族为什么有些 ES 查询没进矩阵以下族需要专用索引/映射而平坦遥测语料不具备故被显式列出而非静默丢弃并附原因geo_distance / geo_bounding_box / geo_polygon / geo_shape— 语料无 geo_point/geo_shape 字段geohash_grid / geotile_grid / geo_distance-agg / geo_bounds / geo_centroid— 语料无 geo_point 字段ip_range / ip_prefix— 语料无 ip 字段nested / has_child / has_parent (join)— 语料平坦无 nested/join 映射span_term / span_near / span_or / span_not / span_first / span_containing / span_within— 需要带位置的 text 字段significant_text— 需要被分析的 text 字段语料字段均为 keywordsemantic / hybrid retriever— 需要 dense_vector 字段 embed 步骤由--knn单独覆盖knn (as query/top-level)— 由--knn在专用 dense_vector 索引上单独覆盖percolate— 已实现为真正的反向搜索文档扫描每文档存一条查询、用输入文档匹配它对应 index.rs 的QueryNode::Percolate分支但平坦语料中没有可匹配的存储查询字段故跳过七、如何复现bench-matrix.mjs 的 CLI 用法运行器无第三方依赖Node 24 系统curl常用命令如下# 全量默认docs{100k,1m}、clients{1,8}含读矩阵输出 SCORECARD.md node demo/playbooks/bench-matrix.mjs # 指定矩阵规模并追加混合读写与 kNN node demo/playbooks/bench-matrix.mjs --docs 100k,1m --clients 1,8 --knn --mixed # 指定两端引擎地址默认 XERJ :9200 / ES :9201 node demo/playbooks/bench-matrix.mjs --xerj http://localhost:9200 --es http://localhost:9201 # 仅读矩阵 / 仅写入矩阵 / 仅混合读写单元 node demo/playbooks/bench-matrix.mjs --reads-only node demo/playbooks/bench-matrix.mjs --ingest-only --docs 1m --clients 1,4,8 node demo/playbooks/bench-matrix.mjs --mixed-only其他与读数可靠性直接相关的实现细节均对两引擎完全对称读前归并读矩阵前两引擎的/perf都会forcemerge到单段并统一静默 3 秒bench-matrix.mjs主流程 833–838 行保证读测量在等价的段结构上进行官方基准页亦披露了主机规格AMD Ryzen AI Max 395、32 硬件线程、119 GiB RAM、Linux。请求超时护栏每个请求 15s 超时引擎在负载下崩溃/超时按最差延迟计分LOSE而不是被误标成不支持N/A掩盖回归。would-be LOSE 的三次复测首个样本判 LOSE 的行会对两个引擎一起再测最多两次取每端中位数打分——真回归三局全输仍是 LOSE只输第一局的不误杀协议保持对称。旧版 harness 隔离demo/playbooks/bench.mjs 因使用非规范传输undici fetch被弃用运行前必须显式设置FORCE_LEGACY_BENCH1防止其覆盖规范记分卡文件。八、结论与边界声明本轮总计55 WIN、4 LOSE、26 TIE、3 N/A共 88 行。客观的读法是在单机、同机、单节点、关安全、10 万文档、已归并静默这一精确限定下XERJ 在写入吞吐1.72×、字典扫描型查询prefix/wildcard/regexp 3.85×–4.86×、聚合与管道聚合多数 2×–30×和磁盘占用1.61×上领先在大量简单查询上与 ES 持平TIE而混合读写写压场景的 p99 落后于 ES——这是文档与源码都确认的已知架构差距也是后续优化memtable 列式过滤聚合的目标区域。所有结论仅适用于本仓库可复现的环境不构成对任意工作负载的普适宣称。延伸阅读官方基准页 landing/benchmarks/elasticsearch.html含逐行渲染与历史修正记录、根因追踪 demo/playbooks/MIXED_READ_UNDER_WRITE_FINDING_2026-07-08.md、一键 CI 编排 demo/playbooks/ci-check.sh。赞分享【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载相关推荐XERJ 与 Elasticsearch 全维对标88 项基准矩阵的测量方法、分数卡与复现指南XERJ 与 Elasticsearch 全维对标88 项基准矩阵的测量方法、分数卡与复现指南 导读 本文围绕仓库中的 demo/playbooks/BENXERJ 与 Elasticsearch 单机对比全解析88 项实测、4 场失败与迁移选型指南XERJ 与 Elasticsearch 单机对比全解析88 项实测、4 场失败与迁移选型指南 导读 XERJ 是一个从零用 Rust 写成的搜索引擎通过XERJ 对决 Elasticsearch同机同载荷下的 head-to-head 基准测试深度解析XERJ 对决 Elasticsearch同机同载荷下的 head to head 基准测试深度解析 本篇技术指南以 engine/reports/2026上一篇eSearch 主进程开发指南异形窗口鼠标穿透、运行目录定位与系统语言获取下一篇MAS 激活脚本Windows 与 Office 免费激活 4 条路线选型10 分钟完成实操与翻车自救创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考