标准化真的会损害高流量站点的性能吗？

Posted 2023-03-08

【中文标题】标准化真的会损害高流量站点的性能吗？

【英文标题】：Does normalization really hurt performance in high traffic sites?

【发布时间】：2011-02-11 18:13:19

【问题描述】：

我正在设计一个数据库，我想规范化数据库。在一个查询中，我将加入大约 30-40 个表。如果它变得非常流行，这会损害网站的性能吗？这将是主要的查询，它会在 50% 的时间里被调用。我将加入关于两个表的其他查询。

我现在可以选择规范化或不规范化，但如果将来规范化成为问题，我可能需要重写 40​​% 的软件，这可能需要很长时间。在这种情况下，标准化真的会受到伤害吗？我现在应该趁我有空的时候去规范化吗？

【问题讨论】：

您不应该冒如此大规模重写（40%）代码的风险。如果您开始规范化但使用视图来提供大多数代码所需的抽象......那么如果您需要将视图非规范化为抽象层应该呈现的方案，它应该避免大多数代码更改。跨度>

当您需要更新非规范化表时，请注意所涉及的开销（就工作量而言） - 如果您更改客户端地址，而不是在一个地方更改它，您现在必须扫描每个在曾经非规范化的表中的行来改变它。也许视图是您的最佳选择，如果仍然太慢，请为数据库分配更多硬件资源。

我想知道为什么首先需要 30-40 个表 - 以及为什么必须加入这些表。这对我来说似乎不对，所以我希望你解释一下这些表在做什么。

【参考方案1】：

不要进行早期优化。非规范化并不是加快网站速度的唯一方法。您的缓存策略也很重要，如果 30-40 个表的查询是相当静态的数据，缓存结果可能会被证明是更好的优化。

另外，还要考虑写入次数对读取次数的影响。如果您为每次插入或更新进行大约 10 次读取，您可以说数据是相当静态的，因此您应该将其缓存一段时间。

如果您最终对架构进行非规范化，您的写入也会变得更加昂贵，并且还可能会减慢速度。

在进行过多优化之前真正分析您的问题，并等待查看您在系统中的真正瓶颈，因为您最终可能会惊讶于您应该首先优化什么。

【讨论】：

30-40 张桌子根本不会是静态的。在正常情况下，我们预计会有大约 1000 次更新和插入。

一天更新 1000 次，每分钟不到 1 次。我认为这是相当静态的。

同意。假设您的读取次数多于写入次数，那么您的缓存策略将被证明非常重要。

【参考方案2】：

也许我在这里遗漏了一些东西。但是，如果您的架构要求您在单个查询中连接 30 到 40 个表，并且该查询是您网站的主要用途，那么您就会遇到更大的问题。

我同意其他人的观点，不要过早优化您的网站。但是，您应该优化您的架构以解决您的主要用例。 IMO 未优化 40 表连接的查询运行时间超过 50%。

【参考方案3】：

标准化会损害性能。但是，这不是过早反规范化的理由。

从完全规范化开始，然后您会看到是否有任何性能问题。按照您描述的速度（每天 1000 次更新/插入），除非表很大，否则我认为您不会遇到问题。

即使有大量的数据库优化选项（索引、准备好的存储过程、物化视图等）可供您使用。

【参考方案4】：

当性能受到关注时，通常有比非规范化更好的选择：

在相关表上创建适当的索引和统计信息 缓存 物化视图（MS SQL Server 中的索引视图） 除了在大多数情况下使用的规范化表（需要编写同步代码，可以作为触发器或计划作业运行）之外，还拥有表的非规范化副本（专门用于需要它们的查询）取决于您需要的数据准确性）

【参考方案5】：

我引用：“为了正确而规范化，为了速度而去规范化 - 并且仅在必要时”

我推荐你：In terms of databases, is "Normalize for correctness, denormalize for performance" a right mantra?

HTH。

【讨论】：

+1。您不会规范化数据库 - 总是 以 3NF 开头。当且仅当有必要时，恢复到较低的速度级别。并确保您了解后果和解决方案。有一些方法可以缓解由非规范化（触发器、计算列等）引起的问题。还要查找 YAGNI :-)

那么你认为加入30-40个表不会有问题吗？此外，如果标准化确实成为问题，是否可以添加更好的硬件来抵消标准化成本？

@Luke：不，这很可能是加入 40 个表的问题，此时您应该考虑非规范化（但仅在问题出现之后，而不是预期可能不存在的问题 - 测量，不要猜）。但我非常对需要连接那么多表的 3NF 模式感兴趣。根据我的经验，我从未遇到过如此极端的情况。也许如果您在这方面添加更多细节，我们既可以更好地理解，也可以提供更有针对性的建议。

我完全同意 paxdiablo 和 Luke101 的观点，即最好先测量和量化您的指标，然后再对数据库进行反规范化。与开发相比，硬件更便宜，但不是仅仅将硬件扔给一个问题，而是测量、量化然后决定......