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

Question

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

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

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

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

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

我意识到这是非常开放的和一般的，但是......

是否有任何关于实现可扩展解决方案的建议？

[1]'相关'可以是：查询的日期;交易类型;用户类型;配方选择;等
[2]不可否认，这是对以前性能的改进，其中ORM的n + 1问题使得时间呈指数增长，或者至少是更陡峭的梯度。

Answer 1

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

<强>综述

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

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

我们使用了Oracle的物化视图，但最终还是推出了自己的摘要流程。

限制要求

您的要求非常广泛。可能存在将所有查询字段放在网页上并让用户选择字段和输出结果的任意组合的诱惑。这使得优化非常困难。我建议深入研究他们实际需要做什么，或者过去做过什么。查询非常无选择的维度可能没有意义。

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

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

有时我们发现很难将某些东西优化得短于几分钟。我们在后台服务器上工作，而不是加载非常慢的网页。在我们得到答案的同时，用户可以发起请求并开展业务。

Answer 2

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

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

物化视图在MySQL中没有插件时尚未可用，并且实现起来非常复杂。但是，由于您有Oracle，我建议您查看link above以了解如何在Oracle中添加实体化视图。