向量索引优化：数据结构与存储格式的工程实践

1. 向量索引的本质：数据结构与存储的艺术

在传统数据库领域工作了十多年的老手们，第一次接触向量数据库时往往会陷入一个思维误区——把索引单纯理解为"算法"。这种认知偏差就像把快递分拣中心仅仅看作"分拣动作"一样片面。实际上，索引的核心价值在于其背后的数据结构设计和存储格式优化。

我清楚地记得2019年第一次调优Milvus性能时的场景。当时团队遇到一个棘手问题：在千万级向量数据集上，IVF_FLAT索引的查询延迟始终无法降到100ms以下。经过两周的源码级排查，最终发现问题出在invlists的内存布局上——原本连续的向量ID列表由于频繁更新变成了内存碎片。这个案例让我深刻认识到：索引性能的瓶颈往往不在算法复杂度，而在于数据结构的实现细节。

1.1 从算法思维到工程思维

传统算法教材通常聚焦于时间复杂度的理论分析，比如HNSW的搜索复杂度是O(log n)。但在工程实践中，以下存储细节对性能的影响可能比算法本身更大：

• 内存局部性：连续存储的向量比随机分布的向量访问速度快3-5倍（CPU缓存命中率差异）
• 数据对齐：256位AVX指令要求内存地址32字节对齐，不对齐会导致性能下降40%
• 预取策略：Knowhere在遍历HNSW图时会主动预取下一跳节点的内存

cpp复制// Faiss中典型的缓存友好设计
struct IndexIVFFlat {
  float* centroids; // 按nlist*dim连续分配
  size_t* ids;      // 向量ID连续存储
  size_t* offsets;  // 每个桶的起始位置
};

1.2 存储格式的权衡艺术

在内存与磁盘的存储格式选择上，开发者需要做多重权衡：