用户统计：交互式计算或批量计算+缓存。

Question

我有一个项目，它计算用户表现的“统计数据”，然后向他们展示。所有这些统计数据最终都来自一张记录用户与网站交互的大型“交互”表。目前，所有这些统计数据都是通过查看此数据进行计算的。我们广泛使用持久性缓存来使这些事情保持快速。

我们正在考虑采用“迭代设计”，其中统计值存储在数据库中，并且在每次记录交互时，根据该交互对每个分数的贡献更新值，因此我们实际上是迭代更新值。（现在我们只是使缓存变脏）。

我认为迭代设计存在一些问题，因为它意味着我们在数据库中存储了这些冗余的、潜在不同步的信息，这使得添加新的统计数据变得困难，并且意味着在每个交互日志上需要更多的工作。但好处是简化了统计数据查询，只需单个数据库访问！

这种迭代设计中的某些内容引起了我的警觉，但我不能否认潜在的节省时间的好处。我应该听从这种直觉，还是继续做呢？

- Chris

---

一些数字： 每个统计数据都是从几百行和几个数据库查询中计算出来的。尽管被称为统计数据，但数字处理并不重要，真正的性能瓶颈在于数据操作。 - Chris

Answer 1

在进行数据库设计时，我尽可能避免存储冗余数据（这毕竟是数据库规范化的目标）。计算列和视图是可以的 - 这些由SQL服务器自动管理和更新。个人而言，在使用DB进行缓存之前，我会倾向于使用其他途径（SQL查询是否真的需要性能改进？我是否可以通过使用SQL视图简化应用程序等）。

当你说操作数据时，你执行的是哪种昂贵的操作？你是指插入/更新/删除吗？如果您对统计数据的使用是写入密集型的，则可以考虑删除索引以加快数据更改速度。

- RMorrisey

---

没有实际的数据库操作，我只是指提取大约200行数据，从中获取我想要的内容（有时是特定值的所有唯一出现次数，有时是匹配某些内容的行的零件编号计数等）。这些都不涉及数据库写入，只有在记录东西时才会进行（目前如此！）。 - Chris

在这种情况下，您最好添加索引，而不是删除它们。=）在此之前，您需要确定性能问题是由于多个数据库查询引起的吗？还是查询运行缓慢？或者只是返回结果的数量太多？如果问题来自于多个数据库查询或者数据计算/提取方式，您可以通过将逻辑移动到视图/公共表达式（SQL Server）/用户定义函数/存储过程中来解决它。我并不是说在数据库中缓存数据是错误的，只是对我来说这是最后的选择。 - RMorrisey

Answer 2

触发器是否有助于你，因为这样你可以在新数据到达时进行计算，从而避免过时的数据。

如果读取比写入高很多，那么这将非常有用。但是，如果每次读取都有两次写入，那么这将是一个糟糕的设计。

提供一些关于你正在做什么的更多详细信息会很有帮助。

- James Black

---

触发器/信号是我触发迭代更新的方式！目前，写操作仅在从用户交互记录数据时发生。统计计算不涉及写操作。因此，总体而言，这是一个更加读取密集型的应用程序。 - Chris

Answer 3

在插入基础上进行计算肯定是我认为的正确方法。

为了解决无法立即生成新统计数据的问题（因为您没有计算出的数据），您可以选择：

• 离线运行新统计报告

或者

• 实时计算并与缓存合并

根据您的缓存模型，统计数据可能会不同步，也可能不会。如果使用触发器，则会立即发生（在插入到tblFoo更新tblFooStats）；但是您可以根据需要检索此信息。

我认为唯一的真正风险就是如上所述：无法立即添加新的统计/计算。如果您解决了这个问题，生活应该会很愉快。

- Noon Silk