Database design 第0年至第n年计算的数据和软件体系结构

例如，我们的应用程序跟踪农场的动物活动和价格。要获得当前库存数量，最简单的解决方案是有一个起始编号，然后将所有进出的移动相加，直到我们有一个当前编号。但这是一种记忆密集型的运动，随着运动次数的逐年增加，速度越来越慢

我们没有“冻结”一年的奢侈，因此它不能再接受变化，系统必须能够在任何时间点处理变化，然后实时显示更新的数字

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

为了计算和报告目的，处理跨越多年的数据流，最常见、首选的“最佳”、最快、最优雅的方法是什么？在这个场景中，数据库设计和体系结构如何关联（即，只要数据库模式设计良好，使用ORM是否合适？）。这里的关键要求是最佳性能和实时可用性

---

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

我会选择SQL数据库（PostgreSQL）。RDBMS在这些方面非常快：）

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

我认为这个解决方案应该是非常安全的，有预期的数据量，并且RDBMS可以通过适当的索引和更多的内存进行扩展

---

您还可以预先生成大量随机数据并测试可伸缩性。

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

您可以在时间上拆分它，，并在低负载的某个时段内定期计算聚合，并将其存储在单独的表中。对于某些聚合函数，您甚至可以从短周期聚合计算长周期聚合，而无需降低精度

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

---

您首先应该知道的是您的读写比率以及您希望运行的查询类型

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

---

看看（vs）数据库设计

“要获得当前的库存数量，最简单的解决方案是有一个起始数字，然后将所有的进出量相加，直到我们有一个当前的数字。但这是内存密集型的，并且随着移动量逐年增加而变得越来越慢。”难道你不能只计算到给定的时间点（比如每年）的数量吗，保存它，然后您只需要添加最近的更改-而不是整个历史记录？是的，我可以这样做。但如果构成“每年”的数字发生变化，就需要重新计算。因此，我的问题是，我是否将其聚合为周、月（周的聚合）、年（月的聚合），然后如果我更改某个周，我只会更新受影响的切片（相关的周、月和年的聚合）不需要重新计算其他月份或年份。我想我是在假设前几年的历史数据不会发生变化，当当前年份/月份发生变化时——但一年的总数据量不会太大。只要记录数达到数百万，且不会跨越数十亿，jkj就是正确的。当它出现时，你会发现总结要花很长时间。“疯狂的数据量”是一个有问题的术语——疯狂在旁观者的眼中。所以，如果你在这里处理的是真正疯狂的数量lmk，我会进一步解释。是的，我的问题与数据库设计和ORM有关。例如，在数据库中进行聚合并将聚合数据拉入ORM层。目前，我倾向于在时间上进行拆分，创建周、月、年聚合表，每次数据更改都只更新受影响的切片。