分析/报告-相同或独立的数据库，以及哪个数据库？

Question

我有一个具有一些业务功能的用户内容网站。所有表都在一个数据库中。现在我正在根据活动和用户日志表在部门报告中添加分析功能-将其按一年中的每一天、每种活动类型等分解到部门报告中。问题是:我是为分析创建一个单独的数据库(或者人们称之为数据仓库)，还是只将这些新表添加到现有数据库中？如果我必须为此创建一个单独的数据库，那么这意味着我需要将主数据库中的所有数据加载到Analyic DB的临时表中，然后将这些数据加载到我假设的分析表中？

分析要求尽可能接近实时，因此，基于此，我不确定使用哪个数据库，如果我真的去单独的一个。我使用的MySQL能否完成提供实时分析的工作，即用户采取行动，下一秒如果他查看报告，数字将已经聚合？

Answer 1

这取决于您期望的报告量。事务处理数据库通常是用3NF设计的，以实现有效的插入。

由于需要连接的数量，报告更加复杂。此外，从报告中添加大量额外的SELECT事务可能会降低性能，这就是为什么使用报告数据库。

您需要权衡可能的报告负载和性能影响，还是设置报告副本和ETL来填充它。此外，您还需要确定是否有副本，以及复制的频率。有一个论点可以用来反对“实时”要求，即如果企业根据固定的数据快照(例如，每日副本)进行报告，则业务报告可能会更加“一致”。

有关将数据加载到报表数据库的方法，请参阅Strategies for populating a Reporting/Data Warehouse database。

Answer 2

在这一点上，这一切都是关于硬件的。如果您打算将分析数据库定位在与应用程序相同的系统(硬盘驱动器)上，那么无论您如何削减它，您都不会看到性能有很大的提高。你的速度被你的磁盘减慢了，scans...one磁盘只能扫描这么快，不管数据库是分开的。

但是，如果我必须实现实时报告...我会做第二个数据库，用于用户活动和监控。我会在用户执行活动时插入到这个数据库中。在报告期间，我会跨数据库连接(这会减慢系统速度，但既然您在同一个框上，您就别无选择)。我会将用户活动放在一个单独的数据库中，这样随着时间的推移，备份和清除旧数据会更容易。

如果您能够将您的报告系统与您的应用程序系统分开，我将执行一个15ETL/sync作业，它只将您需要的表复制到不同系统上的报告数据库中。然后我会报告那个系统。显然，用户有15分钟的延迟，但这允许更快的报告。但是，这不是真正的数据仓库，而是满足您特定需求的临时解决方案。