我最近与一位使用 SQL Server 2005 的用户交谈,他说他们的数据库过度规范化,他们将数据复制到报表服务器。数据库不应该同时处理事务和报告吗?为什么我必须投资 2 台服务器并进行复制?
我知道这是一个开放式的主观问题,在上述情况下我没有统计数据,但是数据库调优不足以处理事务报告吗?我可以理解,对于数据挖掘场景,我们需要一个带有分析服务和反规范化的单独服务器。但是对于当年的交易呢?
谢谢。
我最近与一位使用 SQL Server 2005 的用户交谈,他说他们的数据库过度规范化,他们将数据复制到报表服务器。数据库不应该同时处理事务和报告吗?为什么我必须投资 2 台服务器并进行复制?
我知道这是一个开放式的主观问题,在上述情况下我没有统计数据,但是数据库调优不足以处理事务报告吗?我可以理解,对于数据挖掘场景,我们需要一个带有分析服务和反规范化的单独服务器。但是对于当年的交易呢?
谢谢。
这取决于。
完全有可能在架构针对报告进行了优化的数据库中更好地处理一年甚至一个月的详细数据,或者甚至只是索引方案不同。
它还取决于报告的类型,如果您将当前月份的趋势与过去几个月进行比较,将它们放在同一个数据库中会容易得多。而且,如果您有每日移动平均线,那么在单个数据库中执行此操作要比在数据库边界上执行该操作要容易得多。
就过度标准化而言——这可能意味着很多事情。
应用程序 (OLTP) 和报告 (DW) 负载在规模应用程序上可能并且通常非常不同。OLTP 事务一次处理少量记录,经常发生并且可能是选择、插入或更新。DW 查询倾向于处理大量记录,发生频率较低,并且应该是只读的。
在较小的应用程序或还没有数据历史的年轻应用程序上,性能不会成为问题。但是随着您的应用程序的增长和普及,将需要一个单独的数据库并最终需要一个单独的服务器来满足应用程序性能和分析报告的业务需求。
以下是这两种工作负载的概述。
OLTP 查询通常由对应用程序性能有既得利益并确切知道他们试图满足什么类型的业务功能的开发人员编写。每天多次执行相同的查询,并排除问题。以下是工作负载类型的一些示例。
DW 查询可以由查询工具自动生成,用于临时报告,也可以由几乎没有技术经验的分析师或业务用户直接编写。有些人可能更喜欢在他们选择的工具中选择 *,例如 SAS 或 Mathematica。如果不使用脏读来完成这些类型的查询,可能会对 OLTP 应用程序的性能造成严重破坏。即使是编写良好的查询来进行趋势分析或将大量客户分组到百分位,也可能需要全表扫描,因为它需要所有数据。可能需要回答的问题类型。
我认为有一个独立于生产/交易服务器的报告服务器通常是一个好主意。我已经设置了具有完全“未规范化”的数据结构的报告服务器,并且会使关系纯粹主义者畏缩......但它是一个报告服务器,所以没关系。
用户喜欢能够在没有 DBA 阻碍的情况下获取“他们的”数据(报告数据库当然是只读的)。
一组例程(或者更好的是无人值守的夜间批处理),从生产服务器中提取数据并汇总、汇总、交叉表和清理,其唯一目的是以尽可能快的方式向用户提供可用信息,通常是一个很好的解决方案。
在我的情况下,对于那些“你能为我创建一个将显示......”的报告类型的请求,绝对可以减轻我的工作量。让用户访问数据并培训他们使用工具并让他们使用它。
在纯技术层面上,没有理由需要将两台服务器分开。他们可能出于“商业原因”做出决定,例如:
根据报告的复杂性,它们在运行时可能会消耗大量资源。如果这会影响系统其他用户的性能,则可以将数据转储到单独的“报告”数据库服务器中。
如果运行报告的人正在编写原始 SQL 但不是经验丰富的数据库开发人员,那么首先将数据转换为非规范化格式可能会很有用,以便他们更容易使用。它还可能有助于加快报告本身的性能。
这实际上取决于您的环境和应用程序。拥有单独的报告服务器是一个安全的选择。如果您的生产系统具有高度规范化的模式并且发生大量事务并引发记录锁定,那么针对此运行复杂的报告可能会产生毁灭性的性能损失。例如,如果可能由另一个开发人员构建的报表查询在复杂连接中不包含 (NOLOCK),则几乎可以肯定会有问题。使用正确的查询(即错误的),您可以使整个数据库陷入停顿。如果报告允许用户提取大量数据,您可能也想查看它。您可能需要防止允许用户运行此类查询。仅应要求进行此类报告。恕我直言
两个数据库可能有意义。这是我自己的经验的一个例子。
数据库 1 用于收集数百万设备租赁的付款历史记录。该数据库的主要目的是从各个贷方收集数据并用作计算信用评分的输入。这个数据库很大,更新很多,从来没有暴露在网络上。
数据库 2 用于报告。小多了。从未更新。具有信用评分计算的输出。可通过网络访问。包括许多表、索引以支持按名称、地址等进行模糊搜索。
如果您认为数据库 1 有很多更新,那么一遍又一遍地更新与搜索相关的索引将是一种浪费。如果您认为数据库 1 很大,而数据库 2 很小,那么将多余的数据发送到面向网站的机器将是一种浪费。
这可能是最佳解决方案,具体取决于进行报告的用户的精明程度以及他们使用的工具;如果他们必须手动加入 8 个表来获取临时客户报告,那么他们最好使用带有视图的报告服务器来为他们完成所有繁琐的工作。
如果报告作者不了解数据结构,请为他们创建一些视图(只读)。在事务负担较低时运行资源密集型报告。有一个开发数据库以防止干扰生产。
当事情不同步并且您花费大量时间来查找问题时,总会出现一种情况。
高度理论化,但我的关系数据库教授会说,唯一的数据重复是主/外键关系或用于备份/测试目的的副本。我想听听他对数据仓库的看法。
过度规范化通常意味着报告用户不了解数据模型。您可能希望远离事务数据库的那种用户。与您的事务数据库因报告用户正在执行奇特的联接而无响应相比,复制服务器是一种非常便宜的解决方案。
它主要是一种简单的组织措施,在操作用户和报告用户之间建立了界限。