Pinecone 的删除工程：如何安全清理数十亿向量对象

在分布式系统中，删除数据比写入数据更难。

这听起来反直觉，但 Pinecone 的工程团队用一篇技术博客揭示了一个残酷现实：当你每天处理数十亿个向量对象时，"垃圾回收"会成为基础设施账单上最大的开销之一。

他们把这个系统命名为 Janitor（清洁工）。

不可变存储的双刃剑

Pinecone 的数据平面基于不可变对象存储（immutable blob storage）。这个设计选择带来了显著的好处：

• 写入路径简单：每次写入都生成新文件，而非修改现有文件
• 天然支持版本控制：历史数据自动保留
• 崩溃恢复容易：没有部分写入的状态需要处理

但代价同样明显：旧版本数据永远不会自动消失。

每次向量更新都会产生一个新文件，旧文件变成"垃圾"。更糟糕的是，如果写入节点在提交元数据前崩溃，文件会变成"孤儿"——存在于存储中，但对系统完全不可见。

这就是 Pinecone 团队所说的 "删除税"（deletion tax）：你不再需要的数据，变成了无法停止支付的成本。

为什么删除这么难？

在单节点数据库中，删除很简单：检查引用计数，归零就删。但在分布式系统中，删除是一条漫长的链条：

写入节点 → 元数据服务 → 缓存层 → 读取节点 → 对象存储

每个环节都有自己的状态，每个环节都可能失败。最大的挑战是传播延迟：当你删除一个对象时，怎么确保所有可能引用它的地方都已经更新？

删得太早，读取节点可能还在服务来自该对象的查询；删得太晚，存储成本持续累积。

Janitor 的三模式设计

Pinecone 没有试图用单一方案解决所有删除问题，而是将删除分为三种模式，每种有独立的策略和风险 profile：

1. 正常模式（Normal Mode）

处理日常积累的过时文件——已被新版本取代、不再被元数据引用的对象。

• 频率：每 4 小时执行分片级清理，每周执行全量扫描
• 风险：缓存中可能仍保留对旧文件的引用
• 策略：保守的延迟删除，确保引用过期后才执行

2. 孤儿模式（Orphan Mode）

处理更棘手的问题：系统根本不知道存在的文件。

场景：写入节点成功写入 blob，但在提交元数据前崩溃。文件存在于存储中，但没有任何元数据指向它。

• 频率：每月全量扫描
• 方法：从对象存储反向扫描，验证每个对象是否可达
• 挑战：孤儿文件对系统完全不可见，必须通过反向扫描发现

3. 客户删除模式（Customer Deletion Mode）

最敏感的操作：客户主动删除索引或命名空间。

客户的期望是"数据立即且不可逆地消失"，但"立即"和"不可逆"本身就是矛盾的。Pinecone 的做法是：

• 立即从元数据中移除引用（客户视角：已删除）
• 异步执行物理删除（系统视角：待清理）
• 保留审计日志（合规视角：可追溯）

核心协议：识别 → 验证 → 执行

Janitor 的核心是一个三步协议：

识别（Identify）：找出候选删除对象

• 扫描元数据，找出不再被引用的文件
• 记录对象 ID、最后访问时间、引用路径

验证（Verify）：确保安全删除

• 交叉检查缓存状态
• 确认读取节点不再使用该对象
• 验证对象确实不可达

执行（Execute）：物理删除并审计

• 执行删除操作
• 记录删除日志
• 监控存储成本变化

这个协议的关键是验证阶段。Pinecone 发现，大多数删除事故都发生在"识别"和"执行"之间缺少充分的验证。

工程权衡的艺术

Janitor 的设计体现了分布式系统工程的几个核心原则：

1. 没有完美的删除策略

只有适合特定场景的策略。正常模式、孤儿模式、客户删除模式，每种都有其适用边界。

2. 延迟是友非敌

在删除场景中，适当的延迟比过早删除更安全。Pinecone 的 4 小时清理周期，是对"存储成本"和"数据安全"的权衡。

3. 可观测性优先

Janitor 的每个操作都有详细的审计日志。不是出于合规要求，而是因为"你无法优化无法观测的东西"。

4. 成本驱动设计

Janitor 的诞生不是因为技术债务，而是因为存储成本。工程决策最终要回归商业现实。

对向量数据库的启示

Pinecone 的删除工程实践，对构建大规模向量检索系统有重要借鉴：

向量数据的特殊性：

• 高维向量占用存储大（768 维 × 4 字节 = 3KB/向量）
• 更新频繁（RAG 场景下文档持续更新）
• 索引结构复杂（HNSW、IVF 等需要重建）

这些因素使得向量数据的"删除税"比普通数据库更高。

工程建议：

1. 设计时考虑删除：不要事后补救，删除策略应该在架构设计阶段就确定
2. 分离逻辑删除和物理删除：给客户"立即删除"的体验，给系统"延迟清理"的空间
3. 投资可观测性：删除操作的审计日志，是排查数据丢失问题的关键
4. 定期评估存储成本：垃圾数据是沉默的成本杀手

结语

Pinecone 的 Janitor 系统告诉我们：在分布式系统中，最简单的操作往往最复杂。

写入数据是原子操作，删除数据是协调问题。当我们设计系统时，很容易关注"如何存储数据"，而忽视"如何安全地删除数据"。

但正如 Pinecone 团队所发现的：你不再需要的那些数据，最终会成为你无法忽视的成本。

在数据基础设施中，删除不是功能的缺失，而是设计的体现。

当系统能够优雅地处理数据的消亡，它才真正具备了承载数据生命周期的能力。

来源: Pinecone Engineering Blog (March 5, 2026)
标题: Garbage Day: How Pinecone Safely Deletes Billions of Objects at Scale
技术要点: 不可变存储、垃圾回收、分布式删除、成本优化