我们正在构建一个拥有数据库的应用程序（是的，非常令人兴奋的呵呵:)。数据库主要是事务性的（支持应用程序），并且还会在应用程序中进行一些“报告” - 但没有什么太费劲。
除此之外，我们还有一些报告要求 - 但目前它们非常模糊和高级。我们有一个标准的报告工具，我们在内部使用，随着需求的巩固，我们将用它来进行“更重”的报告。
我的问题是：您如何知道何时需要单独的报告数据库？
需要问什么样的问题？什么样的事情会让你决定一个单独的报告数据库是必要的？
一般而言，交易应用程序越关键，报告要求越复杂，分裂就越有意义。
它增加了非平凡的复杂性，所以imo，必须有一个很好的理由去分裂。
通常，我会尝试最初报告事务数据库。
确保您经常使用添加的任何索引以促进有效报告。您添加的索引越多，性能越差，插入和（如果您更改密钥）更新。
当您转到报告数据库时，请记住您只有几个原因：
最终，关于报告数据库的首要问题是您正在从OLTP数据库中删除锁定争用。因此，如果您的报告数据库是同一数据库的直接副本，那么您只需使用不会干扰生产事务的延迟快照。
接下来，您可以使用单独的索引策略来支持报告使用方案。这些额外的索引可以在报告数据库中维护，但会在OLTP数据库中造成不必要的开销。
现在，上述两种方法都可以在同一台服务器上完成（即使是在单独的数据库中的相同实例，甚至只是在单独的模式中），仍然可以看到好处。当CPU和IO完全挂钩时，此时，您肯定需要将它放在一个完全独立的盒子上（或升级您的单个盒子）。
最后，为了最终报告的灵活性，您可以对数据进行非规范化（通常是对维度模型或星型模式），以便报告数据库是不同模型中的相同数据。在维模型中报告大量数据（特别是聚合）非常快，因为星型模式非常有效。对于更多种类的查询而言，如果没有大量的重新索引或分析来更改索引，它也是有效的，因为维度模型更适合于无法预料的使用模式（旧的“切片和骰子每个方向”请求）。您可以看到这是一种使用数据仓库技术的小型数据仓库，但不一定要实现完整的数据仓库。此外，星型模式对于用户来说特别容易掌握，并且数据字典对于BI工具或星型模式的报告工具来说更简单，更容易构建。你可以在同一个盒子或不同的盒子上做这个，就像前面讨论过的那样。
这个问题需要经验而不是科学。
作为BI架构师，我为客户设计每个BI解决方案的方法非常不同。我没有查看清单。它需要对其系统，报告要求，预算和人力有一个大致的了解。
我个人更喜欢在数据库方面尽可能多地保留报告流程（BI世界中的最佳实践）。报告工具仅用于显示目的（最小用于小型计算）。这种方法需要大量的数据预处理，这需要不同的登台表，触发器等。
当你说：
我处理具有数亿行的项目，实时报告以及数百名用户同时访问应用程序/数据库而没有问题。
你的陈述有一些问题。
我的观点是，在决定何时：
您需要一个单独的数据库来报告问题的主要原因是报告的生成会干扰应用程序的事务责任。例如。如果报告需要20分钟来生成并利用100％的CPU /磁盘/等......在高活动期间，您可能会考虑使用单独的数据库进行报告。
至于问题，这里有一些基本的问题：
基本上，当来自应用程序的数据库负载变得与用于报告的数据库负载不兼容时。这可能是由于：
我还将添加另一个可能使用报告数据库的原因，即：CQRS模式（命令查询责任分离）。
如果您有大量用户访问和写入一小组数据，您可以考虑使用此模式。基本上，它以最简单的形式表示所有命令（创建，更新，删除）都被推送到事务数据库。您的所有查询（读取）都来自您的报告数据库。这使您可以自由地修改您的架构和升级功能。
在模式中还有更多内容，我刚才提到了由于您关于报告数据库的问题而感兴趣的位。
我还要补充说，事务数据库意味着保持当前状态，并且通常这样做是为了自我维护。您不希望事务数据库超出其必要的手段。当工作流或事务完成后，将该数据移出并进入报告数据库，该数据库设计得更好，可以保存历史数据。