关于数据库冗余字段

关于数据库冗余字段

2011-10-13 星期四 阴雨

原则:
1. 不要随便作冗余!
2. 冗余的字段千万不要随便暴露出去!
3. 要冗余也要冗余有业务关系的字段!
最后一点——还是不要随便作冗余!

冗余就像缓存,对于只读字段,那么冗余是没有问题的。但是如果这个字段是会被更新的,那么冗余就有可能带来更新的性能下降,和不一致的情况。特别是如果冗余在一个大表中,这带来的压力是非常大的。一个具体例子就是我们产品表和BuyOffer表中的create_type和is_validate字段的冗余。这两个字段其实是冗余自vaccount表的stage和status。目的是为了避免关联vaccount表来获取这两个字段的信息。但是它绝对是一个失败的冗余。首先:
1. 冗余不完全:vaccount表最重要的三个字段:service_type,stage和status。这里只冗余了stage和status,而忽略了service_type,这导致其实在95%场景下都是需要根据product表中的company_id多查询一下vaccount表。
2. 冗余在大表:vaccount是一个小表,根据主键关联或者查询并不会带来多大的性能消耗,而product是一张大表,这导致在CRM拉上拉下一个会员的时候,更新vaccount的同时,也需要更新product和buy_offer表的这两个冗余字段。这就带来了很大的数据库压力。再加上我们现在前后台分库之后,给数据库同步也带来了很大的压力(国际站还有特有的中美同步),还有复杂的补偿逻辑。而在业务逻辑上,本来拉上拉下一个会员,从业务上应该与这个会员的产品和buyOffer一点关系都没有。现在,由于这两个字段的冗余,导致了这个会员拥有的产品、Offer、Column等都需要牵扯进来。
3. 冗余字段与product没有直接的业务关系:将一个业务模型的关键字段冗余到另一个业务模型上,并且在上层DO中暴露出来,这明显是混淆了业务模型。因为将冗余字段放在productDO中,明显就是认为isValidate和createType是product的一个属性,而不会认为它是一个vaccount的冗余字段。所以如果要合理的话,应该将这两个冗余字段放在productDO的一个Vaccount属性中,而不是散落在productDO中。这就是业务模型和数据库模型的区别。

另一个例子是company表的is_pass_av字段,这个字段比product的isValidate和createType字段冗余有意义的多,因为是否通过AV认证确实就是公司的一个属性,将这个属性放在业务模型中是绝对没有问题的。但是为什么还是说他是一个冗余字段呢?因为在数据库层面上,这个字段的值是由诚信团队回填到company表的,也就是说它是来自于AV相关的表。由于是回填,所以也会出现不一致的现象,不过由于company和AV认证表是一对一的关系,所以没有前面提高的更新压力情况。也就是说isPassAV属性放在company业务模型是正确的,但是是否要对应在数据库模型中,也就是company表,是有待商榷的。

补记:2011-6-13

这两个冗余字段,除了带来很高的数据库和同步压力,以及巨大的维护成本之外,还容易导致问题。

周末小强打电话给王小雪,说数据库load很高,锁表严重。小雪和我一起查看了log日志,发现同一家公司的所有产品在同一个时间相续被更新了多次(大概相隔3秒做一次),就周末两天大概就有10多家公司被拉下,其中有家公司有3万多条产品。原因应该是分久必合项目将本地接口改成dubbo远程服务,而默认超时时间太短,导致超时抛出异常,dubbo或者后面的业务代码(具体是哪个麻烦李鼎和王兴勇帮忙查找一下)进行了重试导致。


再补记2011-7-15:

后来,本人实在看不下去了,将这两个冗余字段下线了(前后花了一年多的时间,背了一个B类和C类故障。。),整个世界清静很多。

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭