生产中的向量 (vector)搜索系统很少处理静态数据集。数据持续变化：新项加入，旧项失效或被修改。在保证高查询性能和可用性的同时，维持大规模分布式向量索引的实时性和准确性带来了重大的工程难题。与传统数据库中更新和删除通常是标准操作不同，高效地修改HNSW这类复杂的ANN索引结构并非易事。
本节审视在生产向量搜索环境中管理索引更新和执行必要维护任务的常见方法及其权衡。
动态数据带来的考量
在分布式环境下，向量 (vector)的添加、删除或更新等操作需要仔细考量：
- 性能影响： 索引新数据，特别是HNSW等基于图的算法，会消耗CPU和内存资源。在提供搜索查询服务的同时执行这些操作，可能增加查询延迟或降低吞吐量 (throughput)。删除操作也可能计算成本高昂，或者随时间推移导致索引结构退化。
- 一致性： 当索引分片并进行副本处理时，更新如何传播？如何确保查询不同副本时，特别是更新或删除后不久，能看到数据的一致视图？最终一致性通常是实际可行的选择，但理解其对应用的影响很重要。
- 原子性： 向量的“更新”通常意味着先执行删除操作，再执行插入操作。确保这些操作原子性执行，尤其是在分布式系统中，可能很复杂。此过程中的失败可能导致状态不一致（例如，旧向量已删除，但新向量尚未插入）。
- 索引结构完整性： ANN索引结构，特别是基于图的结构，优化用于快速查询相对静态的数据。频繁的插入可能需要重组图的部分结构。删除操作常会带来问题；简单地从HNSW图中移除一个节点可能会破坏其他节点的导航路径。这可能导致召回率下降，或需要复杂且成本高的图修复操作。
处理索引修改的方法
存在多种处理索引变更的方法，从简单的批量处理到更精密的近实时系统。
批量更新
最简单的方法是，在一段时间内（例如，每小时或每天）累积变更（添加、删除、更新），然后批量应用它们。
- 机制： 通常涉及从更新后的数据集快照重建索引段甚至整个分片。系统在新索引版本准备好后，将查询切换到该版本。
- 优点： 相对易于实现和管理。将资源密集型索引过程与查询高峰时段隔离。在查询服务期间（批量处理窗口之外）性能可预测。
- 缺点： 数据的实时性受限于批量处理间隔；查询可能作用于潜在的陈旧数据。批量处理本身可能资源密集，需要大量的临时容量。除非使用蓝绿部署方法，否则在索引切换期间可能需要停机或可用性降低。
近实时（NRT）更新
对于要求较低数据延迟的应用，NRT更新旨在快速（几秒到几分钟）使变更可搜索。
- 插入： 大多数向量 (vector)数据库和库能够较好地处理增量插入。新向量被添加到现有索引结构中。对于HNSW，这包括寻找入口点，遍历图以寻找邻居，并连接新节点。对于IVF，向量被分配到簇，进行量化 (quantization)（如果适用），并添加到相应的倒排列表中。
- 删除： 这通常是ANN索引最麻烦的操作。
- 软删除（逻辑删除）： 向量不是立即移除，而是被标记 (token)为已删除，通常通过相关元数据中的标志。查询从ANN索引获取候选结果，然后过滤掉任何标记为已删除的项（后过滤）。如果索引结构允许在遍历期间检查标志，一些系统可能会尝试预过滤。这避免了昂贵的索引修改，但需要定期清理。
- 硬删除（物理删除）： 物理移除向量并更新索引结构。对于HNSW等图索引，由于修复图连接的复杂性，这通常效率低下或不被支持。如果处理不当，可能导致索引碎片化或搜索质量下降。基于IVF的索引可能通过从倒排列表中移除向量ID来更平稳地处理硬删除，尽管列表中仍可能发生碎片化。
- 更新： 通常按逻辑顺序处理：软删除旧向量ID，然后插入新向量数据（可能使用相同或新的ID）。这需要协调这两个操作。
下图显示了软删除后进行紧凑处理的做法。
软删除会标记待移除的向量，但不会立即改变索引结构。随后的紧凑处理或重建会移除已标记的向量并优化索引。
流式更新
这种方法将向量数据库与消息队列或事件流（例如Kafka、Pulsar）结合。变更以事件形式发布，由索引服务消费，并使用NRT技术（增量更新、软删除）应用于向量索引。
- 优点： 能够实现极低的数据延迟。与事件驱动型架构很契合。
- 缺点： 增加了系统复杂性。需要错误处理、对流式管道的监控，以及为索引消费者进行细致的容量规划。跨副本/分片的一致性管理仍是一个难题。
索引紧凑处理与重建
随着时间推移，特别是频繁的软删除和插入，ANN索引的效率可能会降低：
- 软删除会增加索引大小，并为查询增加额外开销（过滤已删除项）。
- 增量添加，特别是对于图结构，可能不总是产生全局最优的图配置。
- 内存碎片化可能发生。
定期维护对于解决这些问题有必要：
- 紧凑处理： 这个过程会移除与软删除向量 (vector)相关联的数据，并可能重新组织剩余数据以提升局部性或结构。这在采用软删除的系统中很常见。
- 重建： 从当前有效数据创建全新的索引段或分片。这通常会产生最优的结构，但比紧凑处理更消耗资源。
- 段合并： 受Cassandra或RocksDB等数据库中使用的日志结构合并树（LSM树）启发。索引由多个不可变段组成。新数据进入更小、更新的段。这些较小的段会定期在后台合并成较大的段。删除操作通过在新段中写入逻辑删除标记 (token)来处理，这些标记在合并时会使旧条目失效。查询可能需要在多个段中搜索并合并结果。这在更新性能和查询性能之间提供了良好平衡，但增加了查询路径的复杂性。
分布式环境下的维护
在多个分片和副本上执行更新和维护需要细致的协调：
- 更新路由： 确保插入、删除或更新请求根据向量 (vector)ID或相关元数据路由到正确的分片。
- 副本同步： 应用于主副本的更新必须传播到辅助副本。这可能使用同步或异步复制，影响一致性保证和写入延迟。
- 滚动维护： 为保持高可用性，紧凑处理或重建等维护操作应以滚动方式执行。一个副本/节点被轮流取出，进行更新/重建、验证，然后重新加入，再进行下一个。负载均衡器在此过程中需要感知节点的可用性。
- 监控： 监控与更新处理相关的指标很重要：更新/删除延迟、索引吞吐量 (throughput)（向量数/秒）、主辅节点间的复制滞后、磁盘/内存使用增长，以及维护操作对查询延迟和资源利用的影响。
实际考量与权衡
选择合适的更新和维护方法需要平衡多项因素：
- 数据实时性要求： 变更需要多快反映在搜索结果中？批量更新更简单，但会引入延迟。NRT/流式方法会增加复杂性，但降低延迟。
- 更新/删除速率： 写入速率非常高的系统可能更倾向于段合并或批量处理等方法，而非执行昂贵的原位修改或严重依赖需要频繁进行大型紧凑处理的软删除方法。
- 查询性能敏感度： 应用能否容忍NRT更新或维护窗口期间查询延迟的暂时增加？
- 成本： NRT和流式系统，以及滚动重建等复杂的维护操作，通常需要更复杂的架构和可能更高的运营开销。
- 向量 (vector)数据库能力： 所选的向量数据库或库明显影响可选项。有些针对静态或批量更新的索引进行优化，而另一些则对NRT更新、软/硬删除以及自动化维护（例如，后台合并或紧凑处理）提供更好支持。根据应用需求细致评估这些能力。
管理索引更新和维护是大规模运行向量搜索系统的重要组成部分。理解所选索引类型和向量数据库的底层机制，结合更新方法和维护计划的细致规划，对于构建可靠且高性能的生产系统有必要。
