我们必须基于大型数据库创建相当大的 Ruby on Rails 应用程序。该数据库每天更新，每个表大约有 500 000 条记录（或更多），并且这个数字会随着时间的推移而增长。我们还必须提供所有数据的正确版本以及参照完整性。用户必须可以从一个版本移动到另一个版本，这是主数据库在不同时间点的“快照”。此外，部分数据需要通过 API 提供给其他外部应用程序。
考虑到大量数据，我们考虑将数据库拆分为多个部分：
当前数据状态
每个表的版本化属性
第一个数据库在特定历史时间点的快照
每一个都有自己的应用程序，创建一个带有 API 的服务来与数据交互。它是必需的，因为我们不想创建多个应用程序直接连接到多个数据库。
问题是：这是正确的方法吗？如果没有，你有什么建议？
我们从未有过如此规模的项目的任何经验，我们正在努力寻找可能的最佳解决方案。我们不知道这种数据分离是否有任何意义。如果是这样，如何提供不同应用程序与单个服务以及服务本身之间的适当通信，因为这也是必需的。
一般来说，表中的数据量不应该是您首先关心的问题。在 PostgreSQL 中，您可以使用大量选项来优化针对大型表的查询。更大的问题与您查询的具体内容、时间和原因有关。您的查询负载总是比数据量更大的问题。拥有 400 万行的 10 年财务数据是一回事。必须汇总这十年的数据以确定支票账户的余额是不同的。
一般来说，在我看来，您正在尝试创建一个依赖于此类聚合的系统。在这种情况下，我推荐以下方法，我称之为 log-aggregate-snapshot。在此，您基本上拥有三个互补的模型，它们协同工作以提供最新的、性能良好的解决方案。然而，这方面的限制对于认识和理解是很重要的。
事件模型。这是仅附加的，没有更新。在此模型中，插入发生，并且仅在绝对需要时更新用于某些查询的某些元数据。对于财务应用程序，这将是表示日记帐分录和行的表格。
聚合关闭模型。这是仅附加的（尽管出于重新开放期间的目的允许删除）。这为特定目的提供前滚信息。一旦进入关闭条目，就不能在关闭期间进行条目。在财务应用程序中，这将代表期末余额。可以通过从聚合点开始并向前滚动来计算新余额。您还可以使用部分索引来更轻松地仅提取您需要的数据。
辅助数据模型。这由较小的表组成，这些表允许更新、插入和删除，前提是不影响其他模型的完整性。在财务应用程序中，这可能是客户或供应商数据、员工数据等。