The challenges of soft delete
4 months ago
- #postgresql
- #database
- #soft-delete
- 软删除的实现方式（如使用`deleted`布尔标记或`archived_at`时间戳）能恢复误删数据，但会增加系统复杂度
- 大多数归档数据永不访问，若无保留策略约束会导致数据库膨胀，产生大量无效数据行
- 大量归档数据会拖慢备份恢复速度，使灾难恢复流程复杂化
- 查询、索引和迁移操作都需过滤归档数据，显著增加实现复杂度
- 恢复归档记录并非总是直截了当，可能需根据当前业务规则重新验证数据有效性
- 除`archived_at`外，还可采用应用级事件归档、触发器归档或基于WAL日志的变更数据捕获(CDC)
- 应用级归档能简化主库结构，但存在数据丢失风险且需额外基础设施支持
- 触发器归档将删除数据转移至副表，保持主表整洁，简化查询和迁移操作
- 基于WAL的CDC方案（如Debezium）无需修改应用即可捕获变更，但大幅增加运维复杂度
- 创新方案是搭建忽略DELETE操作的PostgreSQL副本，但可能引发模式迁移问题并提高成本
- 对新项目推荐采用触发器方案，因其实现简单且基础设施需求最低