最佳的数据库报告解决方案

Question

这里是情况说明： 有一个事务密集型数据库，用于常规交易和报告。

我想知道是否可以将这两个操作和2个独立的数据库隔离开来，使报告可以在一个数据库上运行，而所有交易都可以在另一个数据库上进行。这将提高OLTP SQL数据库的性能。

我已经考虑了一些选项，如镜像、日志传送、复制、快照、群集等，但希望讨论实现期望结果的最佳策略。

请建议最佳解决方案以实施此策略，或者您可能有其他想法/建议。

- zzyzx

Answer 1

我认为这是一个典型的前端和后端数据库分离的案例。在我工作过的项目和人员中，有一个强烈的共识，即应该将两者分开。

在一个案例中，有三个层次的数据库：

1. 前端事务中间摘要 2. 供前端事务引用的存储库 3. 后端信息存储库

前端事务速度非常关键，甚至该层被分解为多个数据库，每个制造区域一个数据库。交易由需要非常快速响应的设备执行。

从前端数据库获取的数据与面向客户和管理的数据库一起使用，以每小时频率构建记录，用于后端报告存储库，因为管理需要短的信息延迟来做出操作和工程决策。如果我们能够以15分钟的间隔执行信息编译，那就更好了。根据项目的不同，该后端存储库可以是Oracle或Sybase IQ。

然而，由设备执行的前端事务需要参考一些元信息。设备所需的响应时间不能冒被其他人在后端存储库上运行大型自定义查询的风险，这种情况很常见。

因此，创建了一个中间层桥接数据库，其中包括从后端存储库中抽取的夜间摘要信息。

用共性键设计架构

模式设计非常重要，以优化所有数据库的响应和性能。您必须确保您的数据库记录是具有共性键索引和离散时间索引的。

对于一个充满机器人和设备、分成制造区域的制造工厂，每个区域都有一个前端事务数据库。每个区域数据库需要具有共性键调度程序。当一台设备需要执行一批操作时，beginOp事件请求从调度程序那里获取离散键。一个操作周期可能需要几秒钟、几天或几周。每次设备需要在其操作状态上执行事务时，它都包括该共性键。一个操作可以具有子操作和子子操作等，但是每个这样的操作都需要从其区域调度程序中获取一个共性键。

共性键调度程序只是数据库中的beginOp表，具有自动递增键。任何共享同一开始操作的设备都能够从表中推断/获取该共性键，由于其精细的过程排序策略。

对于我们能够确保整个楼层上没有两个操作在同一100毫秒内启动的区域，就不需要调度程序，因为我们可以简单地使用beginOp事件的日期时间，其中数据库服务器的datetime函数是自然/自发的键调度程序。

讨论共性键的原因是因为所需的事务响应非常快，您不希望设备不必要地相互通信，只是告诉彼此它们正在记录同一操作的事件。机器人和设备只需使用它们所持有的共性键执行交易。

每小时编译的信息用于插入后端存储库，并方便地使用公共性+区域的复合键构建事件层次结构。

前端管道数据库

好的，这真的很极端。在某些领域，交易如此频繁，我们必须使用FIFO数据库。我们引入了第四层数据库。为了获得最佳的交易响应，我们必须保持数据库大小低于1GB。存在一个事务管道处理程序，将旧的事务清空到第四层数据库中。我发现创建一组新数据库更容易（并且响应更快），以便每当其大小达到1GB时，就会将其移出并立即从池中替换为新数据库 - 这样留给执行每小时编译的机器加入各个数据库。因此，我们依赖于现有的元数据数据库来存储带有一些元数据表的公共性-键分配器表。

回想起来，人们可能认为公共性-键分配器表和元数据表可以放置在中间层桥接数据库中，但是由于数据库管理过程是自动化的和标准化的，所以创建一个新过程比修改管理中间层桥接数据库的过程更简单。这些管理例程在全球范围内使用，因此您不能轻易更改它们，否则会对公司的财务表现或冒犯维护它们的各个数据层架构师造成混乱。

经理们需要大量组织技能才能将所有这些内容整合在一起。因此，事务数据设计不仅仅是技术技能，而是涉及到计划过程的技能，其中包括许多人之间的头脑风暴，直到达到正确的结果。

- Blessed Geek

Answer 2

您所要求的内容是完全标准的 - 在高负载场景下，OLAP 和 OLTP 不混合使用。

您正在使用 SQL Server。请查看 SSAS（SQL Server 分析处理）以构建立方体（与 SQL 不同的方法），然后可以根据此报告。

如果您不想这样做，那么镜像是下一个最佳解决方案 - 您可以将镜像放置在只读模式下以供报告使用，并且如果主服务器出现故障，则可以激活备份；这总是很好的。

集群是无关紧要的 - 它将允许您将数据库移动到另一个节点，但它根本不解决性能问题。日志文件传送、复制 - 都不错，不过我会选择镜像，只读副本用于报告，将数据加载到 SSAS 中。

- TomTom

Answer 3

我们有一个读写集群，使用事务复制技术复制到“只读”服务器（不是物理上的只读，Web应用程序只在它们上执行读取操作）。我们对报告也是同样的处理方式，这种方式扩展得非常好。

我们有多个站点，32个以上的服务器和几个报告服务器，这种配置具有非常高的插入、更新和读取量。

我们主要使用报告服务进行内部报告。报告不会影响我们的核心业务，我想这是您最关心的问题。

- Barry King