场景和需求
方案
请问各位大神,两种方案哪个好?或者是否有其他更优方案?
1
whx20202 2017-11-14 11:35:39 +08:00
我是搞 openstack 的。目前我司就是第一种方案,加了一个 deleted 字段
然后每天运行定时任务,把 deleted 为真的,转移到 shadow_原表名中 shadow 系的表,每天也运行定时任务,超过很久的就删除 有好有坏吧 一个重大的坏处就是查询时候, 动不动就得加上 deleted=0,然后大部分都是没删的么,优化器在索引上就吃了很多亏 |
2
master13 2017-11-14 11:37:41 +08:00
拍脑袋一想当然是加一个字段。但是严谨点也要具体看应用场景,比如你这个表记录巨多(比如>1 亿条),并且索引下也不是很效率;再比如你这个表特别稀疏等等……这种特殊场景下,应该有更好的选择。
|
4
whx20202 2017-11-14 11:44:07 +08:00
@alvy 删除的时候就插入备份表肯定是有影响的,不过按我理解影响没那么大
有的人在触发器里面做,有的人在代码事务里面做,有不少的区别,但也都是小点 如果你们删除(删除 + 转移添加)时延要求苛刻,而且还高并发,那就得权衡一下了 |
5
whypool 2017-11-14 11:47:19 +08:00
现有数据表的设计都不会物理删除,只是逻辑删除;
已经标记删除是数据定期备份,比如一季度或者一个月,这个看数据量; 至于性能,如果要求高可以上缓存 |
6
crazyneo 2017-11-14 11:49:14 +08:00 1
绝大部分金融行业数据库相关系统早就有过完整的解决方案了,不要拍脑袋学什么 NoSQL 搞什么 tombstone 之类,就是交易日志表两张每天切换,历史表若干张保存 180 天,自己写个或者用开源的数据迁移工具在闲时对闲联机日志表按日期进行转移,如果有关联交易就注意下日切问题同时查联机表和历史表,历史表对超过 180 天的数据就通过数据整理规约进数据仓库,最后对两年以上的交易上磁带,频率大概是 2-3 天一次。
|
10
lusyoe 2017-11-14 13:52:52 +08:00 via iPhone
加字段,加个视图判断字段即可
|
11
owenliang 2017-11-14 15:02:02 +08:00
用软删除最大的问题就是查询效率更差了,走其他索引过滤 deleted 字段,如果删除量很大,那么查询效率肯定很 low,是个矛盾。
|
12
openbsd 2017-11-14 18:02:38 +08:00
这个问题很常见啊,个人观点
表里行数少(忘了数据来自哪<500W 行)话,第一个方法即可,简单粗暴 >一亿行的,你会发现第二种方法会好很多 |