database-design - 拆分数据库密集型应用程序

Question

我目前正在为大约 90 KLOC 的保险经纪人开发一个数据库繁重的业务线 Rails 应用程序 - 其中大部分是通过业务交易进行数据操作，以及多个报告来汇总所有数据。

我们在一个非常小的团队中，代码库的大小和复杂性开始超出我们的管理能力。正因为如此，我们正在研究驯服它的方法，其中之一是将其转换为面向服务的架构 - 即，将其拆分为几个较小的应用程序。

这种方法的问题在于报告方面:我们的报告通常涉及多达 7 个连接的表，过滤器沿途作用于多个表。如果我们放弃服务共享表的可能性(在多篇文章中说明这是一种反模式)，是否有可能以一种不会对性能造成太大影响的方式连接所有这些数据？

那么，SOA 是针对此类问题推荐的方法吗？或者它带来的问题多于解决的问题？

虽然我们的专长主要在于 Ruby(Rails 和 Sinatra)和 Python(Plone 和 Grok)，但我也想知道其他技术(.NET、Java)周围的社区通常如何处理这个问题。

提前致谢!

Answer 1

我来自数据仓库背景，对 ruby​​/rails 保持一些兴趣。
阅读您的帖子，我有一种感觉，您的报告架构可能需要重新设计，并脱离基本系统。

重新设计该部分后，也许您的原始系统不会那么大/复杂。

简而言之，一个通过 7 个连接级别的报告要求让我感到“尴尬”，看起来您正在尝试使用您的事务系统进行报告？

我建议您使用预先计算好的聚合转移到不同的模式/数据库(当然，杠杆率将取决于您的业务案例)。这应该有助于降低基本系统的复杂性，并允许您更快和相对简单的报告环境。您可能会产生一些存储成本(对于 aggs env 的单独 db/schema)，但这对于简单性/设计来说应该是很小的代价。

第