用于报告和日常交易的数据库

Question

我有一个可以容纳大量数据的系统。使用的数据库是SQL Server。其中一个表大约有300000行，并且有很多这种大小的表。该表上会定期进行更新-
我们将其称为发生交易的“交易数据库”。

现在，我们需要实现报告功能。一些架构师正在提议一个不同的数据库，该数据库是该数据库的副本+一些其他报告表。他们之所以提出这一建议，是因为他们不想破坏交易数据库的功能。为此，必须将数据频繁移至报告数据库。我的问题是，是否真的需要为此使用第二个数据库？我们可以使用事务数据库本身进行报告吗？由于必须将数据移动到其他数据库，因此会涉及到延迟，如果使用事务性数据库本身来进行报告，则不会出现这种情况。期待一些专家的意见。

Answer 1

您需要对ETL，数据仓库和报告数据库进行一些研究，因为我认为您的架构师可能会很好地解决这个问题。由于您没有提供实际报告的详细信息，因此我将尝试回答一般情况。

（免责声明：我在这一领域工作，我们有针对此的产品）

已优化事务数据库，以在读取/更新/插入之间实现良好的平衡，而索引和表规范化则针对这种效果。

报告数据库在所有其他方面都非常适合读取访问。这意味着一个适用于事务数据库的“正常”规范化规则将不适用。实际上，可能存在高度的非规范化，以使报表查询更加有效和易于管理。

在事务数据库上运行复杂的查询（尤其是在诸如历史时间范围之类的扩展数据范围上的聚合）查询，可能会影响性能，从而使数据库的关键用户-事务生成器受到负面影响。

尽管在您的情况下可能不需要报告数据库，但是您可能会发现，将两个用例分开是比较简单的。

您对数据延迟的担忧是真实的。只有使用报告的业务用户才能回答此问题。人们常常说“我们需要实时信息”，而事实上，如果不是所有的需求都被非实时信息所覆盖，那么我们会说“我们想要实时信息”。可接受的数据陈旧程度只能由他们来回答

实际上，我建议您进一步研究，并考虑多维多维数据集来解决报表问题，而不是仅针对报表数据库。设计将您的报告问题抽象到全新的水平。