上一篇
非关系型数据库为什么会有重复数据，怎么办？
重复数据产生的原因
- 写入缺乏唯一性约束：非关系型数据库（NoSQL）设计上常放弃强约束以换取性能,同一字段可能重复插入。
- 分布式与多副本机制：在分片或副本环境下，网络延迟、客户端重试等可能导致数据重复写入不同节点。
- 数据迁移与同步：从其他系统导入时，未做去重处理，或CDC（变更数据捕获）产生重复事件。
- 应用层逻辑缺陷：业务代码未校验唯一性,在并发写入时产生重复记录。
重复数据的影响
- 存储浪费：重复记录占用额外磁盘空间,增加存储成本。
- 查询性能下降：索引膨胀，扫描行数增多,响应变慢。
- 数据不一致：聚合计算（如求和、计数）结果偏离真实值,业务逻辑出错。
- 维护成本高：清理重复数据需要额外开发与定期执行任务。
处理重复数据的方法
利用数据库内置唯一性机制
| 数据库类型 | 常用方案 | 说明 |
|---|---|---|
| MongoDB | 创建唯一索引（unique: true） | 对需要保证唯一的字段设置索引，插入重复时抛出错误 |
| Redis | 使用 SET 或 HyperLogLog | SET 天然去重，HyperLogLog 用于近似去重计数 |
| Cassandra | 主键定义重复策略（PRIMARY KEY） | 相同主键的写入为 upsert 行为，但其余列可能部分更新 |
| HBase | 利用行键唯一性 | 行键相同则数据覆盖，需在应用层设计行键规则 |
注意：唯一索引不能完全防止分布式下的重复插入（如客户端重试）,需结合幂等性设计。
应用层去重
- 幂等性写入：在写入前查询校验，或使用请求唯一标识在数据库层级判断（如MongoDB的findAndModify配合条件）。
- 批量去重：使用map-reduce或aggregate管道处理已有数据，通过分组、去重后重新写入新集合。
- Bloom Filter 或位图：在应用层快速判断是否存在,减少重复写入概率。
定期清理与维护
- 定时任务扫描：按业务规则（如时间戳、版本号）删除重复数据,保留最新一条。
- TTL（生存时间）：对临时数据设置过期自动删除,减少长期重复堆积。
- 数据归档：将重复数据迁移至冷存储或日志系统,主存储只保留唯一版本。
架构设计规避
- 使用消息队列实现异步写入,确保消费端做幂等处理。
- 采用事件溯源模式,通过事件版本号鉴别重复。
- 设计复合主键或唯一约束时充分考虑业务语义,避免自然键重复。
不同场景下的去重实践
| 场景 | 推荐方案 |
|---|---|
| 用户注册（邮箱唯一） | 写入前检查 + 唯一索引 + 应用层异常捕获 |
| 日志采集（允许少量重复） | 应用层布隆过滤器 + 定期批量去重 |
| 分布式计数器（精确去重） | Redis 的 SET 或 CRDT（无冲突数据类型） |
| 时序数据库（相同时间戳取最后值） | 使用时间戳加设备ID作为复合主键，启用 upsert |
相关问题与解答
问题1：非关系型数据库能否完全避免重复数据？
解答：不能完全避免，NoSQL 的设计哲学是牺牲强一致性以换取可用性和分区容错性（CAP理论），即使设置了唯一索引，在分布式网络分区、客户端重试等情况下仍可能产生重复，通常需要结合应用层幂等性、请求唯一ID（如雪花ID）和定期清理来综合控制,将重复率降到可接受范围。
问题2：如果已经存在大量重复数据，如何高效去重？
解答：对于大量重复数据,建议按以下步骤处理：
- 分析重复模式：通过聚合查询找出重复字段的组合（如MongoDB的$group + $count）。
- 分批删除或迁移：使用游标或分页扫描，不要一次性加载所有数据；将唯一记录写入新集合，再用rename替换旧集合。
- 利用原子操作：如MongoDB的deleteMany配合$sort保留最新文档，或Cassandra的DELETE ... WHERE ...。
- 建立索引：去重后立即创建唯一索引防止未来重复。
- 验证与监控：去重后检查数据完整性,并部署监控告警。
