database · E1 预消化简报(2026-07-25)

Jay · cron_d71a4202 · 2026-07-25 20:20 CST 覆盖范围：Jul 24–25 inbox（jay/tom/flyp/spark/stephen）+ 近 3 日 paper_cards

检查过的来源一览

一、增量条目（7 条）

增量 1：向量数据库 2026 选型格局固化——pgvector ≤ 10M / Qdrant 10M–5亿 / Milvus 亿级+

来源：2026-07-25-1105-db-backend-cloudnative-inference-briefing.md（Jay）+ 2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md（Jay）综合 arXiv 引用：2606.08950（VDB HPC 扩展悖论）、2509.12384（Qdrant HPC 实测）

要点： - 10M 向量以下：pgvector 是默认最优解（已是 Postgres 生态则无脑选）；pgvectorscale 可提供 471 QPS @ 99% recall - 10M–50M：pgvectorscale 或 Qdrant（HNSW + payload 过滤强） - 50M–5 亿：Qdrant（Rust，~12ms P50，节点职责架构分离，并发隔离优于 Milvus） - 亿级+多租户：Milvus（K8s 原生分布式） - 全托管免运维：Pinecone（~10–15ms P50），成本较高 - HPC 场景扩展悖论：arXiv 2606.08950 揭示 256 workers 仅带来 5.46× 提速，证明向量 DB 在超大规模下存在扩展天花板，盲目增加节点反而可能降低吞吐

与 knowledge/database.md 现有脉络的关系： - 活文档应有"向量数据库选型"节，该增量是 2026H2 最新规模-路线对照表，可直接替换/补充"专用向量数据库 vs 数据库内建向量"路线对比 - 2606.08950 的 HPC 悖论是新增维度——此前版本未覆盖"超大规模扩展失效"现象

建议归入章节：向量数据库选型 / 第三节 2026H2 格局

增量 2：pgvector HNSW 生产参数陷阱——ef_search > 200 导致 PostgreSQL 优化器绕过索引

来源：2026-07-24-1506-db-cloud-backend-csdn.md（Jay） arXiv 引用：无直接对应，但与 2606.08950 形成互补（HPC 大规模 vs 单机生产）

要点： - HNSW ef_search 参数 > 200 后，PostgreSQL 优化器会改为 Seq Scan + Sort（365ms vs 2.5ms），完全绕过向量索引——这是生产中极易踩的坑 - m 参数在构建时一次性确定，决定图密度，影响 recall vs 内存 tradeoff - Partial Index 技巧：按分类建部分索引，体积缩小 11×，构建速度提升 20× - DiskANN（SBQ 压缩）：存储体积比 HNSW/IVFFlat 小 9×，3ms 完成 3072 维最近邻查询 - 索引体积警告：HNSW + B-tree 总体积约为数据本体 2–4.5×，高维向量场景须提前规划存储

与 knowledge/database.md 现有脉络的关系： - 活文档"pgvector 生产实践"节目前缺少 HNSW 参数陷阱数据；该条目应补充 ef_search 上限建议（≤ 200），并加入 Partial Index 和 DiskANN 新选项

建议归入章节：pgvector 生产实践 / 参数调优

增量 3：PostgreSQL-V——向量索引与存储引擎解耦，比 pgvector 快 8.9×（CIDR 2026）

来源：2026-07-24-1506-db-cloud-backend-csdn.md（Jay） arXiv 引用：2605.17152（LSM-VEC，LSM-tree + 动态向量搜索）交叉参考

要点： - pgvector 受制于 PostgreSQL 面向页的存储结构，索引效率存在天花板 - PostgreSQL-V 核心思路：向量索引完全从 PostgreSQL 存储引擎解耦，直接利用原生向量索引库（如 HNSWLib），绕过 page-oriented 开销 - 关键技术：LSM-based 索引框架 + 轻量级崩溃一致性机制（复用已有 WAL + 检查点，无需额外分布式协调） - 实验结果：与专用向量数据库（Milvus / Qdrant）性能持平；比 pgvector 快 8.9× - 路线之争里程碑：解耦架构可能是内建向量扩展的最终答案

与 knowledge/database.md 现有脉络的关系： - 该条目对应"专用向量数据库 vs 数据库内建向量"讨论，是继 2505.17152（LSM-VEC）之后又一重要数据点；解耦路线获得量化支撑（8.9×），应作为独立子议题更新

建议归入章节：向量数据库架构选型 / PostgreSQL 内建向量路线

增量 4：SIGMOD/VLDB 2026——O3-LSM（分解式内存三层层卸载）、DART（无锁 ART）、Terark-DS（KV 分离）

来源：2026-07-24-1506-db-cloud-backend-csdn.md（Jay）

要点：

O3-LSM（SIGMOD 2026，arXiv 未编号，直接 PDF）： - Purdue DASLab，分解式内存（DM）架构下的 LSM-KVS - 三层卸载策略：DM-optimized memtables + cache-enhanced read delegation + shard-level flush offloading - p99 写延迟降低 45%，吞吐量提升 38% - 适合与 TiDB/OceanBase 生产实践对比

DART（SIGMOD 2026）： - 分解式内存无锁双层哈希 ART 索引 - 双层哈希 + ART 无锁设计，CAS 替代全局锁 - 适用：高并发 OLTP + 点查 + 范围查询

Terark-DS（VLDB 2026，doi:10.14778/3796195.3796198）： - 针对 disaggregated storage 重新设计 KV 分离布局 - 冷 value 下推远程存储，热数据保留本地 NVMe cache - 存储成本降低 50%，p99 读延迟降低 30% - Artifact 可用：github.com/Terark/Terark-DS

与 knowledge/database.md 现有脉络的关系： - 活文档应有"数据库内核研究"节，O3-LSM/DART/Terark-DS 三者可组成"Disaggregation × Storage Engine"专题，与已有的 LSM-tree 内容形成延续

建议归入章节：数据库内核 / LSM × Disaggregation

增量 5：Directory-Aware Vector DB——TrieHI 打破膨胀式设计的根本局限（arXiv:2606.16903，7/25 新入库）

来源：paper_card 013-2606-16903，主分类 database，2026-07-25 入库

要点： - 现有膨胀式（expansion-based）设计的根本局限：扁平化目录结构导致 PE-Online 递归查询延迟高，两种膨胀策略在结构变更时均产生不可扩展的写放大 - TrieHI 核心设计：保留目录拓扑为原生前缀树，通过树遍历实现高效递归检索，通过拓扑节点操作降低维护成本 - 关键贡献：揭示了"膨胀式"路线的算法上限，为目录感知的向量数据库索引提供了新范式

与 knowledge/database.md 现有脉络的关系： - 该条目与"向量数据库选型"和"索引结构"节均相关；2606.16903 是 7/25 当日新卡，应作为增量最高优先级条目之一处理

建议归入章节：向量数据库索引结构 / TrieHI 目录感知路线

增量 6：vLLM MRV2——56% 吞吐提升但需显式启用（v0.20.0+，FP8 / Disagg Serving）

来源：2026-07-25-1105-db-backend-cloudnative-inference-briefing.md（Jay） arXiv 引用：2605.17613（VeriCache，KV Cache 压缩替代 EAGLE 类 draft model）

要点： - MRV2 基于 GPU-native Triton kernels + async scheduling，需显式设置 VLLM_USE_V2_MODEL_RUNNER=1 - GB200 最高 56% 吞吐提升（结果因硬件而异） - 2026 上半年关键功能：FP8 inference（H100/B200）、NGram GPU speculative decoding、Chunked Prefill（p95 改善 68%）、Disaggregated Serving（实验性）、Native RL APIs - VeriCache（arXiv:2605.17613）：压缩 KV Cache 替代 EAGLE 类 draft model，Qwen-32B 接受长度 ~19、Llama-70B ~23；比传统 speculative decoding 高一个数量级，且无损 - Prefill-Decode Disaggregation：prefill 计算 bound / decode 内存 bound，vLLM 已支持实验性分离；适合长 prompt + 短输出（RAG）或短 prompt + 长输出（代码生成）

与 knowledge/database.md 现有脉络的关系： - 活文档"推理引擎"或"LLM 基础设施"节已有 vLLM 内容；MRV2 的 56% 提升和 disaggregated serving 应作为 2026H2 重点更新条目；VeriCache（2605.17613）的 KV Cache 自压缩路线值得在数据库 × AI 推理交叉处单独成节

建议归入章节：LLM 推理优化 / vLLM 2026H1 更新 / 第四节 MRV2

增量 7：llm-d 加入 CNCF Sandbox——Kubernetes AI 基础设施编排层正式登场

来源：2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb.md（Jay）

要点： - 创始成员：Red Hat + Google Cloud + IBM Research + CoreWeave + NVIDIA；2026-03-24 正式加入 CNCF Sandbox - 使命：any model, any accelerator, any cloud——将分布式 LLM 推理作为一级云原生工作负载 - llm-d ≠ 推理引擎，是 orchestration layer，可管理 vLLM/SGLang/TensorRT-LLM 生命周期 - 核心技术：LeaderWorkerSet（LWS，多节点分布式推理标准抽象）、DisaggregatedSet operator（Mistral AI 贡献） - CNCF 2026 数据：66% 托管生成式 AI 的组织使用 K8s，82% 容器用户在生产环境运行 K8s

与 knowledge/database.md 现有脉络的关系： - 该条目属于云原生 AI 基础设施，与数据库的关联是间接的（模型权重存储：LINSTOR CSI / Model CSI Driver）；但 disaggregated serving 与数据库存储引擎的 disaggregation 趋势形成呼应，可在"云原生数据库"节补充 llm-d 生态定位

建议归入章节：云原生 AI 基础设施 / llm-d CNCF 生态

二、值得警惕的矛盾或待核实说法

三、可引用 arXiv 号列表（按编号排序）

四、增量汇总

无显著新增量时如实说明：本次共发现 7 条增量，均来自近 2 日 inbox 综合分析，无硬凑字数。paper_cards 近 3 日新卡中，013-2606-16903（TrieHI）是唯一当日入库且主分类为 database 的条目，其余新卡（476-2302-04761 等 4 张）主分类均非 database。