我有一个包含大量数据的系统。使用的数据库是SQL Server。其中一个表有大约300000行，并且有相当多的这种大小的表。在这个表上发生了定期更新 - 我们将其称为事务正在发生的“事务数据库”。
现在，我们需要实现报告功能。一些架构师提议使用不同的数据库，该数据库是此数据库的副本+一些用于报告的附加表。他们提出这个建议是因为他们不想破坏事务数据库功能。为此，必须经常将数据移动到报告数据库。我的问题是，是否真的需要为此目的建立第二个数据库？我们可以将事务数据库本身用于报告目的吗？由于必须将数据移动到不同的数据库，因此将涉及延迟，如果事务数据库本身用于报告则不是这种情况。 期待一些专家建议。
答案 0 :(得分：7)
您需要对ETL，数据仓库和报告数据库进行一些研究，因为我认为您的架构师可能会以一种好的方式解决这个问题。由于您没有提供实际报告的详细信息，我将尝试回答一般情况。
（免责声明：我在这个领域工作，我们有适合这个的产品）
事务数据库经过优化，可以在读取/更新/插入之间取得良好的平衡，并且索引和表格规范化可以适应这种效果。
报告数据库非常适合读取访问，超越所有其他内容。这意味着将应用于事务数据库的“正常”规范化规则将不适用。实际上，可能存在高度的非规范化以使报告查询更有效且更易于管理。
在事务数据库上运行复杂（特别是对扩展数据范围的聚合，例如历史时间帧）查询可能会影响性能，使得数据库的关键用户 - 事务生成器可能会受到负面影响。
虽然在您的情况下可能不需要报告数据库，但您可能会发现将两个用例分开是更简单的。
您对数据延迟的关注是真实的。这只能由将使用报告的业务用户来回答。通常人们说“我们想要实时信息”，实际上很多，如果不是所有的要求都包含非实时信息。可接受的数据陈旧程度只能由他们来回答
事实上，我建议您稍微进一步研究，并查看多维立方体，以便报告问题，而不仅仅是报告数据库。将您的报告问题设计抽象到全新的水平。
答案 1 :(得分：4)
我是第二个Hubson的回答。我自己可能不是一个体面的SQL服务器开发人员，但我面对的是大表（大约1米行）。所以我或多或少都有这方面的经验。
参考this SE answer，我可以说同一个硬盘上的多个数据库由于硬盘的I / O容量而无法提升性能。如果您能以某种方式将报告数据库放到不同的硬盘上，那么您可以通过I/O上的一个hdd密集，以及read only中的其他密集来获得收益。
如果两个数据库都存在于同一个实例中，它会共享相同的memory和tempdb，这对性能没有任何好处或者根本不会降低I / O成本。
此外，300k行并不是什么大问题，除非它与其他3个300k表连接，或者有一个非常复杂的查询需要数据清理等等。虽然你的数据增长率在未来快速增长。
如果不涉及对运营数据库的性能影响，您可以采取哪些措施来提高报告的性能？
正确编制索引
除了需要一些存储空间之外，正确的索引还可以加快数据处理速度，并且您会对如何加速处理感到惊讶。
正确锁定
NoLock imho最适合用于报告，除非您在数据库中使用与序列化策略不同的锁定策略。由未提交的交易引起的报告结果的偏差通常无关紧要。
汇总数据
生成汇总数据的计划流程也可用于防止重新计算报告阅读。
编辑：
那么，拥有第二个数据库有什么好处？虽然拥有它是有益的 不会直接有益于绩效。第二个数据库可用于保持事务数据库清洁并与报告活动分开。它的好处：
保留具体化数据
例如，每个月生成的总利润汇总可以存储在属于此特定数据库的表中
保持报告逻辑
您可以保护与事务性数据库</ p>
为db生成的文件用transactional分隔。它更容易备份/恢复（并与事务分离），当你想要移动到不同的硬盘时，它就更容易了
简而言之，为这种情况添加另一个普通数据库不会给性能带来太多好处，除非它正确完成（将硬盘分开，将服务器分开等）。但是，第二个数据库虽然可以在可维护性方面和安全策略中获益。
答案 2 :(得分：2)
在完美的世界中，报告和运营数据应该是分开的。原因是您希望将事务表集中用于插入/更新（通常较少的索引）和报告选择（通常更多的索引）。当然，现实世界并不是完美的世界。所以这是我的经验法则。只要你可以在同一个表上同时执行这两个操作而不会丢失性能，同时保持报告代码的可维护性，那么就没有真正的理由去分离。当是时候进行跳转时，您可能会处于关系数据库至少应该通过BI解决方案进行扩充的阶段。当时机成熟时，两者应分开的另一个原因。
要记住一件事。大多数建筑师想要超过建筑师，毕竟这是他们的工作。让他们诚实，让他们证明自己的情况。对你而言，总是希望你是如此成功，以至于你需要他们所说的设计它，但如果你花费很大的交付速度，就不要试图实现最终游戏。