何时建立单独的报告数据库?

一般来说,事务应用程序的任务越关键,报告要求越复杂,拆分就越有意义。

1. 当事务性能至关重要时。
2. 当很难在事务应用程序上获得维护窗口时。
3. 如果报告不仅需要关联此应用程序的结果,还需要关联其他应用程序的结果。
4. 如果报表需要支持最适合星型模式/商业智能环境的趋势分析或其他类型的报表。
5. 如果报告长时间运行。
6. 如果事务应用程序位于昂贵的硬件资源(群集、大型机等)上,
7. 如果需要对事务性数据执行数据清理/提取转换加载操作(例如,状态名到规范状态缩写)。

它增加了非平凡的复杂性,所以在我看来,必须有一个很好的理由来分裂。

通常,我会尝试首先报告事务数据库。

确保经常使用为方便高效报告而添加的任何索引。添加的索引越多,插入和(如果更改键)更新的性能就越差。

当您确实要访问报告数据库时,请记住,您访问该数据库的原因只有以下几个:

归根结底,报告数据库的第一件事是从OLTP数据库中删除锁争用。因此,如果您的报告数据库是同一数据库的直接副本,那么您只需使用延迟的快照,这不会干扰生产事务。

接下来,您可以有一个单独的索引策略来支持报告使用场景。这些额外的索引可以在报告数据库中维护,但会在OLTP数据库中造成不必要的开销。

现在,这两种方法都可以在同一台服务器上完成(甚至是在单独的数据库中的同一个实例,甚至是在单独的模式中),并且仍然可以看到好处。当CPU和IO完全固定时,此时,您肯定需要将它放在一个完全独立的盒子上(或者升级单个盒子)。

最后,为了实现最终的报告灵活性,可以将数据(通常是维度模型或星型模式)非规范化,以便报告数据库在不同的模型中是相同的数据。在维度模型中,大量数据(尤其是聚合数据)的报告速度非常快,因为星型模式非常有效。在没有大量重新索引或分析的情况下,对于各种各样的查询,更改索引也是有效的,因为维度模型更适合于不可预见的使用模式(旧的“向每一个方向切片和切块”请求)。您可以看到,这是一种使用数据仓库技术的小型数据仓库,但不一定实现全面的数据仓库。此外,星型模式对于用户来说特别容易掌握,数据字典对于使用星型模式的BI工具或报告工具来说更简单也更容易构建。你可以在同一个盒子或不同的盒子上做这个,就像前面讨论的那样。

北极:

希望你在近两年后找到了答案。这个问题需要经验而不是科学。

作为一个BI架构师,我为我的客户设计每个BI解决方案所采用的方法是非常不同的。我没有检查清单。这需要全面了解他们的系统、报告要求、预算和人力。

我个人更喜欢在数据库端尽可能多地保留报告流程(BI世界中的最佳实践)。报告工具仅用于显示目的(对于小计算最大)。这种方法需要大量的数据预处理,这些数据需要不同的临时表、触发器等。

当你说:

我处理的项目有数亿行,实时报告,数百个用户同时访问应用程序/数据库,但没有问题。

你的陈述有一些问题。

1. 数以亿计的行数太多了。即使是像CognosTM1或QlikView这样的内存工具也很难获得这样的结果。(查看SAP的SAP HANA,了解行业巨头如何处理它)。

2. 如果数据库中有数亿行,并不一定意味着报表需要遍历所有这些记录。也许这份报告的作用是1000人,而不是数百万人。可能你看到的就是这个。

3. 交易报告与仪表盘非常不同。大多数仪表板工具预处理和缓存数据。

我知道两年后我会回答,而且我的想法没有很好的组织,但我的观点是,所有这些都取决于决定何时: 1。设计新架构 2。创建语义数据库 三。处理同一事务数据库 4。或者甚至使用报告工具(有时使用Java/JSF/Ajax/jQuery或JSP的手写仪表板为客户端工作)

您需要一个单独的数据库来报告问题的主要原因是,生成报告会干扰应用程序的事务职责。例如,如果报告需要20分钟来生成和使用100%的CPU/磁盘/等…在活动频繁的时候,您可能会考虑使用单独的数据库进行报告。

至于问题,以下是一些基本问题:

1. 我可以在非高峰时间做高强度报告吗?
2. 它是否会干扰使用系统的用户?
3. 如果对2是,干扰的成本与另一个数据库服务器、重构代码等的成本是多少?

基本上,当应用程序中的数据库加载与用于报告的数据库加载不兼容时。这可能是由于:

• 报告消耗了大量数据库服务器资源,影响应用程序的数据库性能。

  这一类别的一部分是,由于锁定,应用数据库的工作必须等待一个非常慢的报告查询,尽管使用锁调优之类的不太激烈的方法可能可以解决这个问题。

• 报告查询在调优方面与应用程序查询非常不兼容(例如索引,但不限于此)-最愚蠢的例子是,由于报告目的索引,影响应用程序插入的热点。

• 时间问题。例如,数据库维护的唯一小窗口(由于应用程序的使用)是繁重的报告工作时间。

• 报告数据的绝对量(例如日志记录、审计、统计)非常大,以至于您的主DB服务器架构对于此类报告来说是一个糟糕的解决方案(请参阅Sybase ASE与Sybase IQ)。顺便说一句,这是一个真实的场景——正因为如此,我们将绩效报告转移到了IQ。

我还想补充一点,事务性数据库是用来保存当前状态的,而且通常是自我维护的。您不希望事务数据库的增长超出其必要的手段。当一个工作流或事务完成后,将该数据移出并移入一个报告数据库,该数据库更适合保存历史数据。

我还将添加另一个您可能使用报告数据库的原因,即:cqrs模式(命令查询职责分离)。

如果有大量的用户访问和写入一小部分数据,那么考虑这种模式是明智的。它的最简单形式基本上意味着所有命令(创建、更新、删除)都被推送到事务数据库中。 所有查询(读取)都来自报告数据库。这可以让您自由地查看您的架构和升级功能。

在模式中还有更多的内容,我刚刚提到了由于您关于报告数据库的问题而有趣的部分。