数据正规化真的那么好吗?

  • Arnon Rotem-Gal-Oz
  • 胡键

2007 年 8 月 15 日

话题:数据库架构DevOps语言 & 开发

正规化(Normalization)是数据库设计的基础之一。最近,关于正规化的一些讨论中正在形成一种观点,即将反正规化(Denormalization)作为一种更具伸缩性的解决方案。

几星期前,Pat Helland 在其博客给出一个简短介绍,称“正规化适合于胆小鬼”。Pat 一开始就声称(很明显)我们正规化是为了避免更新异常,但接下来做出了一系列有趣的短评:

  • 许多类型的计算问题本质上是只增(Append-Only)的,用他的话来说是“会计不使用橡皮擦”。因此,对于不变的数据没有必要去进行正规化(除非你真的需要那些空间)。
  • 开发者使用“完整的”业务对象来工作。这些业务对象总是反正规化的完整视图。

作为另一个博客,你可以很容易驳回 Pat 的言论——除非你注意到 Pat 有与数据库系统长期为伍的经历,这包括,如作为 SQL Server Service Broker 的首席架构师、COM+ 团队的奠基人之一。Pat 还花了几年时间为 Amazon 工作——并且 Werner Vogels(Amazon 的 CTO)确实提过可以考虑反正规化实体,以得到更好的伸缩性和效率。这些言论是他在 QCon 上关于可用性和一致性(最近发布于此)的演讲中提及的。

Andres Aguiar 评论说,除了“无需正规化不变数据”,你甚至都不需要删除数据:

另一个想法是,你事实上都不需要删除 / 更新数据库。“删除”一行意味着设置 InvalidationTimestamp = now(),更新一行意味着设置 InvalidationTimestamp = now() 的同时新增一行,使其 SinceTimestamp= now() 且 InvalidationTimestamp = null(你实际上需要两组日期,这将在另一篇帖子里讨论)。现在,如果你把两个想法合在一起,那么所有的数据都是不变的,所以你不需要正规化任何东西。

通过分析这一点,Andres 提到一个障碍:这种情形下会使每张表产生大量数据行(译注:原文是 column,但根据上下文的意思,应该是数据行才更有意义。),而数据库并未准备好应对这种情形。如果你归档更老的数据,那么它是可以得到解决的。

Dare Obasanjo 认为

“数据库反正规化是一种效率优化,但这应该作为最后一道防线。应该在创建数据库索引、使用 SQL 视图和实现应用特定的内存缓存之后。”

然而,Dare 认同:当你需要大规模计算时,你可能需要反正规化,并举 Flickr 为例。

正如 Cal Henderson(Flickr 的 Web 开发领导)在 2004 年关于Flickr 架构演讲中所说的:Join 效率低下(27 页)。作为结论:

* 正规化的数据适合于胆小鬼

* 多处保存数据的多重副本

* 让搜索更快些

* 必须在应用逻辑中确保一致性

一篇由 Jason Kottke 于 2004 年撰写的博文中,表露出了与 Pat 的博文和 Cal 演讲中第一点类似的观点。Jason 解释,在 Flickr 的情形中,每次 Insert/Delete 或 Update 会有 13 次 Select,这是他们为什么选择反正规化的原因。

Pat 在其介绍的结尾总结:

“人们正规化‘因为他们的教授这么说的’”

是时候反思数据库正规化的咒语了吗?一些更大的网站似乎这么认为,你的感觉呢?

查看英文原文:Data normalization, is it really that good?

数据库架构DevOps语言 & 开发