logo标签列表

在高流量网站中，规范化是否真的会影响性能？

c#performancesql-server-2008normalizationdenormalization
6

我正在设计一个数据库，并希望对其进行规范化。在一个查询中，我将连接大约30-40个表。如果这个网站变得非常流行，这会影响网站的性能吗？这将是主要查询，并且将被调用50％的时间。其他查询我只需要连接两个表。

现在我有一个选择，是规范化还是不规范化，但如果规范化在将来成为问题，则可能需要重写40％的软件，这可能需要很长时间。在这种情况下规范化是否真的会有影响？现在应该去除规范化吗？

2
你不应该冒着重写40％代码的风险。如果你从规范化开始，但考虑到提供大部分代码所需的抽象，则在需要反规范化为视图呈现的计划中，抽象层应消除大部分代码更改。 - Jim Dennis
1
当您需要更新非规范化表时，请注意涉及的开销（工作量）- 如果您更改客户地址，而不是在一个位置更改它，则现在必须扫描每个非规范化表中的每一行以进行更改。也许视图是您的最佳选择，如果仍然太慢，则将更多硬件资源分配给数据库。 - slugster
1
我想知道为什么你需要30-40张表格 - 以及为什么这些表格必须被连接。这对我来说似乎不太对，所以我希望你能解释一下这些表格的作用。 - Richard Harrison
5个回答
4
3
在数据库设计中，不要考虑规范化（normalization） - 总是从第三范式（3NF）开始。仅在必要时为了提高速度才返回较低的规范化级别，并确保您理解其后果和解决方案。有方法可以缓解非规范化带来的问题（触发器、计算列等）。还要查找YAGNI :-) - paxdiablo
那么，您认为连接30-40个表不会有问题吗？另外，如果规范化成为问题，是否可以添加更好的硬件来抵消规范化成本？ - Luke101
1
@Luke: 不，加入40个表可能会有问题，这时你应该考虑去规范化（但只在出现问题后考虑，而不是预期可能不存在的问题-要量力而行）。但我对需要连接那么多表的第三范式模式非常感兴趣。根据我的经验，我从未遇到过这种极端情况。也许如果你在这方面添加更多详细信息，我们就能更好地理解并提供更有针对性的建议。 - paxdiablo
我完全同意paxdiablo和Luke101的观点，即在去规范化数据库之前，最好先测量和量化指标。与开发相比，硬件是廉价的，但是不仅仅是为了解决问题而投入硬件，而是要先进行测量、量化，然后再做决策... - Sunny
3

当性能是一个关注点时，通常有比去除范式更好的替代方案：

  • 在涉及的表上创建合适的索引和统计信息
  • 缓存
  • 物化视图（在MS SQL Server中称为索引视图）
  • 拥有去除范式的表的副本（仅用于需要它们的查询），除了大多数情况下使用的规范化表之外，还需要编写同步代码（可以作为触发器或定期运行的任务，具体取决于所需数据准确性）
1

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

此外，考虑写入次数与读取次数之比。如果您每次插入或更新大约进行10次读取，可以说数据相当静态，因此应该将其缓存一段时间。

如果最终非规范化您的模式，您的写入成本也会变得更高，并且可能会减慢事情的速度。

在进行太多优化之前，请仔细分析您的问题，并等待看到系统瓶颈真正存在的地方，因为您可能会惊讶于首先应该优化什么。

30-40个表格将完全不是静态的。在正常情况下，我们预计会有大约1000次更新和插入操作。 - Luke101
1
一天内进行1000次更新，每分钟不到1次。我认为这相当静态。 - Gabe
同意。假设您进行的是更多的读取而不是写入操作，那么您的缓存策略将非常重要。 - jamesaharvey
1

规范化可能会影响性能。但这并不是过早去规范化的理由。

首先进行完全规范化，然后再看看是否存在性能问题。以您描述的速率（每天1000次更新/插入），除非表格非常庞大，否则我认为您不会遇到问题。

即使有很多数据库优化选项（索引、准备好的存储过程、物化视图等），您也可以使用。

1
也许我在这里漏掉了什么。但是如果你的架构要求你在一个查询中连接30到40个表，并且该查询是你网站的主要用途，那么你就有更大的问题了。
我同意其他人的观点，不要过早地优化你的网站。然而，你应该优化你的架构以适应你的主要用例。在50%的时间内运行的查询需要连接40个表，在我看来并没有进行优化。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接