- 人工智能
- 搜索引擎
- 本地部署
- 后端
- 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/08-cloud-native-expectations/data-points.md这份调研文档（共 75 条数据点，覆盖 2025 年 1 月至 2026 年初的 CNCF 年度调查、Percona/CloudNativePG、Gartner 系行业报告与厂商工程博客），系统解读 2025–2026 年用户对云原生数据库/搜索引擎的核心期望，并结合 xerj 仓库中的 Helm chart、Raft 元数据复制与 region 自动分裂等源码实现，说明这些行业期望在一个 Elasticsearch 兼容搜索引擎中如何被满足、以及当前的适用前提与限制。
一、文档定位：一份带时间戳与出处的期望基线
data-points.md 是该调研目录08-cloud-native-expectations/下的核心汇总表，与同目录的 trends-2025-2026.md、kubernetes-docker-pain.md、observability-monitoring.md 等文件构成一套完整的证据链。文档采用四列结构：编号 + 引文/摘要 + 来源 + 日期 + 类别，所有 75 条数据点均可回溯到具体来源与年份，便于按类别筛选。
其类别分布大致如下：
| 类别 | 典型数据点编号 | 核心信号 |
|---|---|---|
| Kubernetes 采用率 | #5、#6、#7 | 82% 容器用户在生产环境运行 K8s；98% 组织已采用云原生技术 |
| Kubernetes Operators | #12–#16、#43 | 多集群 + GitOps 成为基线；备份/恢复正确性优先于速度 |
| 存算分离 / 多云 | #17–#21、#49–#51 | Aurora/PolarDB/GaussDB/TDSQL 均已转向存算分离 |
| 零停机 / 自动分片 | #22–#32 | 3 秒逻辑复制切换、Blue-Green 升级成为基准 |
| 可观测性 / GitOps | #33–#35、#38 | Prometheus 格式指标 + 分布式追踪 + 结构化日志是生产 K8s 的硬性要求 |
| 开发者偏好 | #39–#41 | PostgreSQL 连续三年居 Stack Overflow 榜单首位 |
| 多区域 / 供应商锁定 / 合规 | #49–#58 | EU Data Act、SOC 2、AES-256 + TLS 1.3 |
| 韧性 / 停机成本 | #22、#23、#62–#65 | 组织年均故障 86 小时；大型停机每小时成本超 30 万美元 |
| 成本 / FinOps | #69–#72 | 无治理时 70% 企业超支至少 25%；50% FinOps 从业者将优化浪费列为首要任务 |
| 连接池 / 自动扩缩 | #36–#37、#73–#74 | K8s 1.35 In-Place Pod Resize GA；PgBouncer sidecar 事务池化 |
阅读这份文档的关键方法：它记录的不是"某款产品的功能清单"，而是用户在 2025–2026 年评估任何数据基础设施时默认会勾选的检查项。以下按类别展开，每类给出代表性数据点、出处与年份，再结合 xerj 仓库的实现说明这些期望的落地方式。
二、Kubernetes 从可选部署方式变为默认运行环境
数据点 #5–#7（CNCF Annual Cloud Native Survey，2026 年 1 月）给出了三个硬数字：82% 的容器用户在生产环境运行 Kubernetes；98% 的被调查组织已采用云原生技术（"已越过早期采用阶段"）；79% 的 "Innovators" 类型组织在容器化生产环境运行有状态应用——后者直接意味着"容器化数据库"不再是边缘话题。#8（CNCF Cloud Native Survey 2025）补充了 AI 维度：66% 的组织已在 Kubernetes 上运行生成式 AI 工作负载。
采用侧的阻力同样被量化记录。#9–#11（CNCF / SlashData Developer Nation Survey，2025 年 Q1）指出：云原生团队当前最大的挑战是开发团队内部的文化转变（47%），超过培训不足（36%）与安全顾虑（36%）；其次是工具与平台选型（52%）和架构复杂度（51%）；"自动化应用供给与管理"是云原生组织排名第一的运营挑战。#75（Techzine / Cloud Native Now，2025）则记录了对应的平台侧趋势：CIO 正在强制推行"简化平台 + 端到端可见性 + 内置自动化与治理"。
对搜索引擎的含义：任何搜索/数据库产品的部署形态，2025 年起的默认假设是"跑在 Kubernetes 上、由 Operator 或 Helm chart 管理、通过 GitOps 变更"。xerj 仓库中 deploy/helm/xerj/values.yaml 正是对这个假设的直接响应，其默认值设计可以逐条对照数据点解读：
- 探针与就绪语义（对应 #11 "自动化应用供给"、生产 K8s 的基本要求）：chart 内置
liveness（/health/live，5 秒初始延迟）与readiness（/health/ready，2 秒初始延迟）两组探针配置，failureThreshold: 3，无需用户手写 probe YAML。 - 安全默认值（对应 #55 "SOC 2 与 GDPR 是不可协商的前置条件"）：
insecure: false默认关闭——注释明确说明"insecure 默认值是 NoSQL 数据泄露事件中被引用最多的原因"；securityContext默认runAsNonRoot: true、allowPrivilegeEscalation: false、capabilities.drop: [ALL]，与文档 #16、#66 中"减少手工凭证管理、收敛长期凭证"的方向一致。 - 持久化：
persistence.size默认 50Gi、accessMode: ReadWriteOnce，storageClass留空走集群默认——注意 #45–#48 记录的 PVC 痛点（Pending 状态、扩容依赖 StorageClass 的allowVolumeExpansion、Azure 磁盘只能在未挂载状态扩容等）是所有有状态负载的共性问题，chart 注释提醒 HA 当前依赖"单 pod + PVC + 快照 + 快速冷启动"。 - 网络边界（对应 #55–#58 的合规要求）：
network.bindAddress显式设为0.0.0.0并给出完整注释——xerj 引擎默认绑定 127.0.0.1，而 pod 网络中 kubelet 探针与 Service 都走 pod IP，因此 chart 必须显式覆盖引擎默认值；同时提供tls.enabled进程内 TLS 终结选项，避免把"明文 HTTP + pod 网络是唯一边界"留给用户自己发现。
适用前提：values.yaml 注释明确指出v0.8 仅支持单节点（replicaCount: 1），多节点集群化在 v1.x 路线图上；当前高可用策略是"单 pod + PVC + 快照 + 约 7ms 冷启动恢复"，而非多副本分片。
三、Operators 与备份恢复：多集群和 GitOps 已是基线
#12（Percona PostgreSQL Operator 2025 年度总结）概括了 Operator 用户的三条期望：用更少的人管理更多集群、满足更严格的安全合规要求、让例行的操作保持例行。#13 进一步断言"多集群与 GitOps 集成现在是基线期望，而不是高级模式"。
备份与恢复（#14–#15）是 Operator 领域 2025 年的重点战场："恢复正确性比恢复速度更重要，清晰的边界优于隐藏的自动化"；Percona 在 2025 年专门为重试逻辑买单——"生产问题总会在备份与恢复中浮现，我们增加了重试逻辑，使得瞬时网络问题或短时超时不会立即导致备份任务失败"。同目录的 kubernetes-docker-pain.md DP-56/DP-57 从另一角度印证：备份/恢复可靠性直到 2025 年仍是"未解决的痛点而非已解决的问题"，用户还期望 Operator 允许配置恢复点的 WAL 回放粒度。
安全自动化（#16、#66）记录了另一个 Operator 基线特性："自定义用户的自动密码生成和 IAM 角色支持减少了管理长期凭证的工作"。#43 则给出选型参照：CloudNativePG 已是 CNCF 孵化项目，被视为生产级 PostgreSQL 自动化的强选择。#42 列出了"生产 Postgres on K8s"的最小清单：故障处理 + 复制、至少一个备节点、以及备份/恢复/DR 的书面 runbook。
xerj 侧的对应实现：集群元数据（索引创建、region 分配等）通过自研的 Raft 共识实现 复制。该实现是"无外部 Raft 库"的最小协议实现（raft.rs，约 1100 行），文件头部明确列出了它维护的 5 条 Raft 安全性质：Election Safety（每个 term 至多一个 leader）、Leader Append-Only、Log Matching、Leader Completeness、State Machine Safety——这正对应数据点中"强一致性、无 split-brain"的用户期望，也是 #26（TiDB 在线滚动升级）、#24–#25（零停机切换）类数据点背后的共同技术底座。集群元数据在节点重启后的存活有专门的测试覆盖，例如 cluster_metadata_survives_restart.rs 与 cluster_metadata_survives_sigkill.rs，用测试用例直接验证了 #14 所强调的"恢复正确性"。
四、存算分离与对象存储后端：架构事实标准的形成
#17（StarRocks Blog / IEEE Survey，2025）是该类别的纲领性数据点："分布式数据库中将计算与存储分离的架构正在成为事实标准——Amazon Aurora、Alibaba PolarDB、Huawei GaussDB、Tencent TDSQL 都已转向这一架构"。#18 给出了动因："随着数据量和实时分析需求增长，存算耦合架构不再令人满意——独立扩展计算能力非常必要"。市场数据（#20–#21）显示云原生存储预计 2030 年达 650 亿美元（CAGR 22.2%），整体云存储市场从 2025 年的 1240 亿美元增至 2029 年的 2690 亿美元（CAGR 21.4%）。
多区域与多云（#49–#53）补充了地理维度：跨区域复制是 Google Cloud 记录在案的"客户最高频请求特性之一"；AWS 架构博客总结了客户地理复制的四个动机——低延迟读、合规、与其他服务同置、关键应用的数据冗余；跨云复制则被 TiDB 团队称为多云企业的"关键能力"；#52–#53 同时记录了反向压力——供应商锁定（尤其是 DynamoDB 类系统高昂的导出迁移成本）是选型中的头号顾虑之一，这也解释了为什么"可携带的存储格式"本身成为期望项。
xerj 的对应设计体现在两处。其一，Helm chart 将"快照 + 快速冷启动"作为单节点 HA 的官方路径（values.yaml 中replicaCount注释："对当前 HA，运行单个 pod + PVC，依赖快照 + 快速冷启动"），从源码结构看，这正是一种简化版的存算分离消费模式：索引数据以可整体搬移的持久卷/快照形式存在，计算层可快速重建。其二，xerj-cluster 中的 region 抽象把索引切分为连续键区间（[start_key, end_key)字典序，end_key为空表示无右界），为"计算节点无状态化、数据按 region 搬迁"预留了数据结构——每个Region记录leader_node、replica_nodes、size_bytes、doc_count等字段，RegionMove结构体显式建模了 region 在节点间的迁移计划。
五、自动分片与自动再平衡：把最难的架构决策自动化
#28–#32 这一组数据点勾勒出自动分片在 2025 年的成熟度：Oracle Sharding 支持无停机增删 shard 与数据再平衡（#28）；自治数据库开始用神经网络预测 shard 负载、在热点形成前触发再平衡（#29）；整体判断是"分片已从手工扩缩技术演化为 AI 驱动的云原生实践，具备预测分析与自动再平衡"（#30）；运营层面建议"定期审查键分布、shard 热点与容量阈值，并应将其自动化"（#31）。#32 同时记录了最常见的误区："团队常常期望仅靠分布式就自动获益——一个主要陷阱是假设分片能消除所有性能问题"。
xerj 在源码层面实现了对 #30–#31 的直接回应：RegionManager 管理 region 的完整生命周期——分裂、合并、初始分配、负载再平衡，四个职责写在模块文档注释中。默认阈值（Default实现，见 regions.rs 第 95–105 行）为：
| 参数 | 默认值 | 行为 |
|---|---|---|
split_threshold_bytes | 256 MiB | region 大小超过即标记为待分裂 |
split_threshold_docs | 1,000,000 文档 | 文档数超过即标记为待分裂（两条件取或） |
merge_threshold_bytes | 64 MiB | 相邻两个 region 均低于此值时合并 |
分裂点计算策略同样明确：双界非空时取字典序中点；end_key为空（无右界）时用start_key + \x80构造合成中点。with_thresholds构造器允许自定义阈值（测试用途）。这套"自动 split/merge"机制正是 #30 所述"自动化再平衡"在一个搜索/索引系统中的具体形态：用户不需要在创建索引时决定分片数量，后续由 region 管理器按阈值自动演化——注意这对应的是文档中"auto-split when data grows / auto-merge when shards are too small"的用户期望，而 #32 提醒的"分布式不等于免费性能"依然适用，阈值需要按实际负载调优。
六、零停机与韧性：停机成本驱动的硬性要求
业务影响数据（#22–#23、#62–#65）是这一类别的量化基础：中大型企业每小时 IT 停机成本超过 30 万美元（41% 认为在 100 万至 500 万美元之间）；组织平均每年故障 86 小时，100% 受访高管在过去一年经历过故障相关的收入损失；每分钟停机成本已升至全行业平均 14,056 美元、大型企业 23,750 美元（较 2014 年基线增长 150%）；但只有 20% 的高管认为组织"已完全准备好"预防或应对故障，95% 知晓运营漏洞而近半数尚未行动。
实现路径数据（#24–#26）给出了三个可复现的工程范例：某公司用 Blue-Green 部署把 PostgreSQL 大版本升级的停机从约 1 小时压到 30 秒；另一团队用逻辑复制完成 3 秒切换，所有客户端连接保持、零事务丢失；TiDB 把"零停机升级"作为核心产品特性文档化。#27 记录了用户侧心理："服务中断会把用户推向竞争对手并损害信任——高可用服务被视为默认属性"。
#63–#64（Uptime 年度故障分析、CockroachLabs State of Resilience，2025，其中后者基于 Wakefield Research 对 1000 名高管的调查）值得单独强调：它把"韧性"从技术指标翻译成了治理指标——高管层的知情-行动落差（95% 知情 / 近半数未行动）意味着产品方的责任是降低用户侧的韧性建设门槛，而不是提供更多需要专家才能调用的旋钮。xerj 侧可查证的对应物即前述快照 + 7ms 冷启动恢复路径与 Raft 元数据复制的 sigkill 存活测试；至于多副本在线再平衡的完整能力，按 values.yaml 的注释属于 v1.x 范围，本文不将其表述为当前已具备的特性。
七、可观测性、GitOps 与自动扩缩：生产 K8s 的接入契约
#33（Tasrie IT Services 2026 指南）给出了最完整的单条定义："云原生数据库以 Prometheus 格式暴露指标、支持分布式追踪、生成与集中式日志平台兼容的结构化日志——这种集成对生产 Kubernetes 环境是必需的"。#38（2025 Observability Survey）补充了主流栈构成："70% 的公司同时使用 Prometheus 与 OpenTelemetry——它们组成了'Kubernetes 可观测性栈'"。GitOps 侧，#34–#35（CNCF Blog 等）指出 Operator 通过 API 暴露供给、扩缩、备份、监控能力，从而支撑 GitOps 与基础设施即代码实践。
自动扩缩（#36–#37、#74）记录了两端的事实：Kubernetes 1.35 的 In-Place Pod Resize 特性 GA，VPA 可以不驱逐正在运行的 pod 就调整资源，"对有状态与长时运行负载是重大改进"；反面数据是"53% 的移动端用户会放弃加载超过 3 秒的站点，超过 30% 的云支出浪费在因扩缩策略不当而闲置或超配的资源上"。#74 的定性总结值得引用："Kubernetes 自动扩缩不只是加副本——你必须平衡性能、可靠性与成本这三股持续互相拉扯的力。"
xerj 的实现证据：
- Prometheus 指标：xerj-common/src/metrics.rs 使用独立
prometheus::Registry（刻意不用全局默认 registry，以便测试隔离），模块文档给出了记录索引文档计数、索引延迟并暴露 HTTP scrape 端点的完整用法示例；进程级全局句柄通过OnceLock一次性安装（set_global_metrics/global_metrics），引擎 flush/merge 管道与存储层 segment 打开路径等"早于 Server 存在"的调用点经global_metrics()记录，未安装时为 no-op——保证库调用方永不"凭空制造观测值"。指标 gauge 在 scrape 时刷新的行为由 metrics_gauges_refresh_at_scrape_time.rs 测试覆盖。 - Helm chart 接入：values.yaml 提供
metrics.enabled与metrics.serviceMonitor（默认关闭，interval: 30s）——集群安装了 Prometheus Operator 时开一个开关即可接入 ServiceMonitor，无需手写 CRD 样板，直接对接 #33 描述的"Kubernetes 可观测性栈"。 - HPA 预留：
autoscaling块默认enabled: false，预留minReplicas: 1、maxReplicas: 10、targetCPUUtilizationPercentage: 70，注释注明待自定义 HPA 指标（按查询队列深度扩缩）落地后可切换——这对应 #74 "平衡性能、可靠性与成本"中"按真实负载而非仅 CPU 扩缩"的方向，当前版本以 CPU 利用率为目标值。
八、安全与合规基线：从可选增强变为准入条件
合规类数据点在 2025 年发生了性质变化：#55 指出"SOC 2 与 GDPR 合规在选型中已成为不可协商的前置条件，北美 B2B SaaS 几乎总是把 SOC 2 放在首位"；#56 判定"静态加密在 2025 年是基线最佳实践，而非可选增强"；#58 给出具体组合——"静态 AES-256 + 传输中 TLS 1.3 正在成为 2025 年私有云 SOC 2 合规的必备项"；#57 记录了多地监管机构对金融数据库更强的身份控制与静态加密要求。
法规层面，#54 记录了EU Data Act（2025 年 9 月 12 日生效）的四个硬性要求：切换权（switching rights）、2027 年 1 月后禁止切换费、机器可读格式的数据可携带性、通过开放 API 实现技术互操作——这一条与第五节的供应商锁定数据点（#52–#53）互为因果：法规正在把"数据可携带"从产品特性提升为法律义务。
凭证管理（#16、#66）与第四章的 Operator 安全主题合流：自动密码生成 + IAM 角色是减少长期凭证的标准做法。xerj 侧可查证的对应设计是 values.yaml 中"无 values 覆盖的安装即为已认证安装"（引擎默认auth.enabled = true，管理密钥首次启动时自动生成且以 0600 权限落盘），以及tls块支持的进程内 TLS 终结；insecure: false的默认值选择则直接引用了仓库自身的用户反馈档案（user-feedback/09-security/insecure-defaults.md）作为依据——"不安全的默认值是无授权数据暴露中被引用最多的原因"。
九、AI 集成与开发者偏好：期望曲线的最新拐点
#1（InfoWorld / CDInsights，2025）是这份数据点集合的开篇断言："数据库 + 向量搜索现在是基线而非例外——用户的期望已经根本改变，他们不再只为精确结果提问"。#3 概括了 2025 年的主题迁移："从'选一个数据库'转向'构建在统一的数据与 AI 基础之上'"。#4 记录了 serverless 数据库的 2025 年被定义为"整合年"——超大规模云厂商把自动扩缩与按量付费模型同时延伸到关系型、NoSQL 与分析服务。
AI 负载的数据增长（#68，Techzine Cloud Native State 2025）："随着 LLM 与 agent 用量增加，审计与个性化数据将爆炸式增长——云端生成与存储的数据呈指数增长"。对搜索基础设施的含义是：AI 工作负载的检索入口（RAG、agent memory）与传统搜索在同一平台上竞争资源，向量/语义检索能力不再是加分项。
开发者偏好（#39–#41，2025 Stack Overflow Developer Survey，49,000+ 份来自 177 国的响应）：PostgreSQL 连续第三年同时登顶 admired（65%）与 desired（46%）榜单；Redis 因实时性能需求在 2025 年用量增长 8%，并成为 AI agent 数据存储的首选。这组数据的操作性结论是：与主流存储/数据库生态的互操作性（API 兼容、常见客户端可用）在选型中权重很高。xerj 的 Elasticsearch 兼容 API（ES-compat 9200 / 原生 REST 8080 / gRPC 8081 三个监听端口见 values.yamlservice块）即是面向这一互操作期望的工程选择。
十、成本与 FinOps：效率与速度同等重要
#69（CNCF / Cloud Native Now）："FinOps 正在崛起——云账单受到审视，效率如今与速度同等重要。" #70 转引 Gartner 预测："2025 年，缺乏适当治理的 70% 企业将超支至少 25%"。优化手段侧，#71（CAST AI / Ternary）："rightsizing——让计算实例匹配真实负载——可带来 20–40% 的成本削减且不对性能产生负面影响"；#72（FinOps Foundation State of FinOps 2025）："50% 的 FinOps 从业者表示工作负载优化与浪费削减是组织的首要任务"。#37 的"30% 云支出浪费"数据与 #74 的扩缩三角平衡（性能/可靠性/成本）共同指向同一工程问题：扩缩决策必须以负载指标为输入，而非副本数为输入。
与第六节的停机成本数据（#22、#65）合并来看，FinOps 与韧性在用户期望中是同一枚硬币的两面：为停机付费与为闲置付费都是"为错误容量付费"，xerj 的应对形态——单二进制、无 JVM 调优面（values.yaml 注释"No JVM heap to tune"）、资源默认值按 100 万至 1000 万文档规模标定并"随索引规模线性扩内存"——正是把容量决策从"专家经验"降级为"一条线性规则"。
十一、连接池与运行时细节：容易被忽略的基线项
#73（OneUptime / KubeDB，2026）记录了一个具体的生产模式："PgBouncer 作为 sidecar 容器部署在 Kubernetes 上——事务池化模式在每个事务后将服务端连接归还池，最大化连接复用。" #36（The New Stack）记录了平台能力变化："Kubernetes 1.35 的 In-Place Pod Resize 特性 GA——VPA 现在可以不驱逐运行中的 pod 就调整大小，对有状态与长时运行负载是显著改进。" 这两条数据点单独看是操作细节，合起来说明了 2025–2026 年的基线形态：连接管理交给池化 sidecar、资源调整原地进行，数据库/搜索引擎只需暴露稳定的健康与就绪信号（xerj 的/health/live、/health/ready端点即为此契约的引擎侧实现）与真实负载指标（Prometheus 指标端点）供外部控制回路消费。
十二、综合结论：75 条数据点背后的单一检查清单
把 75 条数据点按类别收敛，2025–2026 年用户评估一个云原生搜索/数据库系统的默认检查清单可以压缩为八项：
- K8s 原生部署：Helm/Operator 管理、探针完整、安全上下文收敛（#5–#7、#34–#35、#55）；
- 存算可分离：数据在廉价持久存储、计算可快速重建（#17–#21、#49–#53）；
- 自动分片/再平衡：无需建索引时做分片决策（#28–#32）；
- 强一致元数据：Raft 类共识，无 split-brain（#24–#26 背后的共同机制）；
- 备份恢复正确性优先：带重试的备份、可配置的恢复粒度（#14–#16）;
- Prometheus 指标 + 结构化日志：即插即用接入 K8s 可观测性栈（#33、#38）；
- 合规默认值：认证开启、静态/传输加密、无长期凭证（#54–#58、#66）；
- 按负载扩缩 + 成本可见：真实负载指标驱动的 HPA，效率与速度并重（#37、#69–#74）。
xerj 仓库对上述清单项的可查证实现包括：Helm chart 默认值（部署面）、自研 Raft 共识 与 region 自动分裂/合并管理器（一致性与分片面）、Prometheus 指标框架（可观测面），以及元数据 sigkill 存活等专项测试。同时应明确适用前提：当前 v0.8 版本 Helm 部署为单节点形态（replicaCount: 1，多节点在 v1.x 路线图），HPA 与 ServiceMonitor 默认关闭待自定义指标落地——这些与本文引用的数据点共同构成"期望基线 vs 当前实现"的对照，后者随版本演进。
附：关键来源与仓库内证据索引
| 主题 | 数据点来源（见文档） | 仓库内证据 |
|---|---|---|
| K8s 采用率 | CNCF Annual Survey（2026-01） | values.yaml |
| Operator/备份恢复 | Percona 2025 Wrap-Up | cluster_metadata_survives_sigkill.rs |
| 存算分离 | StarRocks/IEEE Survey 2025 | values.yaml（快照 + 冷启动路径） |
| 自动分片 | Aerospike/ProxySQL 2025 | regions.rs（256MiB/1M 文档分裂、64MiB 合并） |
| 零停机 | InstantDB/Gadget/PingCAP 2025 | raft.rs（5 条安全性质） |
| 可观测性 | Tasrie 2026/2025 Observability Survey | metrics.rs、metrics_gauges_refresh_at_scrape_time.rs |
| 合规/安全 | EU Data Act/SOC 2 系来源 | values.yaml（insecure: false、TLS、capabilities drop ALL） |
| FinOps | Gartner via CAST AI/FinOps Foundation 2025 | values.yaml（HPA 预留、线性内存规则） |
本文全部数据点引自>赞
- 人工智能
- 搜索引擎
- 本地部署
- 后端
- 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.
相关推荐
Groonga：开源的全文搜索引擎与列存储数据库
Groonga：开源的全文搜索引擎与列存储数据库 项目介绍 Groonga 是一款开源的全文搜索引擎与列存储数据库，旨在提供高效、灵活的数据检索与存储解决方案。
XERJ 向量搜索实战：dense_vector + kNN 在同一引擎内原生运行，无需外部向量数据库
XERJ 向量搜索实战：dense_vector + kNN 在同一引擎内原生运行，无需外部向量数据库 本文基于仓库中的 demo/playbooks/cast
人工智能搜索引擎本地部署后端MCP 服务CANN/asc-devkit矢量存储对齐API
asc_storealign 产品支持情况 | 产品 | 是否支持 | | : | : :| | Ascend 950PR/Ascend 950DT | √ |
人工智能深度学习算子库CANNAscend
