在我的 Web 应用程序中，我的用户有很多事件。一个这样的事件是“用户更新了 Facebook 状态”。一个用户可能有数百个这种类型的事件，并且有 10 种类型的事件。我需要以非常可扩展的方式显示基于事件的事件计数和其他用户统计信息。这是因为每个用户都可以看到他或她的统计数据。显然，我们无法在用户每次访问网站时都运行每个计算，因此缓存这些统计数据肯定是要走的路。
为“统计”创建一个单独的表是否有意义，该表将为我们缓存的每个统计数据提供一个用户 ID 和一个列？桌子本质上是在起作用，所以我想知道是否有更好或不同的方法来做到这一点。
【问题讨论】：
标签： database-design caching statistics
您可以只计算这些统计信息并将它们放入内存缓存中，根据需要读取/递增它们，因为这些数据不需要持久保存（冷缓存会导致服务器负载峰值，您可能会考虑限制速率登录/计算等）。然而，这种情况是非关系数据存储的理想候选者，例如Cassandra（“高度可扩展、最终一致、分布式、结构化的键值存储”）。 This internal Digg article 读起来很有趣：
根本问题是地方性的 关系数据库的思维方式，其中 将计算负担置于 读而不是写。这是 大规模网络完全错误 应用程序，其中响应时间是 批判的。情况变得更糟 大多数应用程序的串行性质。 页面的每个组件都阻塞在 从数据存储中读取，以及 操作的完成 来到它面前。
非关系型数据反向存储 这个模型完全，因为他们 没有复杂的读取操作 的 SQL。模型迫使你改变 您对写入的计算，而 将大多数读取减少到简单 操作——相当于 SELECT * FROM
Table.
【讨论】：