Milvus中删除操作后仍可查询到数据的深度分析

问题背景

在分布式向量数据库Milvus的实际使用中，我们发现了一个值得关注的现象：在执行删除操作后，部分被标记为删除的实体仍然可以通过查询接口获取到。具体表现为在并发插入和删除操作场景下，约有100条已删除ID的记录仍能被查询到。

问题复现与验证

通过详细的测试流程，我们重现了这一现象：

1. 首先创建包含三个字段的集合（id、float_vector、json_1）
2. 建立向量索引后，批量插入3000万条数据（ID范围0-3000万）
3. 执行flush、建立索引和加载操作
4. 并发执行以下操作：
   • 搜索请求（权重19）
   • 插入请求（权重16，从3000万开始随机ID）
   • 删除请求（权重15，每次删除100条）

通过对比count(*)统计结果和实际binlog扫描结果，发现存在约100条已删除记录仍可查询的异常情况。进一步分析日志发现，这些记录的删除时间戳与插入时间戳非常接近，部分甚至出现了删除操作先于插入完成的情况。

技术原理分析

Milvus的删除操作实际上是标记删除而非物理删除。当执行删除时，系统会记录删除操作的逻辑时间戳（timestamp），后续查询时会根据这些时间戳过滤掉被标记删除的记录。

在并发场景下，可能出现以下时序问题：

1. 操作时序竞争：当插入和删除操作几乎同时发生时，由于分布式系统的特性，可能出现删除操作的时间戳早于插入操作的时间戳的情况
2. 可见性延迟：新插入的数据可能还未完全同步到所有节点，而删除操作已经执行
3. 缓冲区未刷新：内存中的删除标记可能还未持久化到存储层

解决方案与优化建议

针对这一问题，我们建议采取以下措施：

1. 客户端时序控制：在应用层确保删除操作一定在相关插入操作完成后再执行
2. 服务端增强：
   • 实现更严格的操作时序检查
   • 优化删除标记的同步机制
   • 增加操作冲突检测和处理逻辑
3. 监控与告警：对删除操作的执行结果进行监控，及时发现异常情况

最佳实践

对于高并发场景下的数据操作，建议：

1. 对关键操作实现应用层的顺序控制
2. 在执行删除操作后，增加验证步骤确认删除效果
3. 考虑使用事务特性（如果Milvus版本支持）
4. 合理设置操作超时时间，避免长时间未完成的操作影响后续操作

总结

Milvus作为高性能向量数据库，在提供高吞吐量的同时，也需要用户理解其底层操作机制。删除操作的可查询异常主要源于分布式系统固有的时序问题，通过合理的应用设计和参数配置，可以有效避免此类问题。未来Milvus版本可能会进一步优化这一机制，提供更强的一致性保证。