在高流量网站中规范化或非规范化

Question

对于像stackoverflow这样的高流量网站，数据库设计和规范化的最佳做法是什么？

是否应该使用标准化数据库进行记录保存或标准化技术或两者的组合？

将规范化数据库设计为记录保存的主数据库以减少冗余并同时维护数据库的另一种非规范化形式以便快速搜索是否合理？

或

主数据库是否应该非规范化，但在应用程序级别使用规范化视图进行快速数据库操作？

或其他一些方法？

Answer 1

加入的性能经常受到高估。像Oracle这样的数据库产品可以非常有效地加入。当真正的罪魁祸首是糟糕的数据模型或糟糕的索引策略时，联接通常被认为表现不佳。人们还忘记了，在插入或更新数据时，非规范化数据库的表现非常糟糕。

要记住的关键是您正在构建的应用程序类型。大多数着名网站都不像常规企业应用程序。这就是Google，Facebook等不使用关系数据库的原因。最近有很多关于这个话题的讨论，I have blogged about。

因此，如果您正在构建一个主要关于提供半结构化内容的网站，您可能不希望使用关系数据库，非规范化或其他方式。但是，如果您正在构建一个高度交易的网站（例如在线银行），您需要一种能够保证数据安全性和完整性的设计，并且做得很好。这意味着至少是第三范式的关系数据库。

Answer 2

对数据库进行非规范化以减少密集查询所需的连接数是许多不同的扩展方法之一。不得不做更少的连接意味着数据库不那么繁重，磁盘也很便宜。

也就是说，对于荒谬的流量来说，良好的关系数据库性能可能很难实现。这就是为什么许多大型网站使用密钥值存储（例如memcached）和其他缓存机制。

The Art of Capacity Planning非常好。

Answer 3

首先：为自己定义高流量意味着什么：

• 50.000 Page-Viewss每天？
• 每天500.000页面观看次数？
• 每天5.000.000页面观看次数？
• 更多？

比计算每分钟和每秒的pobalbe峰值页面浏览量。 之后，考虑每个页面视图要查询的数据。数据是否可缓存？数据有多动态，数据有多大？

分析您的个人需求，编写一些代码，进行一些负载测试和优化。在大多数情况下，在需要扩展数据库服务器之前，需要扩展Web服务器。

如果完全优化了关系数据库，那么在加入表时可以非常快！

关系数据库在作为后端时很少被用来填充缓存或填充一些非规范化数据表。我不会将denomralization作为默认方法。

（您提到了搜索，如果您需要全文搜索，请查看例如lucene或类似内容。）

最佳最佳实践答案绝对是：取决于 ;-)

Answer 4

您可以通过以下播客的堆栈溢出创建者听取有关此主题的讨论：
http://itc.conversationsnetwork.org/shows/detail3993.html

Answer 5

对于我正在研究的项目，我们已经选择了非规范化的表路由，因为我们希望我们的主表对写入的读写比例高（而不是所有用户都在同一个表中，我们已经非规范化了）它们并设置每个“用户集”以使用特定的分片）。您可能会发现阅读 http://highscalability.com/有关“大型网站”如何处理该卷的示例 - Stack Overflow最近已被展示。

Answer 6

如果您没有正确缓存，这两件事都不重要。