正规化（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，但根据上下文的意思，应该是数据行才更有意义。），而数据库并未准备好应对这种情形。如果你归档更老的数据，那么它是可以得到解决的。
“数据库反正规化是一种效率优化，但这应该作为最后一道防线。应该在创建数据库索引、使用 SQL 视图和实现应用特定的内存缓存之后。”
然而，Dare 认同：当你需要大规模计算时，你可能需要反正规化，并举 Flickr 为例。
正如 Cal Henderson（Flickr 的 Web 开发领导）在 2004 年关于 Flickr 架构演讲中所说的：Join 效率低下（27 页）。作为结论：
* 正规化的数据适合于胆小鬼
\* 多处保存数据的多重副本
\* 让搜索更快些
\* 必须在应用逻辑中确保一致性
一篇由 Jason Kottke 于 2004 年撰写的博文中，表露出了与 Pat 的博文和 Cal 演讲中第一点类似的观点。Jason 解释，在 Flickr 的情形中，每次 Insert/Delete 或 Update 会有 13 次 Select，这是他们为什么选择反正规化的原因。
Pat 在其介绍的结尾总结：
“人们正规化‘因为他们的教授这么说的’”
是时候反思数据库正规化的咒语了吗？一些更大的网站似乎这么认为，你的感觉呢？
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论