用户统计：“交互式计算”或批量计算+缓存
我有一个项目，计算用户性能的一些‘统计’，然后将其显示给他们。所有这些统计数据最终都来自一个记录用户与网站交互的大型“交互表”。目前，所有这些统计数据都是通过查看这些数据来计算的。我们广泛使用持久缓存来保持这一过程的快速进行。
我们正在考虑一种‘迭代设计’，将统计值存储在数据库中，在记录每个交互时，我们根据交互对每个分数的贡献来更新值，所以我们本质上是在迭代更新值。(现在我们只是弄脏了缓存)。
我看到了迭代设计的一些问题，因为这意味着我们在数据库中存储了这些冗余的、可能不同步的信息，这使得添加新的统计数据变得困难，并意味着在每个交互日志上进行更多的工作。好处是，它简化了统计查找，以单一的数据库命中！
这种迭代设计中的一些东西给我敲响了警钟，但我不能否认潜在的节省时间的好处。我是应该听从这种直觉，还是应该去做呢？
回答 3
Stack Overflow用户
发布于 2009-09-21 23:53:05
当我进行数据库设计时，我尽量避免存储冗余数据。(毕竟，这是数据库规范化的目标)。计算列和视图是OK的-它们由SQL server自动管理和更新。就我个人而言，在使用DB进行缓存之前，我会倾向于使用其他方法( SQL查询真的是需要改进性能的部分吗？我可以通过使用SQL视图来简化应用程序中的事情吗？等)
当您说操作数据时，您执行的是什么操作，成本如此之高？你是说插入/更新/删除吗？如果统计数据的使用是写密集型的，则可以考虑删除索引以加快数据更改。
Stack Overflow用户
发布于 2009-09-22 00:01:39
Would触发器很有帮助，因为只要有新的数据进来，你就可以进行计算，这样就不会有陈旧的数据。
只有在读操作比写操作高得多的情况下，这才有用。如果我为每次读操作做两次写操作，那么这将是一个糟糕的设计。
更多关于您正在做的事情的详细信息将会有所帮助
Stack Overflow用户
发布于 2009-09-22 00:15:54
在插入的基础上计算当然是可行的，IMHO。
要解决不能立即生成新统计数据的问题(因为您没有计算出的数据)，您可以：
- 对新的stat offline
运行批量报告
或
- 动态计算并与缓存
合并
根据您的缓存模型，统计数据可能不同步，也可能不同步。如果它使用触发器，那么它会立即发生(在插入到tblFoo update tblFooStats时)；但是您可以根据需要检索它。
我认为唯一真正的风险是如上所述:不能立即添加新的统计/计算。如果你涵盖了这个，生活应该是相当美好的。
https://stackoverflow.com/questions/1457448
复制相似问题
腾讯云开发者
