3.3 索引构建与动态维护

3.3 索引构建与动态维护

上一节把索引结构摆上了货架，本节处理货架背后的问题：索引是静态的雕塑，可业务数据是活的。承接 3.2 的结构与参数，本节讲构建期怎么训、增量写入怎么吸收、删除怎么记账、什么信号出现时该重建——这也是第一章案例里"大促写入毛刺"问题的正式答案。这一节的内容同时覆盖了旧版教程里"构建动态"与"动态索引管理"两个话题，因为它们本来就是同一件事的静止面与运动面。

构建期：训练与灌入是两件事

倒排系与量化系索引的构建分两步：先训练后灌入。训练阶段用采样数据学出聚类中心或码本——这一步决定了空间怎么切、向量怎么压；灌入阶段把全量向量按学好的结构安置到位。两个常见事故都在这里：训练样本不能代表整体分布（比如只用最近一个月的数据训练，老数据的簇全被挤偏），以及训练数据量不足导致码本欠拟合。稳妥做法是采样覆盖各时间段与各业务分区，样本量取聚类数数百倍以上。图索引（HNSW 系）没有独立训练步，逐点插入连边即可，但批量构建远快于逐条插入，冷启动时务必走批量通道。

图 3-2 分层图的金字塔结构与查询下沉路径

增量写入：分段的智慧

在线业务不能等全量重建，主流系统的答案是分段：新写入进一个小的可变段（内部常是图或暴力结构，可随时增删），攒到一定大小就封段并为其建完整索引；查询时同时扫所有段再合并结果。这个设计的巧妙之处在于把"建索引慢"和"写数据快"解耦——大段是不可变的，重建、压缩、合并都可以在后台对副本慢慢做；小段吸收实时流量，牺牲一点查询效率换写入的即时可见。段的合并策略（按大小分层合并）与日志结构存储异曲同工，写入毛刺由此被平滑：第一章电商案例里大促批量换图的写入洪峰，正是被新段吸收、再由后台合并慢慢消化成大段的。

对使用者，这套机制意味着两个可配置的旋钮：段大小与合并频率。段太多，查询要扫的子索引多，延迟上升；段太大，合并期间的后台资源占用会挤压在线查询。观察段的分布是向量库运维的基本功，第六章的监控清单会把它列为固定项目。

删除与更新：墓碑的账

向量数据库的删除几乎都是逻辑删除：标记墓碑，查询时跳过，物理回收留给后台合并。这里有一笔最容易失控的账——墓碑比率。图索引里被标记的点虽然不返回，但搜索路径仍会经过它，墓碑越多，无效跳跃越多，召回与延迟双双劣化；倒排结构里墓碑则让簇的统计失真。经验阈值是墓碑占比超过两到三成、或绝对量到达百万级时，安排一次重建。更新在多数实现里是删除加插入的组合：旧向量进墓碑、新向量进新段，所以高频更新业务的墓碑问题天然严重，参数上要预留更多余量。

什么时候该重建，怎么平滑地建

四类信号提示重建：分布漂移（新数据与训练分布明显不同，倒排簇失衡）、模型换代（嵌入模型升级，向量坐标系全变）、墓碑超标、以及结构参数需要调整（内存升级后想加大连接度）。平滑重建的标准做法是双索引在线切换：后台用同一份增量数据流构建新索引，构建期间旧索引继续服务，写操作双写或走变更日志补齐；新索引追平后，把流量原子地切过去，旧索引退役。整个过程业务无感，唯一要规划的是构建期的资源——全量重建的 CPU 与内存开销不小，安排在低峰并预留余量是基本素养。

# 双索引在线切换的核心步骤（伪代码）
new_idx = build_hnsw(snapshot_of_latest_data())     # 后台构建，读旧数据快照
replay_change_log(new_idx, since=snapshot_ts)        # 回放构建期间的增量变更
verify_recall(new_idx, probe_queries, expect=0.98)   # 用探针查询验证召回达标
router.switch_primary(new_idx)                       # 原子切换流量
old_idx.retire()                                     # 旧索引延迟退役留回滚余地
​

问题：全量重建期间在线查询会受影响吗？

理论上不该受影响，前提是资源隔离做得到位。重建消耗的是构建进程的 CPU 与内存，在线查询消耗的是服务进程的资源，两者若部署在同一批节点上，重建挤占内存会拖垮在线延迟。工程上的稳妥做法有三种：把重建任务调度到独立节点或低峰窗口；对重建进程设置资源上限（容器限额）；以及最简单的——在从副本上先重建，完成后再提升为主。重建期间的监控要单独看构建吞吐与在线尾延迟两条曲线，后者出现抬升就说明隔离没做干净。

问题：怎么判断分布漂移已经严重到需要重建？

用数据说话而不是凭感觉。做法是维护一份"训练分布画像"（建索引时对训练样本的簇分布、距离分布做的统计快照），定期对新增数据采样计算同样的画像并比对：新数据在旧簇心上的分配失衡度（最大簇与最小簇的负载比）、查询命中簇的集中度变化，都是可量化的漂移指标。失衡度超过阈值（比如最大簇负载超过均值三倍）再触发重建。这套画像和 6.3 的健康度监控天然是一体的，把漂移指标放进监控面板，重建就从"救火动作"变成"计划内维护"。

顺带一个容易忽略的小账户：构建与重建都会产生中间产物（临时段、构建快照），磁盘水位要把这部分算进去，重建高峰期的磁盘占用可达稳态的两倍。见过太多集群在重建夜被磁盘打满拖垮在线服务，这笔钱提前算进容量规划，比事后救火便宜得多。

一份维护节奏的参考表

把本节的动作排成日常节奏，可以直接搬进团队运维日历：每日看段分布与墓碑增量，异常增长当天查因；每周核对合并滞后与写入可见性延迟，跑一轮探针召回；每月复核容量水位与漂移画像，决定是否计划重建；每季做一次恢复演练与参数复扫（5.3 的季度例行）。节奏本身不重要，重要的是每个动作都有指标依据、每次偏离都有人接住——维护体系的生命力在于闭环，不在于排期表的整齐。

本节要点回顾

• 倒排与量化系先训练后灌入，训练样本必须覆盖真实分布。
• 分段机制把慢速建索引与快速写入解耦，写入毛刺由小段吸收、后台合并消化。
• 段大小与合并频率是可调旋钮，段分布是运维监控的固定项目。
• 删除是墓碑标记，占比过高会同时拖垮召回与延迟，两三成即应安排重建。
• 平滑重建靠双索引在线切换加变更日志回放，切换前必须用探针查询验证。

至此索引的全部静态与动态知识就位。下一章把镜头拉远：这些结构如何被装进一套可扩展、可恢复的分布式系统。