大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
数据正规化真的那么好吗？
作者 Arnon Rotem-Gal-Oz 译者 胡键 发布于 2007年8月15日
正规化（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在其介绍的结尾总结：
“人们正规化‘因为他们的教授这么说的’”
是时候反思数据库正规化的咒语了吗？一些更大的网站似乎这么认为，你的感觉呢？
查看英文原文：Data normalization, is it really that good?
译者 胡键 热心开源技术，《开源技术选型手册》作者，《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。
关系型数据库的生命周期即将走向结束
发表人
Meng Mike
发表于
Re: 关系型数据库的生命周期即将走向结束
发表人
good gpy
发表于
Re:数据正规化真的那么好吗？
发表人
sen firefly
发表于
3 条回复
关注此讨论 回复