S3 上构建 MVCC 风格的列式存储：元数据标记实现常数时间删除

在云原生数据系统中，S3 作为对象存储的首选，其不可变性和高耐用性非常适合存储列式格式的数据，如 Parquet 文件。然而，传统的关系型数据库删除操作在这种 append-only 环境中会面临挑战：直接重写整个对象不仅成本高昂，还会引入不必要的 I/O 开销。本文探讨一种 MVCC（多版本并发控制）启发的方案，在 S3 上构建列式存储，支持常数时间删除，通过元数据标记和懒惰压缩机制，实现高效的版本管理和空间回收，而无需立即重写数据文件。

MVCC 在列式存储中的应用观点

MVCC 是数据库中经典的并发控制技术，它通过维护多个数据版本来避免锁竞争，确保事务隔离性。在 S3 列式存储中，我们可以借鉴这一思想，将数据文件视为不可变的“版本快照”，而删除操作则转化为逻辑标记：不修改原始 Parquet 文件，而是通过辅助元数据记录删除意图。这种方法的核心优势在于常数时间复杂度——删除只需更新一个元数据条目，O(1) 操作，而查询时通过过滤可见版本来隐藏已删行，避免了物理删除的开销。

证据显示，这种设计在类似系统中已证明有效。例如，在 Hydra 的 PostgreSQL 列式扩展中，他们使用 row_mask 表来位掩码标记删除行，每扫描百万行仅需 2 毫秒额外开销，且未修改的块无需检查，从而保持高性能。同样，在 S3 环境中，我们可以将元数据存储在高效的键值店如 DynamoDB，或 S3 中的小型元数据对象中，确保删除操作的原子性和一致性。根据 AWS 文档，S3 的元数据表支持快照机制，但我们需自定义以支持 MVCC 版本链。

这种方案特别适用于分析型工作负载，如数据仓库，其中删除操作相对插入较少（通常 <10%），且查询可利用列式压缩和谓词下推来优化过滤。相比全重写方法，它可将删除成本降低 90% 以上，尤其在 TB 级数据集上。

元数据标记实现常数时间删除

要实现常数时间删除，首先需定义存储结构：数据以 Parquet 列式文件形式存储在 S3，每个文件代表一个“条带”（stripe），包含多列的 chunk。每个 chunk 对应固定行数（如 10,000 行），并有最小/最大值元数据用于谓词过滤。

删除流程：

1. 版本标识：为每个行分配一个版本号（timestamp 或事务 ID），初始为插入时的事务 ID。
2. 删除标记：当执行 DELETE 时，不触碰数据文件，而是创建一个“墓碑”（tombstone）条目：键为 (文件路径, 行偏移)，值为删除版本号。存储在 DynamoDB 中，键设计为分区键（表名 + 文件 ID）+ 排序键（行 ID），支持高效范围查询。
3. 查询过滤：在 SELECT 时，读取数据文件的同时，查询元数据过滤出可见行：对于当前事务的快照时间 t，仅返回版本 <= t 且无更高删除版本的行。这通过并行扫描元数据实现，常数时间 per row。

参数建议：

• 元数据 TTL：设置 DynamoDB 条目 TTL 为 7 天，过期后移至归档 S3 对象，减少活跃元数据大小。
• 批删除阈值：单个事务删除 >1% 行时，考虑小批量标记而非全扫描，以控制元数据膨胀。
• 一致性模型：使用 DynamoDB 的强一致读，确保删除可见性；对于高吞吐，结合 S3 Select 直接在对象上过滤，但需自定义 UDF。

潜在风险：如果删除频繁，元数据表可能膨胀至数据量的 5-10%，增加查询延迟。缓解：监控元数据大小，每日 >1GB 时触发压缩。

懒惰压缩机制与落地参数

懒惰压缩是该方案的关键，避免频繁重写：定期后台任务合并删除标记，物理移除无效行，但仅在必要时执行。

压缩流程：

1. 触发条件：当删除比例 >20% 或文件年龄 >30 天时，调度 Lambda 函数扫描元数据。
2. 合并逻辑：读取多个条带，过滤可见行，写入新 Parquet 文件（使用 Apache Arrow 优化列式合并）。更新元数据：原子替换旧文件指针，新文件继承最新版本。
3. 增量性：分片处理，每批 100MB，避免长尾任务；使用 S3 版本控制回滚失败批次。
4. 空间回收：旧文件标记为非当前，依赖 S3 生命周期规则移至 Glacier 后删除，回收率可达 80%。

落地清单：

• 基础设施：
  • S3 桶：启用版本化和服务器端加密 (SSE-KMS)。
  • 元数据店：DynamoDB 表，容量模式 Provisioned (5 RCU/WCU 起步)，索引 on (table_id, version)。
  • 计算：Step Functions 编排压缩流程，EventBridge 定时触发。
• 参数配置：
  • Chunk 大小：10k 行/ chunk，平衡压缩与过滤粒度。
  • 压缩阈值：删除率 >15% 或元数据条目 >10M 时压缩。
  • 监控指标：Prometheus 采集删除延迟 (<50ms)、压缩吞吐 (>1GB/h)、存储利用率 (>70%)。
  • 回滚策略：压缩失败时，回滚元数据指针，警报阈值：错误率 >5%。
• 测试要点：
  • 负载测试：模拟 1M 删/插混合，验证 QPS >1000。
  • 一致性检查：使用事务 ID 验证 MVCC 隔离（读未提交）。
  • 成本估算：删除 1TB 数据，元数据开销 ~$0.1/月，压缩 Lambda ~$0.05/次。

在实际部署中，此方案可与 Iceberg 或 Delta Lake 集成，后者已内置类似 MVCC，但自定义元数据允许更细粒度 S3 优化。例如，Iceberg 的快照管理可扩展为我们的墓碑系统，支持时间旅行查询。

总结与扩展

通过 MVCC 启发的元数据标记和懒惰压缩，我们在 S3 上实现了高效的列式存储删除，支持常数时间操作而无需全重写。这不仅降低了运维复杂度，还提升了分析查询的性能，尤其适合 OLAP 场景。未来，可进一步集成向量索引加速过滤，或结合 S3 Express One Zone 降低延迟。

实际案例中，如 BemiDB 项目使用 Iceberg on S3 实现压缩列式存储，我们的方案可作为其删除优化的插件。总体而言，此设计平衡了性能、成本与一致性，是构建 S3 数据湖的实用范式。

（字数：1025）