#优质博文 #数据库 #系统架构 #后端 #运维
探讨了传统“软删除”模式（如 archived_at 列）带来的长期复杂性，并对比分析了触发器、应用层事件和 WAL 等更优的替代方案。
对于新项目，作者优先推荐基于触发器的方案，因为它部署简单、不引入额外基建，且有效隔离了活跃数据与归档数据。
The challenges of soft delete
[以下是方便搜索索引的大纲 (AI 生成)，请读原文]
author Atlas9
探讨了传统“软删除”模式（如 archived_at 列）带来的长期复杂性，并对比分析了触发器、应用层事件和 WAL 等更优的替代方案。
对于新项目，作者优先推荐基于触发器的方案，因为它部署简单、不引入额外基建，且有效隔离了活跃数据与归档数据。
The challenges of soft delete
AI 摘要：本文深入分析了在数据库中直接使用 archived_at 字段实现软删除（Soft Delete）的弊端，指出这种做法会导致数据膨胀、索引效率下降、查询逻辑复杂化以及数据迁移困难等问题。作者对比了三种替代方案：应用层异步归档、数据库触发器（Triggers）记录 JSON 快照以及基于 WAL 的变更数据捕获（CDC）。作者认为，对于大多数新项目，使用触发器将删除的数据转移至独立的归档表是平衡简洁性与实用性的最佳选择。
[以下是方便搜索索引的大纲 (AI 生成)，请读原文]
1. 传统软删除模式的弊端
• 数据膨胀与性能损耗：99% 的已删除数据永不被读取，却占用了昂贵的存储，导致数据库备份与恢复耗时剧增。
• 查询与索引复杂化：应用代码必须在每个查询中过滤已删除记录，索引也需要额外关注这些“死数据”，增加了误读风险。
• 数据迁移（Migration）难题：旧的归档数据可能不符合新的 Schema 约束或校验规则，导致数据库迁移变得棘手。
• 恢复逻辑不一致：恢复记录往往不只是修改一个状态位，还可能涉及外部系统调用，重复编写创建逻辑容易滋生 Bug。
2. 替代方案一：应用层归档 (Application Level Archiving)
• 机制与优势：在删除记录时发送事件（Event）到消息队列（如 SQS），由另一个服务将其序列化为 JSON 并存储至 S3 等对象存储中。
• 优点：主库结构保持纯净，处理异步化提高性能。
• 缺点：增加了基础设施复杂度，且 S3 中的归档数据难以直接通过 SQL 查询进行检索
3. 替代方案二：数据库触发器 (Triggers)
• 实现方式：利用 PostgreSQL 触发器在执行 DELETE 前，将行数据转换为 JSONB 格式并插入一个通用的 archive 归档表。
• 级联删除处理：通过会话变量（Session Variable）追踪根源，记录级联删除（Cascade Delete）是由哪个父表操作引起的。
• 优势：兼具性能与灵活性，主表无冗余数据，归档表易于清理（例如清理 90 天前的数据）且仍然支持 SQL 查询。
4. 替代方案三：基于 WAL 的变更数据捕获 (CDC)
• 技术栈：利用 Debezium、Kafka 或 pgstream 等工具读取 PostgreSQL 的预写日志（WAL），过滤删除事件并流转至外部存储。
• 优势：对主库性能几乎零影响，无需修改业务逻辑或添加触发器。
• 运维挑战：需要维护复杂的 Kafka 集群；需警惕 WAL 积压（Lag）导致主库磁盘写满，需合理配置 max_slot_wal_keep_size。
author Atlas9
