基于 Web 应用程序中的事务数据以可扩展的方式计算结果？

Posted 2023-02-23

【中文标题】基于 Web 应用程序中的事务数据以可扩展的方式计算结果？

【英文标题】：Calculating results in a scalable way based on transaction data in web app?

【发布时间】：2011-10-22 17:58:24

【问题描述】：

可能重复：Database design: Calculating the Account Balance

我使用存储交易数据的网络应用程序（例如“日期 y 的金额 x”，但更复杂）并根据所有相关交易的详细信息提供计算结果[1]。我们投入了大量时间来确保这些计算高效执行，因为它们是应用程序的交互部分：即用户单击按钮并等待查看结果。我们有信心，对于当前的数据水平，我们可以优化数据库获取和计算，以在可接受的时间内完成。但是，我担心随着交易数量的增长[2]，所花费的时间仍会线性增长。我想说的是，我们可以处理数量级以上的事务，而不会过度降低性能。

我正在寻找可以提高基于交易数据的计算的可扩展性的有效技术、技术、模式或算法。

然而，任何建议都存在实际和重大的限制：

我们目前必须支持两个高度不兼容的数据库实现，mysql 和 Oracle。因此，例如，使用特定于数据库的存储过程的维护成本大约是其两倍。 实际交易比给出的示例交易复杂，计算涉及的业务逻辑复杂，并且有规律的变化。因此，将计算直接存储在 SQL 中并不是我们可以轻松维护的。 之前保存的任何交易都可以随时修改（例如交易日期可以向前或向后移动一年），并且预计会立即更新计算。这会对缓存策略产生连锁反应。 用户可以跨大空间、多维度进行查询。解释一下，考虑能够计算任何给定日期的结果，对于任何特定的交易类型，其中交易被几个任意条件过滤。这使得预先计算用户希望看到的结果变得很困难。 我们的应用程序的一个实例托管在客户的公司网络上，在他们的硬件上。因此，我们不能轻易在 CPU 和内存方面的问题上花钱（即使这些实际上是瓶颈）。

我意识到这是非常开放和笼统的，但是......

对于实现可扩展的解决方案有什么建议吗？

[1] 其中“相关”可以是：查询的日期；交易类型；用户类型；配方选择；等等 [2] 诚然，这比之前的性能有所改进，在之前的性能中，ORM 的 n+1 问题所花费的时间呈指数增长，或者至少是更陡峭的梯度。

【参考方案1】：

我曾针对类似的要求工作过，并提出了一些建议。这在很大程度上取决于您的数据的可能性。很难让每个案例都能快速想象，但您可以针对常见案例进行优化，并为其他案例提供足够的硬件资源。

总结

我们每天、每周和每月都会创建摘要。对我们来说，大部分交易都发生在当天。旧的交易也可以改变。我们保留了batch，并在此之下记录了个人transaction。每个批次都有一个状态来指示是否可以使用事务摘要（在表batch_summary 中）。如果汇总批次中的旧事务发生更改，则作为此事务的一部分，batch 将被标记以指示该汇总不可信任。后台作业稍后会重新计算摘要。

然后，我们的软件会在可能的情况下使用摘要并回退到没有摘要的单个交易。

我们玩弄了 Oracle 的物化视图，但最终推出了我们自己的摘要流程。

限制要求

您的要求听起来很广泛。将所有查询字段放在网页上并让用户选择字段和输出结果的任意组合可能是一种诱惑。这使得优化非常困难。我建议深入挖掘他们实际需要做的事情，或者过去做过的事情。查询非选择性维度可能没有意义。

在我们针对某些查询的应用程序中，将日期范围限制为不超过 1 个月。我们已将一些功能与基于日期的摘要对齐。例如您可以获得整个 2011 年 1 月的结果，但不能获得 2011 年 1 月 5 日至 20 日的结果。

为缓慢的操作提供用户界面反馈

有时我们发现很难将某些内容优化到少于几分钟。我们将工作交给后台服务器，而不是加载非常慢的网页。当我们得到答案时，用户可以发出请求并继续他们的业务。

【参考方案2】：

我建议使用物化视图。物化视图允许您像存储表一样存储视图。因此，您需要完成的所有复杂查询都是在用户查询之前预先计算好的。

当它基于的表发生变化时，棘手的部分当然是更新物化视图。这里有一篇很好的文章：Update materialized view when urderlying tables change。

如果没有 MySQL 中的插件，物化视图（还）不可用，否则实现起来非常复杂。但是，既然您有 Oracle，我建议您查看 link above，了解如何在 Oracle 中添加物化视图。

【讨论】：

感谢您的回答。不幸的是，数据库供应商的粗略支持是一个问题，因为我们正在积极支持 Oracle 和 MySQL。