向量数据库分片：HNSW为何在分区边界失效及应对策略
大多数向量数据库教程只展示如何插入百万条嵌入并运行查询。但它们不会告诉你六个月后会发生什么——当你的语料库已经超出单节点承载能力，你不得不对整个检索管道所依赖的HNSW索引进行分片时，实际情况如何。答案是：供应商在营销材料中刻意回避的事实是，HNSW图在分区方式上存在特殊阻力，会导致无声的召回率下降，而恢复这一质量所需的运营模式会带来真实的复杂性。
本文将深入探讨HNSW分片失效的技术原因、实际中召回率损失的表现，以及团队在超出单节点容量后用于维持检索精度的运营模式。
为什么HNSW无法干净地分区
HNSW（层次化可导航小世界）是大多数生产向量数据库的底层索引结构——Qdrant、Weaviate、Milvus和pgvector默认均采用此方案。该算法构建一个多层图，每个向量与少 量邻居相连，顶层提供长程遍历能力，底层实现精确的局部搜索。
HNSW的关键特性在于：邻居关系由高维空间中的位置决定，而非由你控制的任何键值或分区方案决定。一旦分布式存储了语料库，两个最近邻的向量很可能存储在不同节点上。分片时，你不得不移除跨越分片边界的边——而这些边恰恰是图用于精确搜索的核心所在。
这一后果在图分区研究的基准测试中有所体现：在分布式HNSW查询中，超过80%的搜索步骤构成跨分片边界的远程过程调用。分区后的图并非"基本可用"，而是从一个连贯的全局结构根本性地退化为若干孤立的局部图，每个局部图都误以为自己就是全貌。
还存在一种更隐蔽的失效模式：不可达节点。当HNSW图在实时更新条件下被分区时，部分向量会失去所有图内连接，对查询实际上变得不可见。研究发现，分区后连接性差的向量（即入度缺陷）占分布式场景总召回率损失的84.6%。
召回率损失的实际表现
关于召回率下降的直觉模型通常是渐进且成比例的：分片越多，结果略差。但实际模式远不如此可预测。
在严格控制的条件下——通过将向量重新分配到最近聚类来强制执行均衡分区——召回率下降幅度为0.2%至3.6%，具体取决于分区策略。这个范围看似很小，但若你在规模化场景下运行推荐系统，每1%的召回率下降都是可测量的参与度降低。
生产环境中的实际遭遇更具不连续性。性能在语料库超过某个临界点之前保持可接受——即HNSW的工作集不再适配内存时，性能会急剧下降。PipeANN和SPANN等系统在内存与索引比低于30%时根本无法运行，DiskANN在内存可用率低于20%时出现吞吐量骤降。这个悬崖并非供应商发布的基准数字所预测的——那些数字是在配置为将完整索引保留在内存中的硬件上测量的。
跨分片邻居是根本原因。当查询向量的真实最近邻分布在多个分片时，每个分片的局部HNSW搜索返回其最优局部结果——这些结果可能与全局正确答案毫无重叠。查询协调器合并的是各分片局部最优但整体错误的结果。
三种补偿性运营模式
突破单节点阈值的团队已收敛于三种模式，可部分恢复分区带来的召回质量损失。
分片感知查询路由避免了暴力散集方式（向所有分片发送查询、合并结果），通过粗粒度索引结构将查询只路由到相关分片。主流实现采用基于质心的路由：维护一个小型聚类质心索引，首先将传入查询与该索引比较，然后只搜索包含附近质心的分片。对于聚类良好的语料库，这可以将扇出从数百个分片减少到个位数。权衡在于：位于聚类边界的查询仍需多分片访问，维护质心索引增加了一个需要独立运营维护的协调层。
跨分片重排序解决了各分片HNSW图导致的排名不一致问题。每个分片返回其局部前K个候选及距离分数，协调器收集所有分片结果，合并候选列表并进行全局重排序。关键实现细节："扇出主导延迟"特性意味着最慢的分片决定查询延迟，无论其他分片响应多快。单个过载分片产生 的尾延迟比所有分片平均延迟更糟糕。重排序本身开销很小——等待最后一个分片才是P99的杀手。
分区大小监控是那个不起眼但能防止前两种模式比必要情况更频繁启用的运营模式。行业经验已收敛于每分片1000万至3000万向量为实际可行范围，4至8个分片为上限——超过此上限后工作节点间通信开销会超过并行化收益。运营上的关键点是：大多数系统创建后无法修改分片数量，因此初始分区策略成为承重墙。监控每个分片的增长速度，并在任何分片达到内存悬崖之前触发重聚类，才能让其他两种模式不必承担超出应有的工作量。
