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