Ruby on Rails数据库和应用程序设计

Question

我们必须基于大型数据库创建相当大的Ruby on Rails应用程序。这个数据库每天更新，每个表格有大约500 000条记录（或更多），这个数字会随着时间的推移而增长。我们还必须提供所有数据的正确版本以及参照完整性。用户必须能够从版本移动到版本，这是在不同时间点的主数据库的“快照”。另外，某些数据部分需要通过API与其他外部应用程序一起提供。

考虑到大量的数据，我们认为拆分数据库的成片：

1. 在当前时间的数据的国家

2. 每个表

3. 快照第一的版本控制的属性数据库在特定的历史时间点

每个人都有它自己的应用程序，用API创建一个服务与数据进行交互。这是需要的，因为我们不想创建多个应用程序直接连接到多个数据库。

问题是：这是正确的做法吗？如果不是，你会建议什么？

我们从来没有对这个规模的项目有任何经验，我们正在努力寻找最好的解决方案。我们不知道这种数据分离是否有意义。如果是这样，如何提供不同应用程序与个人服务以及服务之间的适当通信，因为这也是必需的。

Answer 1

一般而言，表格中的数据量不应该是您首先关注的问题。在PostgreSQL中，您有大量的选项来优化针对大型表的查询。更大的问题与你究竟在询问什么，何时以及为什么有关。您的查询负载总是比数据量更大。拥有长达4M行的十年财务数据是一回事。将这些十年的数据进行汇总以确定支票账户余额是多少有所不同。

总的来说，听起来像你正在尝试创建一个依赖此类聚合的系统。在这种情况下，我推荐以下方法，我称之为log-aggregate-snapshot。在这方面，您基本上有三个互补模型，它们一起工作以提供最新的表现良好的解决方案。然而，对此的限制对于认识和理解很重要。

1. 事件模型。这是仅附件，没有更新。在这个模型中插入会发生，并且仅仅根据绝对需要更新一些用于某些查询的元数据。对于财务应用程序，这将是表示日记帐分录和行的表格。

2. 集合结束模型。这是仅限于追加（尽管删除允许用于重新开放期间）。这为特定目的提供前滚信息。关闭条目一旦进入，关闭期间不能进行条目。在财务申请中，这将代表期末余额。新的余额可以通过从汇总点开始并向前滚动来计算。您也可以使用部分索引，以便更轻松地提取所需的数据。

3. 辅助数据模型。这包括允许更新，插入和删除的较小的表，只要其他模型的完整性不受影响。在金融应用中，这可能是客户或供应商数据，员工数据等等。