- 人工智能
- 搜索引擎
- 本地部署
- 后端
- MCP 服务
【免费下载链接】xerj
XERJ 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.
本篇指南以
user-feedback/15-clustering-durability-expectations-2025-2026/14-sla-durability-benchmarks/performance-benchmarks.md为骨架，系统整理了 2025-2026 年间公开的搜索引擎与向量数据库性能基准：Elasticsearch 与 OpenSearch、ClickHouse 的对比，Qdrant / Milvus / Weaviate / Pinecone 等向量库的延迟、吞吐与内存实测，以及缓存、过滤、冷启动等容易被忽略的性能陷阱。仓库内的 XERJ vs Elasticsearch 记分卡 与 基准方法论 提供了“如何诚实地做基准测试”的第一手对照。读完你将掌握：各主流引擎在不同工作负载下的真实量级、评估基准时必须核查的十个隐藏变量，以及如何在选型与自测中复现这些结论。
文档定位与阅读方法
该文档是一份公开基准汇编（Collected from published benchmarks, independent studies, and vendor reports），发布于 2026 年 4 月，素材全部来自对实时线上来源的新一轮检索。全文以DP-1至DP-103的编号数据点组织，覆盖四类问题：
- 通用搜索引擎对比：Elasticsearch vs OpenSearch、Elasticsearch vs ClickHouse、Typesense vs Meilisearch；
- 向量数据库对比：Qdrant / Milvus / Weaviate / Pinecone / FAISS / Redis / pgvectorscale；
- 横切主题：索引吞吐、内存占用、冷启动与分层存储、过滤条件下的 ANN 性能退化；
- 可操作性结论：末尾附有一张
Key Numbers at a Glance汇总表。
需要特别提醒：文中每个数据点都来自独立来源，测试条件（硬件、数据集、缓存状态、并发模型）并不统一，直接跨表比较数字可能误导。下文在每个小节会同时标注其适用边界，并结合 XERJ 仓库内的自测证据（SCORECARD.md、CRITICAL_FINDING_read_perf_cache_mirage.md）给出“这类基准该信什么、该怀疑什么”的判断方法。
1. Elasticsearch vs OpenSearch：两个分叉引擎的性能分水岭
1.1 Trail of Bits 独立基准（2025 年 3 月）
该基准使用 OpenSearch Benchmark（OSB）Big5 工作负载，对OpenSearch v2.17.1 与 Elasticsearch v8.15.4进行了 4 个月的测试，是"谁更快"争议中最常被引用的一组独立数据：
| 指标 | OpenSearch v2.17.1 | Elasticsearch v8.15.4 | Winner |
|---|---|---|---|
| Big5 几何均值（p90） | 12.1 ms | 18.8 ms | OS（1.6x 更快） |
| 文本查询（p90） | 18.11 ms | 7.47 ms | ES（2.42x 更快） |
| 排序（p90） | 5.82 ms | 6.14 ms | OS（1.05x 更快） |
| Term 聚合（p90） | 104.90 ms | 354.52 ms | OS（3.38x 更快） |
| 范围查询（p90） | 1.47 ms | 1.49 ms | OS（1.02x 更快） |
| 日期直方图（p90） | 124.79 ms | 2,064.61 ms | OS（16.55x 更快） |
| 向量搜索（NMSLIB vs Lucene） | 快 11.3% | baseline | OS 胜 |
| 向量搜索（FAISS vs Lucene） | 快 13.8% | baseline | OS 胜 |
| 向量搜索（Lucene vs Lucene） | 慢 258.2% | baseline | ES 胜 |
关键数据点：
- DP-1：整体 Big5 负载下 OpenSearch 比 Elasticsearch 快1.6x（p90：12.1 ms vs 18.8 ms）。
- DP-2：但就文本查询单项，Elasticsearch 反而快2.42x（7.47 ms vs 18.11 ms）。
- DP-3：OpenSearch 在日期直方图聚合上快16.55x（124.79 ms vs 2,064.61 ms）。
- DP-4：OpenSearch 最大离群比达1,412x（出现在复合日期直方图操作）。
- DP-5：Elasticsearch 最大离群比为43x（出现在 query-string 操作）。
- DP-6：98 个任务中 Elasticsearch 有 19 个任务出现离群值，OpenSearch 有 11 个。
- DP-7：缓存会把日期直方图性能虚增1,400x（缓存命中 1–5 ms，而缓存未命中是 4,163–7,136 ms）。
这条来源最有价值的启发不是"谁赢了"，而是结论高度依赖工作负载：聚合与向量场景 OS 占优，文本查询场景 ES 占优。任何"XX 全面碾压 YY"的说法都值得用同样细粒度的工作负载切片去复验。
1.2 Elastic 赞助的 ESG 基准（2025）
- DP-8：经典负载（文本搜索、排序、聚合）下 Elasticsearch 比 OpenSearch 快40%–140%。
- DP-9：默认设置下 Elasticsearch 比 OpenSearch 少用37%磁盘空间。
- DP-10：即使双方都开启
best_compression，Elasticsearch 仍多省13%空间。
1.3 Elastic 官方博客——性能差距（2025）
- DP-11：文本查询上 Elasticsearch 比 OpenSearch快 76%。
- DP-12：Term 查询 p90 约为 20 ms（ES）vs 40 ms（OS）。
- DP-13：日期直方图 p90 约为 40 ms（ES）vs 100 ms（OS）。
注意：1.1 与 1.3 在日期直方图上的结论方向相反（Trail of Bits 认为 OS 快 16.55x，Elastic 官方认为 ES 快约 2.5x）。这正是"供应商赞助基准 vs 独立基准"冲突的典型案例——评估时应把来源的资金关系纳入可信度加权。
1.4 Blunders.io 独立延迟基准
覆盖 40+ 操作的 p90 延迟：
- DP-14：默认查询：4.76 ms（ES）vs 5.18 ms（OS）。
- DP-15：Term 查询：2.46 ms（ES）vs2.32 ms（OS）。
- DP-16：小时级日期直方图：2.68 ms（ES）vs 2.95 ms（OS）。
- DP-17：范围查询：1,964.79 ms（ES）vs3,537.2 ms（OS）——相差 80%，ES 胜。
- DP-18：排序操作：729–841 ms 区间，ES 快 10–25%。
2. Elasticsearch vs ClickHouse：日志分析场景的存储与查询账本
2.1 "十亿行对决"（The Billion-Row Matchup）——存储压缩
| 配置 | 存储大小 |
|---|---|
| Elasticsearch + LZ4 + _source | 51.3 GB |
| Elasticsearch + LZ4 - _source | 38.3 GB |
| ClickHouse + LZ4 | ~5.5 GB |
- DP-19：10 亿行规模下 ClickHouse 存储比 Elasticsearch小 12x（5.5 GB vs 51.3 GB）。
规模继续放大：
- DP-20：100 亿行：Elasticsearch + LZ4 约 500 GB；ClickHouse 约 40 GB——小 12–19x。
- DP-21：1,000 亿行：ClickHouse LZ4 = 412 GB；ClickHouse ZSTD = 142 GB；Elasticsearch无法加载该数据集。
这一节与 XERJ 仓库内 DISK_SIZE_2026-07-09.md 记录的磁盘足迹调查形成了有趣的对照：在该文档的同语料（100k 文档，force-merged 单段）测试中，XERJ 稳态磁盘占用为 ES 8.13.4 的0.331x（约 2.6–3x 更小），其背后的结构性差异（列式_source、数值字段倒排索引、zstd 压缩级别在 flush/merge 路径的分级使用）与 ClickHouse 的压缩优势属于同一类"格式与编码决定存储成本"的机制。
2.2 冷缓存查询性能（10 亿行，原始数据）
| 查询 | Elasticsearch DSL | Elasticsearch ESQL | ClickHouse | CH 优势 |
|---|---|---|---|---|
| Top 3 projects 聚合 | 3.5 s | 6.8 s | 700 ms | 快 5x |
| 过滤数据 | 256 ms | 9.2 s | 42 ms | 快 6x |
- DP-22：10 亿行聚合：ClickHouse700 msvs ES DSL 3.5 s（快 5x）。
- DP-23：10 亿行过滤查询：ClickHouse42 msvs ES 256 ms（快 6x）。
- DP-24：ES ESQL 在 100 亿行上的过滤查询耗时96 秒，ClickHouse500 ms（慢 192x）。
2.3 冷缓存查询性能（100 亿行，原始数据）
- DP-25：Top 3 projects：ES DSL 33 s、ESQL 32 s、ClickHouse6.5 s（快 5x）。
- DP-26：过滤数据：ES DSL 3.5 s、ClickHouse500 ms（快 7x）。
2.4 预聚合查询（100 亿行）
- DP-27：Top 3 projects：ES 970 ms vs ClickHouse81 ms（快 12x）。
- DP-28：过滤：ES 660 ms vs ClickHouse132 ms（快 5x）。
2.5 ClickHouse Cloud 吞吐（并行执行）
- DP-29：10 亿行 / 9 节点：每秒 52 亿行，约 100 GB/秒 数据吞吐。
- DP-30：100 亿行 / 9 节点：每秒 102 亿行，192 GB/秒 数据吞吐。
2.6 内存占用
- DP-31：10 亿行 Top 3 查询：峰值 RAM 约50 MB。
- DP-32：100 亿行 Top 3 查询：峰值 RAM 约600 MB。
- DP-33：10 亿行过滤查询：峰值 RAM<20 MB。
2.7 成本效率
- DP-34：要达到 32 核 Elasticsearch 的等效延迟，ClickHouse 只需便宜 4x 的硬件（8 核 vs 32 核）。
- DP-35：AdTech 案例：ClickHouse 把查询处理从8 秒降到亚秒级。
- DP-36：AdTech 案例：ClickHouse 云存储成本比 Elasticsearch 降低60%。
- DP-37：典型日志压缩率：ClickHouse10:1–20:1vs Elasticsearch1.5:1。
阅读提示：日志分析（写多读少、高压缩率敏感）是 ClickHouse 的优势主场；ES 的优势场景是复杂查询 DSL、实时全文检索与生态。仓库内的 benchmarks/autoindex-resilience 与 benchmarks/mbox-ingest 则展示了另一类"日志/文档批量摄入"的实测路径，可作为中小数据量自测的参考。
3. 向量数据库基准：Qdrant vs Milvus vs Weaviate vs 其他
3.1 Tensorblue.com（100 万条 768 维向量）
P95 延迟：
| 数据库 | P95 延迟 |
|---|---|
| FAISS（内存驻留） | 10–20 ms |
| Qdrant | 30–40 ms |
| Pinecone | 40–50 ms |
| Weaviate | 50–70 ms |
| Milvus | 50–80 ms |
- DP-38：Qdrant P95（1M 768 维）：30–40 ms。
- DP-39：Milvus P95：50–80 ms。
- DP-40：Weaviate P95：50–70 ms。
- DP-41：FAISS 内存驻留 P95：10–20 ms（最快，但要求全量内存驻留）。
- DP-42：Pinecone P95：40–50 ms（托管服务）。
吞吐（QPS，1M 向量）：
| 数据库 | QPS 范围 |
|---|---|
| FAISS | 20,000–50,000 |
| Milvus | 10,000–20,000 |
| Qdrant | 8,000–15,000 |
| Pinecone | 5,000–10,000 |
| Weaviate | 3,000–8,000 |
- DP-43：FAISS 吞吐20,000–50,000 QPS（纯内存、无持久化）。
- DP-44：Milvus 吞吐10,000–20,000 QPS。
- DP-45：Qdrant 吞吐8,000–15,000 QPS。
- DP-46：Pinecone 吞吐5,000–10,000 QPS（托管）。
- DP-47：Weaviate 吞吐3,000–8,000 QPS。
内存占用（1M 条 768 维向量）：
| 数据库 | 内存 |
|---|---|
| Qdrant（量化后） | ~3 GB |
| FAISS | ~3 GB |
| Weaviate | ~3.5 GB |
| Pinecone | ~4 GB |
| Milvus | ~4 GB |
- DP-48：Qdrant 量化后约3 GB（1M 条 768 维向量）。
- DP-49：Milvus 约4 GB。
- DP-50：Qdrant 向量量化可在保持精度的同时将内存降低最多75%。
3.2 Qdrant 官方基准
- DP-51：对于 1,000 万条 96 维向量，Elasticsearch 索引比 Qdrant慢 10x（5.5 小时 vs 32 分钟）。
- DP-52：Milvus 索引速度最快，但在更高维度或更大向量数量下 RPS 会明显下降。
- DP-53：Redis 在低精度阈值下能取得不错 RPS，但延迟随并发请求快速上升。
向量基准尤其容易失真：
recall@k、量化方案、HNSW 图参数（M/ef_construction/ef_search）、过滤条件都直接影响结果。XERJ 仓库的 kNN 相关实现 与 向量文档 采用的"HNSW 服务 + 精确重打分"路线，即是对 recall 与延迟权衡的一种工程化取舍。
4. 向量数据库生产环境延迟（2025-2026）
来源：多份生产环境报告 / Simor Consulting / Actian / Dev.to
- DP-54：Qdrant 生产环境 p504 ms；p9925 ms。
- DP-55：Redis 内存驻留 p505 ms。
- DP-56：Milvus p506 ms（可选 GPU 加速）。
- DP-57：Pinecone p508 ms（全托管，无基础设施开销）。
- DP-58：Reddit 生产部署（3.4 亿+ 向量）：元数据过滤被识别为主要瓶颈，并发负载下 p99 延迟跳升 10x。
- DP-59：pgvectorscale 在 5,000 万向量、99% recall 下测得471 QPSvs Qdrant 的41 QPS。
- DP-60：在 90–95% recall 下，选择性元数据过滤可使二元量化查询贵 4x。
- DP-61：p99 延迟对用户体验的影响远大于中位数——一个 p50 10 ms / p99 500 ms 的系统，体感比 p50 20 ms / p99 50 ms 更慢。
DP-61 是整份文档里最值得记住的工程结论之一：优化应当以尾延迟（p99/p95）为目标，而不是中位数。XERJ 的 SCORECARD.md 同样遵循这一原则——每个读单元都同时公布 p50（判读依据）与 p99（尾延迟），并在|Δ| ≤ max(0.30ms, 20%)的噪声带内判为 TIE，避免把亚毫秒差异包装成胜利。
5. 搜索引擎索引吞吐
来源：Elasticsearch 官方夜间基准 / 多来源
- DP-62：在 Wikipedia 630 万文档数据集上，Meilisearch 索引比 Elasticsearch、PostgreSQL 和 Typesense快约 7x。
- DP-63：同数据集上 RediSearch 索引比 Elasticsearch慢约 2x。
- DP-64：Elasticsearch 开箱即用的索引性能需要大量调优才可用；默认配置并非生产就绪。
- DP-65：ClickHouse 摄入吞吐可达每秒数亿行。
- DP-66：GreptimeDB 日志摄入121,000 行/秒（比 Loki 高 1.5x）。
- DP-67：GreptimeDB 写入吞吐是 TimescaleDB 的2.17x。
- DP-68：GreptimeDB 边缘场景：每秒 600,000 数据点，CPU 占用低于 8%。
对照：XERJ 在 SCORECARD.md 的摄入单元（100k 文档 × 1 客户端）测得191,286 docs/s vs ES 111,073 docs/s（1.72x 更高）；BENCHMARK.md 记录的单节点 100k 文档批量摄入为 6.1 s、16,514 docs/s（该数字为早期端到端 HTTP 往返口径，与记分卡的 keep-alive 口径不可直接比较——这正是"数字必须绑定口径"的又一例证）。
6. Elasticsearch 大规模查询延迟
来源：Elastic Labs / QueryQuotient / Elastic Blog（2025）
- DP-69：Elasticsearch BBQ（Better Binary Quantization）在数亿向量规模下，仅用100 MB 内存占用即可实现亚 20 ms 搜索延迟（与索引大小无关）。
- DP-70：ES BBQ vs OpenSearch FAISS：同等 recall 下查询快至 5x、吞吐高 3.9x。
- DP-71：ES 9.0 BBQ 借助 SIMD 向量指令，吞吐提升8x–30x。
- DP-72：ES 9.0 BBQ recall 相比旧版提升最高 20%。
- DP-73：ES 推荐分片大小为10–50 GB/分片，以获得最优查询性能。
- DP-74：配合优化手段，ES 可处理的 QPS 提升10x，延迟从秒级降到毫秒级。
- DP-75：ES 堆内存建议约为系统总 RAM 的 50%（JVM 堆上限有效值 31.5 GB）。
7. Typesense vs Meilisearch vs Elasticsearch
来源：Meilisearch Blog / Typesense Docs / GigaSearch Medium（2025）
- DP-76：Typesense 搜索结果延迟：多数查询低于 50 ms（C++ 实现）。
- DP-77：Meilisearch 单节点部署延迟同样低于 50 ms。
- DP-78：标准文本搜索负载下 Meilisearch 索引比 Elasticsearch快约 7x。
- DP-79：Typesense 使用复制集群（每节点全量数据），Meilisearch 保持单节点——这是规模化 vs 简单性的架构取舍。
- DP-80：Elasticsearch 可扩展到企业级多 PB；Typesense/Meilisearch 面向单服务器到小集群（GB–TB 量级）。
- DP-81：Typesense 以亚 50 ms 延迟自动处理拼写错误，而 Elasticsearch 需要显式配置 fuzzy 查询。
- DP-82：RediSearch 对部分查询类型可达到亚毫秒延迟，但整体是较慢的离群者。
8. 内存占用对比
来源：2025 年多个基准
| 系统 | 工作负载 | 内存占用 |
|---|---|---|
| Redis | 全量数据集 + 开销 | 数据集大小 + 20–30% |
| Qdrant（量化） | 1M 条 768 维向量 | ~3 GB |
| Qdrant（未量化） | 1M 条 768 维向量 | 约 12 GB（估算） |
| Milvus | 1M 条 768 维向量 | ~4 GB |
| Weaviate | 1M 条 768 维向量 | ~3.5 GB |
| Elasticsearch | 生产集群 | 多个高内存节点 |
| ClickHouse | 10 亿行聚合 | 每查询峰值 ~50 MB |
| ClickHouse | 100 亿行聚合 | 每查询峰值 ~600 MB |
| SQL Server 2025 | 稳定内存授予 | ~467 MB（2022 约为 934 MB） |
- DP-83：SQL Server 2025 内存授予反馈稳定在~467 MB，约为 2022 版本的一半。
- DP-84：通用建议：给数据库操作分配系统总 RAM 的 60–80%。
- DP-85：ClickHouse 10 亿行过滤查询内存<20 MB峰值。
- DP-86：ES 生产集群在 PB 级部署下"通常需要数十个高内存节点"。
- DP-87：Qdrant 量化（标量到二元量化）可将内存降低4x–16x，代价是可配置的 recall 折损。
内存维度同样要绑定场景解读。XERJ 的 idle-budget 基准 给出了"常驻搜索守护进程"视角下的内存账本：按索引计的 idle RSS 产品线为 0.2 MB/index，CI 门禁 256 kB/index，并通过对 jemalloc 的thp:never,dirty_decay_ms:0,muzzy_decay_ms:0固定消除 THP 页粒度伪影——可见"测内存"与"测延迟"一样，必须先排除测量环境本身的干扰项。
9. Elasticsearch 冷启动与分层行为
来源：Elastic Blog 冷层测试 / Medium / Elastic Docs（2025）
- DP-88：ES 冷数据层相比热层可减少集群存储最多 50%，可靠性等价。
- DP-89：配合 searchable snapshots（ES 7.11+），节点重启后集群立即回到 green 状态，无需后台下载。
- DP-90：ES 冷层滚动重启的 green 状态"几乎瞬时"，无额外后台下载。
- DP-91：ES 没有传统意义的冷启动（JVM 进程保持温热），但罕见访问索引的首个查询会经历缓存未命中延迟尖峰。
- DP-92：未命中缓存的日期直方图查询：4,163–7,136 ms p90vs 命中缓存1–5 ms——相差1,400x。
- DP-93：ES 默认索引刷新间隔为1 秒（数据约 1 秒后可见）。
- DP-94：Apache Lucene 2025 年的改进在 ES 8.x/9.x 夜间基准中带来可测的查询加速。
缓存未命中/命中的 1,400x 差距（DP-92/DP-7）与 XERJ 仓库记录的一次"缓存海市蜃楼"教训高度同构：CRITICAL_FINDING_read_perf_cache_mirage.md 记录了 2026-07-01 的发现——此前 XERJ "读性能胜过 ES" 的结论实际上是query_cache命中造成的假象：对静态索引反复执行同一查询，第一次未命中要 2–8 秒，之后全部由缓存 0.00 秒返回；一旦写负载推进dataset_version使缓存失效，真实未缓存延迟立刻暴露。修复（有界命中物化 + 选择性查询预过滤 + 关闭缓存重新测）之后，未缓存读路径全部进入个位数毫秒，并固化为 bench-matrix.mjs 的强制约束：request_cache=false与XERJ_DISABLE_QUERY_CACHE=1双端关缓存执行。任何基准，若不能证明自己在测"未缓存执行"，其读延迟数字都不应被采信。
10. 向量搜索过滤性能：隐藏的性能杀手
来源：Qdrant / VDBBench 1.0 / Reddit Engineering / Actian（2025-2026）
- DP-95：高选择性过滤（过滤掉99%+数据）会导致查询速度波动多个数量级——被称为"隐藏性能杀手"。
- DP-96：Reddit（3.4 亿+ 向量）：并发用户增长后，元数据过滤解析耗时超过相似度计算——过滤选择性成为主要成本。
- DP-97：低选择性（90–95% recall 加过滤）下二元量化比无过滤等价查询贵约 4x。
- DP-98：后过滤（post-filtering）扩展性差——要么损失精度，要么第一阶段需要大量候选。
- DP-99：预过滤（pre-filtering）需要对全数据集做二元掩码——掩码大小随数据集线性增长（1 亿+ 向量时不可行）。
- DP-100：Qdrant 过滤搜索采用"高级查询规划策略"，在高过滤选择性下避免速度骤降、精度崩溃与 HNSW 图断裂。
- DP-101：VDBBench 1.0（2025）覆盖从低到高的过滤选择性场景，显示高选择性下各数据库结果相差数量级。
- DP-102：在向量图与关系型元数据存储间搬运数据会导致p99 延迟跳升 10x（CPU 等待磁盘 I/O）。
- DP-103：MongoDB Atlas Vector Search 的过滤 ANN 基准显示，过滤选择性超过 95% 后出现明显退化曲线。
选型含义：如果业务查询普遍带元数据过滤（租户、时间范围、状态），那么"裸 ANN 延迟"漂亮的数据库在真实负载下可能完全不是同一回事。评估时必须用带过滤的、接近生产选择性的负载复测。
汇总表：关键数字速览
| 对比 | 指标 | 结果 |
|---|---|---|
| ES vs OS（文本搜索，p90） | 延迟 | ES: 7.47 ms vs OS: 18.11 ms |
| ES vs OS（日期直方图，p90） | 延迟 | OS: 124.79 ms vs ES: 2,064.61 ms |
| ES vs OS（Big5 整体） | 延迟 | OS: 12.1 ms vs ES: 18.8 ms |
| ClickHouse vs ES（10 亿行，聚合） | 查询时间 | CH: 700 ms vs ES: 3.5 s |
| ClickHouse vs ES（100 亿行，过滤） | 查询时间 | CH: 500 ms vs ES ESQL: 96 s |
| ClickHouse vs ES（存储，10 亿行） | 磁盘 | CH: 5.5 GB vs ES: 51.3 GB |
| ClickHouse vs ES（硬件成本） | 成本 | CH 仅需便宜 4x 的硬件 |
| Qdrant（生产环境） | p50 / p99 | 4 ms / 25 ms |
| Milvus | p50 | 6 ms |
| Pinecone | p50 | 8 ms |
| Qdrant / Weaviate / Milvus（1M 向量） | P95 | 30–40 ms / 50–70 ms / 50–80 ms |
| Milvus 吞吐（1M 向量） | QPS | 10,000–20,000 |
| Qdrant 吞吐（1M 向量） | QPS | 8,000–15,000 |
| Elasticsearch BBQ vs OS FAISS | 速度 | 查询快 5x、吞吐高 3.9x |
| ES 9.0 BBQ SIMD 改进 | 速度 | 吞吐提升 8x–30x |
| ES 冷层 vs 热层 | 存储 | 减少 50% |
| ES 缓存命中 vs 未命中聚合 | 延迟 | 相差 1,400x |
| Meilisearch vs ES 索引 | 速度 | Meilisearch 约快 7x |
| ClickHouse 日志压缩率 | 比率 | 10:1–20:1 vs ES 1.5:1 |
| 过滤搜索 p99（生产环境） | 延迟尖峰 | 并发下最高 10x |
数据来源清单
以下为文档原始引用来源（按名称列出，便于检索原文）：
- Benchmarking OpenSearch and Elasticsearch —— Trail of Bits（2025 年 3 月）
- Elasticsearch vs. OpenSearch: Performance and resource utilization —— Elastic Blog
- Elasticsearch Benchmarks —— Elasticsearch vs. OpenSearch —— Blunders.io
- ClickHouse vs. Elasticsearch: The Billion-Row Matchup —— ClickHouse Blog
- ClickHouse vs. Elasticsearch —— DoubleCloud Comparison
- ClickHouse vs Elasticsearch for Log Analytics —— OneUptime（2026）
- Vector Search Benchmarks —— Qdrant
- Best Vector Database 2025: Pinecone vs Weaviate vs Qdrant vs Milvus —— Tensorblue
- VDBBench 1.0: Real-World Benchmarking for Vector Databases —— Milvus Blog
- Vector Search Performance Benchmark: SingleStore, Pinecone, Zilliz —— benchANT
- MongoDB Vector Search Benchmark Results —— Atlas Docs
- Elasticsearch 9.0 & 8.18: BBQ GA —— Elastic Blog
- Elasticsearch vs Qdrant vs Meilisearch —— Meilisearch Blog
- Typesense vs Algolia vs Elasticsearch vs Meilisearch —— Typesense
- Meilisearch vs Typesense —— Meilisearch Blog
- Benchmarking Performance: Elasticsearch vs Competitors —— GigaSearch / Medium
- Testing Elasticsearch Cold Tier at Scale —— Elastic Blog
- Database Performance Benchmarks —— GreptimeDB（2025）
- Vector Database Benchmarks are Misleading: What Matters —— Actian（2026）
- Choosing a vector database for ANN search at Reddit —— Milvus Blog
- VectorDBBench —— Zilliz
- OpenSearch vs Elasticsearch (2025) —— Medium / Jagadeesh Chandra
- ClickHouse vs Elasticsearch 2026 —— Tasrie IT Services
如何把这些数字用在自己的评估里：仓库内的对照证据
汇编文档提供的是"行业快照"，而要得出属于自己的结论，必须有一套可复现的、诚实的方法论。XERJ 仓库恰好把这样一套方法论连同原始结果一起开源了，可作为自测模板：
- 同机、同负载、双引擎对打：SCORECARD.md 记录 XERJ v1.0.0-rc.6 vs Elasticsearch 8.13.4 的 88 个测量单元（摄入、全查询族、聚合、管道、混合读写、kNN、磁盘占用），结果 55 WIN / 26 TIE / 4 LOSE / 3 N/A——且 4 个 LOSE（写压下的读 p99）被逐一根因定位到 memtable 锁竞争（见 MIXED_READ_UNDER_WRITE_FINDING_2026-07-08.md），没有隐藏。
- 客户端口径决定结论：bench-matrix.mjs 明示了为什么不能用 Node 全局
fetch（undici 约 1.5 ms 客户端开销会淹没双引擎亚毫秒服务端时间），并改用共享 keep-alivehttp.Agent（XERJ 0.126 ms vs ES 0.283 ms 的真实服务端往返）。 - 噪声带与 TIE 规则：
|Δ| ≤ max(0.30ms, 20%)判 TIE——本汇编文档中 ES/OS 间大量亚毫秒差异（DP-12、DP-15）按此规则都算不上胜利。 - 开环 vs 闭环：bench-methodology.test.mjs 用固定延迟 mock 服务器证明：开环 200 req/s 在 40 ms 真延迟的服务上会把 p50 虚增 4x+（背压排队伪影），这解释了为何本汇编中"高延迟查询"与"低延迟查询"必须分开发布。
- 缓存必须关闭：详见上一节"缓存海市蜃楼"教训。
- 磁盘与内存要分场景：DISK_SIZE_2026-07-09.md 与 index-size/run.sh 展示了 force-merged 稳态下按文件扩展名拆解的磁盘账本；idle-budget/run.sh 展示了常驻进程按索引计的 idle RSS 预算与门禁。
最后，把"性能"与"耐久性/集群期望"放在一起看：本汇编所属的目录15-clustering-durability-expectations-2025-2026关心的正是"多节点集群到底承诺了什么"。XERJ 官方集群文档（landing/docs/clustering.html）给出的诚实边界是：单二进制内置 Raft 环（选主、心跳、HMAC-SHA256 认证传输、持久化本地 Raft 日志），但索引、映射与文档目前仍是节点本地，跨节点复制尚未落地；若需要第二份活数据副本，官方建议使用 WAL tap 或逐节点备份。这与本汇编中"多高内存节点的 ES 集群""ClickHouse 多节点吞吐"等规模化数字形成了互补视角：规模化能力与数据冗余承诺，应当和延迟、吞吐一样，被列入选型评估的必测清单。
- 人工智能
- 搜索引擎
- 本地部署
- 后端
- MCP 服务
【免费下载链接】xerj
XERJ 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.
相关推荐
GetQzonehistory 批量导出 QQ 空间历史说说：扫码登录后自动跑完，十年动态、评论和配图落进本地硬盘
GetQzonehistory 批量导出 QQ 空间历史说说：扫码登录后自动跑完，十年动态、评论和配图落进本地硬盘 QQ 空间没有导出入口，你攒了十几年的说说，
网页爬虫数据分析PDF补丁丁完整指南：免费快速解决PDF书签、页面与限制难题的终极方案
PDF补丁丁完整指南：免费快速解决PDF书签、页面与限制难题的终极方案 办公桌上堆着十几份页面大小不一、没有书签、还带着打印限制的PDF文件，想统一整理却找不到
桌面应用GPT-NeoX推理性能测试终极指南：如何优化大语言模型的吞吐量与延迟
GPT NeoX推理性能测试终极指南：如何优化大语言模型的吞吐量与延迟 GPT NeoX是由EleutherAI开发的开源大语言模型训练框架，基于DeepSpe
深度学习NLP大模型分布式训练预训练
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
![【关注可白嫖源码】--课程设计--毕业设计--78966形体管理中心系统[编号：project79321]（案件分析）](http://pic.xiahunao.cn/yaotu/【关注可白嫖源码】--课程设计--毕业设计--78966形体管理中心系统[编号：project79321]（案件分析）)
