database-design - OLTP 应用程序上的业务报告

Question

我们有一个使用 Oracle 数据库 10g 企业版的 OLTP 应用程序，
并计划搭建业务报表层，满足以下需求。

当前 OLTP 数据库设计的屏蔽复杂性

提高当前 OLTP 报表的查询性能

提供对其他应用程序的只读访问权限

允许业务用户执行临时报告

我们正在考虑的解决方案是在当前 OLTP 上使用 Oracle Materialized Views(MV) 创建一个 DB 缓存层。
MV 将被非规范化并设计用于报告。 MV 日志将使用增量刷新同步对 MV 的更改。

我的问题是，

这种方法有意义吗(MV)？有没有人使用 MV 来构建 OLTP 报告解决方案？

这种方法(MV)的缺点是什么？

如何使用 Oracle CDC 和表，以及执行同步的过程。

还有其他方法吗？

谢谢，
雪莉酒

Answer 1

一般来说，我会考虑用于报告用户的 View 层或物化 View 层。除非有具体的性能问题，否则我的偏好是使用 View 来创建偶尔使用查询重写来加速选定报告的物化 View 。

如果您使用物化 View ，您显然会再次物化数据，但其格式将导致存储效率降低。这意味着系统中的大部分空间将分配给非规范化的物化 View 及其索引。这可能会从您的磁盘供应商处产生相当高的帐单，并且可能会引起对 SAN 资源的争用。

物化 View 也意味着 OLTP 和报告用户之间对缓存空间的更多竞争。由于它们存储在不同的对象中，因此正在查找最近事件的报告将无法从 OLTP 事件的缓存中的热块中受益，反之亦然。您可以通过使用 RAM 或将报告移至非高峰时间来缓解此问题，但这不是最有效的解决方案。如果您几乎只有历史报告，这可能没什么大不了的——无论如何都不会共享，因为流程对完全不同的块感兴趣——但如果您有大量的运营报告，它就变得很重要。

物化 View 也可能不太灵活。如果您想以多种方式呈现相同的数据，那么多次物化它会在磁盘和缓存中增加实际成本，并增加定期刷新物化 View 层所需的时间。在实践中，这往往意味着报告用户获得数据的最小公分母 View ，并且在对数据进行切片和切块时必须重新发明轮子，因为 IT 不想为他们创建新的物化 View 。

正如我之前所说，我的偏好是常规 View 层。这避免了多次存储数据的成本，并使在 OLTP 和报告查询之间共享缓存中的块成为可能。它还使向用户提供不同的数据 View 变得相对容易，并且无需让业务用户了解他们报告的数据的陈旧程度。如果由于 OLTP 数据模型不支持您想要运行的查询类型而导致性能成为问题，您可以通过 query rewrite 创建充当索引的目标物化 View 。 .这意味着用户可以查询常规 View ，DBA 可以稍后添加生成全部或部分结果的物化 View ，优化器可以更改查询计划以使用新的物化 View ，而不是扫描表并执行其他操作比如在运行时聚合数据。

在某些时候，您可能希望将报告流量转移到具有更多维度数据模型的真实数据仓库。如果您发现您确实需要物化 View 层而不是常规 View 层的性能，我会强烈考虑使用具有事实和维度的真实数据仓库。您将获得更灵活的报告，与使用完整的物化 View 层可能会遇到的 ETL 问题基本相同。