【问题标题】:How to denormalize a heavily normalized database system?如何对高度规范化的数据库系统进行非规范化?
【发布时间】:2010-10-22 01:40:40
【问题描述】:

我希望在高度规范化的系统中引入一些数据库非规范化。

我拥有大量数据库,这些数据库已经发展了 10 多年,并且负载不断增加,因此我希望提高性能并可能降低某些查询的复杂性。

执行 10 次联接来完成存储过程中的任何给定任务并不罕见。有人告诉我,超过 6 种臭味。

我是否应该保持表结构不变并提供一些物化视图或非规范化“缓存”表。

一些关于最佳实践的建议或推动正确方向会有所帮助。

谢谢

【问题讨论】:

    标签: sql-server-2005 performance caching denormalization


    【解决方案1】:

    你没有说问题是什么。是性能吗?如果是这样,在什么桌子上?

    真的是连接导致问题吗?还是存储过程?你不知道(或者至少你没有说)。

    最佳实践:首先找出瓶颈所在,然后再尝试解决尚未诊断出的问题。


    编辑时:我想起了在工作中遇到性能问题的时候。非常慢的存储过程,可能需要几分钟才能完成。事实证明,这些 sps 正在执行完全正常的表更新,但使用游标。对于像update t set c = c + 1 where id = n 这样简单的东西。

    所以要进行更新,我们使用昂贵的更新游标对一堆行进行游标并执行 declare cursor for "select c from t where id = n" for update; 然后打开游标和读取和错误检查以及带有读取和错误检查的循环,然后select c into @c; @c = c + 1; update t set c = @c where current of cursor; 每次更新。

    原来写这篇文章的人没有意识到我们可以发布一个更新声明。所以他写了几十个这样的慢速存储过程。我们甚至不需要摆脱存储的过程(尽管这也会为我们带来一些速度,但它会改变我们的客户端);我们只是摆脱了游标,用更新语句替换它们。性能问题消失了。

    【讨论】:

      【解决方案2】:

      需要调查的一些事情

      • 对所有查询运行时间进行基准测试 - 给自己一个指标以进行比较。
      • 调查索引是否正确完成。
      • 阅读table partitioning
      • 探索sharding as an option
      • 仔细查看您的联接。您是否总是将同一张桌子连接在一起?如果答案不是很明显,您仍然可以使用视图创建逻辑分区(如非规范化表)。

      【讨论】:

        【解决方案3】:

        我同意以利亚的观点。确保你对任何你将要改变的东西进行基准测试。

        此外,根据您的设置,索引视图可能是一个选项。

        【讨论】:

          【解决方案4】:

          尝试大量且明智地编制索引。 尝试使用索引视图。 尝试预编译的存储过程。 如果失败,请记住,非规范化和缓存通常需要大量的同步工作,因此在执行之前应仔细查看每种情况。

          【讨论】:

            【解决方案5】:

            我必须同意,10 次连接是邪恶的,会扼杀你的表现。

            很大程度上取决于您的应用程序与数据库的交互方式。如果您的代码严格遵守存储过程(没有直接的 SQL 调用),那么您的生活会更轻松。

            如果您遇到非规范化的麻烦,我不会添加新的“缓存”表。这实际上只是修补问题。我会继续制定一个完整的计划,以使用新的优化模式对数据库进行非规范化。

            【讨论】:

              猜你喜欢
              • 2017-01-27
              • 2020-04-06
              • 2017-10-05
              • 2013-03-08
              • 2013-01-18
              • 2016-07-23
              • 2018-12-12
              • 1970-01-01
              • 2021-09-05
              相关资源
              最近更新 更多