例如，我们的应用程序跟踪农场的动物活动和价格。要获得当前的库存数量，最简单的解决方案是有一个起始编号，然后将所有进出的移动相加，直到我们得到一个当前编号。但这是内存密集型的，并且随着移动数量的逐年增长而变得越来越慢。
我们没有“冻结”一年的奢侈，所以它不能再接受变化，系统必须能够随时处理机芯的变化，然后实时显示更新的数字。
这不仅仅是股票数量；我们必须跟踪大量这样的变量，并为每个时期（日、周、月、年）编写报告，其中包括基于这些变量的汇总计算。
为了计算和报告目的，处理跨越多年的数据流的最常见、首选、“最佳”、最快、优雅的方法是什么？在这种情况下，数据库设计和架构将如何关联（即，只要数据库模式设计良好，使用 ORM 就可以了吗？）。这里的关键要求是最佳性能和实时可用性。
我已经在大型系统中看到过这样的工作被分成时间片，例如周、月、年汇总表。如果有解决这个问题的通用设计模式，我特别感兴趣。
我会使用 SQL 数据库（PostgreSQL）。RDBMS 在这些方面非常快:)
从长远来看，将所有历史记录作为 ORM 对象，然后将其相加，应用程序可能无法正常工作。您必须使用在 RDBMS 中完成大部分统计工作的 SQL 查询。当然，您仍然可以使用 ORM 来显示和编辑对象。
我认为该解决方案对于预期的数据量应该是相当安全的，并且可以通过适当的索引和更多内存来扩展 RDBMS。
您还可以预先制作大量随机数据并测试可扩展性。
可能只有一种通用方法 -拆分工作。
您可以将其及时拆分并在某个低负载期间定期计算聚合并将它们存储在单独的表中。对于某些聚合函数，您甚至可以从短期聚合计算长期聚合，而不会丢失精度。
您也可以在空间中拆分它- 有使用分布式数据库和 map-reduce 引擎组合的解决方案- 以 Apache Pig 为例。这种方法需要大量的学习和学习，但您应该获得更好的可扩展性。
您应该知道的第一件事是您的读写比率和您想要运行的查询类型。