Dashboard 数据分析架构

我有一个数据库，它保存了一些数据。该数据在存储到该数据库之前会转换为所需的格式。生产应用程序也会查询数据库

请注意，没有原始数据数据库，所有数据都经过处理，以便在我们的应用程序中进一步使用，然后再将其插入noSQL。 现在我需要基于这些数据实现一些报告

例如，通过在UI中选择日期范围，生成简单图表以按日期显示收集的数据趋势：

当然，这是一个简单的例子来理解我需要什么，并试图实现，真正的报告将更加复杂

原则上，我正在寻找最常见和最智能的方式来连接这两个子系统data DB和analytics，以实现以下结果：通过应用程序查询的报表查询相同的数据

在这里，我看到了一些挑战和困难，因为繁重的报告会影响数据库吞吐量，而且应用程序也使用相同的数据库也会降低它们的速度。 如果已经有一些原则建立了这样的体系，如果您在评论/回答中提及，我将不胜感激

由于我找不到任何指导原则，我将描述我对如何实施分析的想法：

将这些计数像消息传递平台上的事件一样发送到另一个应用程序，该应用程序将把这些数据存储到单独的数据库中，并在以后的报告中使用这些数据。我认为这种方法有以下优点和缺点： 优点：仪表板平台对性能没有影响。 缺点：重复数据

---

因此，您有一个事务应用程序当前使用的数据库， 您将在该数据库中的数据之上构建一个分析应用程序，但需要考虑添加到事务应用程序中的性能影响

一种常见的做法与您的想法类似，即复制数据 输入另一个数据库进行分析

应用子系统是一个OLTP系统， 分析子系统是OLAP系统。将数据从OLTP数据库转换为OLAP数据库的过程称为ETL。您通过消息队列复制数据的想法 进入另一个数据库是一种可能的自定义ETL方法

在OLAP系统中，通常使用星型模式或OLAP多维数据集来存储预聚合的数据，以便报表应用程序能够以更好的性能从数据库中查询数据。大多数报告工具BI工具，如Tableau、Cognos、SSRS，都可以从星型模式读取数据。即使您不打算使用这些工具中的任何一个，只想用自定义代码构建报表UI，星型模式也会很有帮助

---

现在报告和应用程序使用不同的数据库，这两者之间会有一个时间差。如果使用消息队列实时将数据转换为分析数据库，则时间延迟将是最小的。但是，如果为了获得更好的查询性能而预先聚合数据，则向OLAP DB添加新数据时会有成本。这就是为什么很多报告系统通常不报告实时数据，如果时间延迟对于业务来说是可以接受的。

请更精确地说明挖掘的数据。数据挖掘是一个庞大的领域，有些人用这个流行词来进行简单的聚合，或者说网络抓取。不要在这里玩流行语宾果游戏，这不是商业推销。