Design patterns 用户统计数据："；“交互计算”；或批量计算+；缓存

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

我们正在考虑转向一种“迭代设计”，在这种设计中，统计值存储在数据库中，在记录每个交互时，我们根据交互对每个分数的贡献来更新值，因此我们本质上是迭代更新值。（现在我们只是弄脏了缓存）

我发现迭代设计存在一些问题，因为这意味着我们在数据库中存储了这些冗余的、可能不同步的信息，这使得添加新的统计数据变得困难，并且意味着在每个交互日志上都要做更多的工作。不过，它的好处是简化了统计查找到单个db命中

---

这种迭代设计中的某些东西给我敲响了警钟，但我不能否认它潜在的节省时间的好处。我应该遵从这种直觉，还是继续去做呢？

当我在做数据库设计时，我尽可能避免存储冗余数据。（毕竟，这是数据库规范化的目标）。计算列和视图正常-它们由SQL server自动管理和更新。就个人而言，在使用DB进行缓存之前，我会倾向于其他途径（SQL查询真的是需要提高性能的部分吗？我可以使用SQL视图简化应用程序中的事情吗？等等）

---

当你说操纵数据时，你正在执行的是什么操作如此昂贵？你是说插入/更新/删除吗？如果你对统计数据的使用是写密集型的，你可以考虑删除索引来加快数据的变化。

会触发帮助，因为你可以在新数据进入时进行计算，这样就不会有过时的数据。 不过，这只有在读取值远高于写入值时才有帮助。如果我每次读写两次，那么这将是一个糟糕的设计

---

关于你正在做的事情的更多细节将很有帮助

在插入的基础上进行计算当然是一条路，伊姆霍

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

• 脱机运行新统计上的批量报告

或

• 动态计算并与缓存合并

根据缓存模型的不同，统计数据可能不同步，也可能不同步。如果使用触发器，则会立即发生（插入

tblFoo

update

tblFooStats

）；但您可以根据需要检索此文件

---

我认为唯一真正的风险是：无法立即添加新的统计数据/计算。如果你涵盖了这一点，生活应该很美好。

一些数字：每个统计数据都是从几百行和几db点击数计算出来的。尽管被称为统计，但数字处理并不重要，真正的性能瓶颈是操作数据。实际上，不是数据库操作，我只是指从200行左右的数据中提取数据，从中提取我想要的数据（有时它是特定值的所有unqiue现象，有时它是匹配某个值的部分行数的计数，等等）。所有这些都不涉及数据库写入，只有在记录内容时（此时！）。在这种情况下，您最好添加索引，而不是删除它们。=）在这样做之前，性能问题是否来自多个数据库命中？还是正在运行的查询速度缓慢？或者只是返回结果的数量？如果问题来自多个DB命中或计算/提取所需数据的方式，则可以通过将逻辑移动到视图/公共表表达式（SQL Server）/用户定义函数/存储过程来解决。我不是说在数据库中缓存数据是错误的，只是说这是我最后的选择。触发器/信号将是我触发迭代更新的方式！写入仅在从用户交互记录数据时发生（此时）。统计计算不涉及写操作。因此，总体而言，它是一个读密集型应用程序。