四层树撑百亿向量，AlloyDB拆算力墙

10 亿向量逼近，老树结构撑不住了

Google AlloyDB 在 2026 年 8 月 20 日把 ScaNN 索引扩到 100 亿向量规模，官方称 p95（95% 请求不超过的延迟）≤51ms、召回率 95%。数字先放着——这一节先看它为什么要重写树的结构。

推力来自企业级 agentic AI（让 AI 自主调用工具完成多步任务的范式），它把向量库推到几十亿、上百亿条记录的体量。AlloyDB 之前的 ScaNN 索引只支持两层或三层树，再往上扩会遇到两个具体障碍：树越大，索引构建和查询遍历所需的运算量陡增；为构建索引对 100 亿向量做采样（随机抽出一部分向量用于训练树结构），内存直接被打爆。两层树的搜索复杂度是 O(N^1/2)（向量数 N 越多，扫描量按 N 的开方增长），三层是 O(N^1/3)，四层能压到 O(N^1/4)——数据量翻 10 倍，扫描量只翻不到 2 倍，这是 Google 把树从三层堆到四层的算账方式。

四层树不是简单多塞一层。Google 在新结构里同时塞进了 Top-K branch、SOAR、centroid adjustment（聚类中心微调）、balanced tree shape（均衡树形）四样东西，配合分层压缩采样集，目标是拿更小的训练样本重建出高保真度的树分区。官方在博客里强调这组数字来自内部测试（internal tests），没有给出第三方复测数据——95% 召回和 51ms p95 暂时只能视为厂商口径。

四层树，每下一层候选集砍到原来的根号

把十亿级向量塞进亚百毫秒延迟，靠的不是逐条扫描，而是让查询沿树形结构逐层下沉，每下沉一层，候选集就被砍掉一截。

向量检索绕不开一个代价：想找最像 query（用户输入的查询向量，用它去库中找最相似的条目） 的 K 条结果，传统做法是把库里的向量全比一遍。

N 越大，扫得越多，延迟越顶不住。AlloyDB ScaNN 用树形索引：先把整个向量空间切成粗粒度聚类，落到第二层再切细，第三层、第四层继续切，直到叶子节点只剩一小撮向量。查询从顶层入口进，每过一层只往与 query 更近的子节点走，扫的向量数随层数指数级收缩。

Google 给出的复杂度对照很直白：两层树 O(N^1/2)，三层树 O(N^1/3)，四层树压到 O(N^1/4)。N=100 亿时，N^1/2 是 10 万量级，N^1/4 是 562 左右。每多一层，根号下再开根号，候选集被压扁的幅度差出两个数量级。

树层不是预先固化死的。ScaNN 配了四件辅助件守住召回率（真实最近邻里被找回的比例，95% 表示 100 个真命中里找回 95 个）：Top-K branch（每层保留前 K 个分支继续往下走，避免一刀切丢路径）、SOAR（一种重排序机制，弥补树形切分带来的精度损失）、centroid adjustment（训练时微调聚类中心，让分区边界更准）、balanced tree shape（强制树形平衡，避免某支长得过胖导致单支扫不完）。十亿级向量训练一次要采样海量样本，内存扛不住，所以必须用更小的采样集配合平衡结构来重建高质量分区。

复杂度公式来自 Google Cloud 博客原文（2026 年 8 月 20 日发布）。N=100 亿跑出 ≤51ms p95 延迟、95% 召回，是 Google 内部测试口径，第三方复测还没见到。这层不确定性先挂着。

多一层树，反而更可能砍掉正确答案

把树从三层加到四层，本意是把搜索量从 N 的 3 次方根压到 4 次方根。结果走向反了：分得越细，每层可选分支越少，正确答案被提前剪掉的风险反而拉高。ScaNN 靠四件补丁把召回率顶回 95%。

多层树的做法是粗筛再细筛：每一层只看几个候选分支，剩下的一刀切掉，省计算。层数越多，搜索空间 O(N 的 1/4 次方) 越窄，速度越快；剪枝时手也越狠，错杀正确答案的概率跟着涨。

Google 工程师没在博客里明说多一层就多一层精度损失，但「Top-K branch、SOAR、centroid adjustment、balanced tree shape」四件套的存在本身把这个假设摆到了台面上。

第一个补丁叫 Top-K branch。普通做法是每层只挑最像的那一条分支往下走；Top-K 改成每层留 K 条候选分支一起走，搜索量涨一点，漏网之鱼少一截。

第二个是 SOAR，原文写的是「在多个质心之间重新分配的兜底机制」：当某个向量正好卡在两个聚类中心的边界上，硬分给哪边都会丢，于是让它同时被两条分支考虑，等于上了一道保险。

第三个是 centroid adjustment，聚类中心建出来以后继续迭代修正位置，把分错的边界往对的方向挪。最后一个是 balanced tree shape，防止某层分支过胖或过瘦——胖的层扫描慢，瘦的层剪枝狠，平衡下来整体延迟才稳。

这也解释了 Google 为什么把四件套和四层树绑在一起发：单看四层树只是工程优化，绑上四个补丁才构成一套完整的精度修复方案。95% 召回、p95 51ms 来自 Google 内部测试，第三方还没复测；这套精度在别人的数据上能不能站住，是另一个问题。

四层树之后，新难题摆上桌

Google 用四层树同时压低了采样阶段的内存占用和搜索时的计算量。索引建好之后，运维、第三方验证、对照标准变成新的考题。

两条可验证的结论，都来自官方那组数字。前提是「四层树 + 平衡结构 + 压缩采样集」三件套配合，缺一不可。

什么时候才算出这条路走通了？等出现独立基准复测、且复测里也跑出与官方数据量级一致的数字。反过来，如果复测里召回掉得比官方低一截、延迟涨得明显，说明四层树的代价被低估了。

另一个观察点是「压缩采样集」的触发频率。信源只说内存告急时系统会生成这份压缩版，阈值、压缩比、压缩后精度损失都没披露。后续如果 Google 在更新里给出具体的触发条件和误差范围，说明这套机制在工程上已经稳定；长期只字未提，意味着它还属于兜底方案，不能当成默认承诺。

生态上可以观察两件事。ScaNN 这次被装进 AlloyDB，相当于把 Google 自家的向量检索算法跟托管 PostgreSQL 绑在一起。一是 ScaNN 索引是否会以独立形式开放给 BigQuery 或其他非 AlloyDB 客户使用；二是 AWS Aurora、Azure Database 是否会推出对标的多层树方案。任意一个出现，说明「四层树」正在变成行业默认设计；都不出现，它暂时只是 Google 单一产品线的内部选择。

成本还没披露。这个规模的索引跑在云上，内存、CPU、存储三笔费用都会膨胀。官方只在结尾把读者引向 30 天免费试用和快速上手文档。后续如果 Google 把对应规模的 AlloyDB 实例价格摆到台面上、或者给出每千次查询的计费明细，才能判断这套架构在企业预算里是奢侈品还是日用品。

先把账算清，再决定要不要试

官方的数字是自测，下面这些动作帮你等复测、挤水分。

第一步是看懂一个关键区别。记住官方三个数字是绑定关系：100亿向量、95%召回、p95 51ms挂在同一句话里，意味着Google是按95%召回率为门槛来报延迟的，不是按100%。这在向量检索里是常见做法，但读者容易把两者混着看。厂商自测，没有第三方在同等硬件、同等数据集上跑过同一组指标，所以现在直接信这一组数字有风险。

如果你已经在用AlloyDB，最直接的验证路径是跟官方quickstart文档，确认四层树索引如何开启。等第三方独立基准出来，对比量级是否一致——几十毫秒级就算站得住，几百毫秒级就说明你的场景可能需要调整。

新用户可以从30天免费试用起步，先别承诺生产环境。原文没有给出quickstart的具体URL、试用条款细节或定价，把这些留给读者自己去官方页面查。

还有一类动作，现在只能观察，没法动手。原文把四层树标成preview，意味着还在早期，行为和定价可能再变。盯AlloyDB的发布说明和changelog，等preview标签去掉、GA之后再做生产决策，是更稳妥的路径。

ScaNN作为一种近似最近邻索引（允许少量误差以换取速度的索引结构），在preview阶段出现API变更、参数调整、性能波动都不意外。

最后留一个判断题给你自己：如果你的业务实际只有几百万到几千万向量，三层树已经够用，那四层树对你的延迟改善大概率是看不出来的——这时候迁移成本会比收益更扎手。100亿这个量级，是给真正撞到天花板的人准备的。