用于计算 0 年至第 n 年的数据和软件架构答案

【问题标题】：data and software architecture for calculations from year 0 - year n用于计算 0 年至第 n 年的数据和软件架构
【发布时间】：2011-08-19 00:31:58
【问题描述】：

例如，我们的应用程序会跟踪农场的动物活动和价格。要获得当前的库存数量，最简单的解决方案是有一个起始编号，然后将所有进出的移动相加，直到我们得到一个当前编号。但这会占用大量内存，并且随着移动次数的逐年增加而变得越来越慢。

我们没有“冻结”一年的奢侈，所以它不能再接受变化，系统必须能够随时处理运动的变化，然后实时显示更新的数字。

这不仅仅是股票数量；我们必须跟踪大量这样的变量，并为每个时期（日、周、月、年）编写报告，其中包括基于这些变量的汇总计算。

为了计算和报告目的，处理跨越多年的数据流的最常见、首选、“最佳”、最快、最优雅的方法是什么？在这种情况下，数据库设计和架构将如何关联（即，只要数据库模式设计良好，使用 ORM 就可以了吗？）。这里的关键要求是最佳性能和实时可用性。

我已经在大型系统中看到过这样的工作被分成时间片，例如周、月、年汇总表。如果有解决这个问题的通用设计模式，我特别感兴趣。

【问题讨论】：

"要获得当前的库存计数，最简单的解决方案是有一个起始编号，然后将所有进出的移动相加，直到我们得到一个当前编号。但这会占用大量内存并且会变得更慢并且随着移动数量逐年增长，速度会变慢。”难道你不能只计算给定时间点的计数（比如每年），保存它，然后你只需要添加最近的更改 - 而不是整个历史记录？
是的，我可以做到。但是，如果构成“每年”的数字发生变化，则需要重新计算。所以我的问题与我是否聚合成周、月（周聚合）、年（月聚合）有关，然后如果我更改某一周，我只需更新受影响的切片（相关的周、月和年聚合）需要重新计算其他月份或年份。
我想我假设前几年的历史数据不会发生变化，而当前年份/月份会发生变化 - 但一年的数据总量不会太可怕了。

【解决方案1】：

我会在数据库中进行聚合，因为这通常是他们非常擅长的。

查看OLAP（与OLTP）数据库设计。

【讨论】：

【解决方案2】：

我会使用 SQL 数据库 (PostgreSQL)。 RDBMS 在这些方面非常快:)

将所有历史记录提取为 ORM 对象，然后将其相加，从长远来看，应用程序可能无法正常工作。您必须使用在 RDBMS 中完成大部分统计工作的 SQL 查询。当然，您仍然可以使用 ORM 来显示和编辑对象。

我认为该解决方案对于预期的数据量应该是相当安全的，并且可以通过适当的索引和更多内存来扩展 RDBMS。

您还可以预先制作大量随机数据并测试可扩展性。

【讨论】：

jkj 是正确的，只要记录数为数百万且不超过数十亿。当它发生时，你会发现摘要需要永远。 “疯狂的数据量”是一个有问题的术语——在旁观者的眼中是疯狂的。所以，如果你在这里处理 real 疯狂的金额，我会进一步解释。
是的，我的问题与数据库设计和 ORM 有关。 IE。在数据库中进行聚合，并将聚合数据拉入 ORM 层。

【解决方案3】：

可能只有一种通用方法 - 拆分工作。

您可以及时拆分并在某个低负载期间定期计算聚合并将它们存储在单独的表中。对于某些聚合函数，您甚至可以根据短期聚合计算长期聚合，而不会丢失精度。

您也可以在空间中拆分它 - 有一些解决方案使用分布式数据库和 map-reduce 引擎的组合 - 以 Apache Pig 为例。这种方法需要大量学习和学习，但您应该获得更好的可扩展性。

您首先应该知道的是您的读：写比率以及您想要运行的查询类型。

【讨论】：