【问题标题】:Design question about Activity model / table关于活动模型/表格的设计问题
【发布时间】:2011-01-12 09:08:19
【问题描述】:

我有一个跟踪每个用户活动的活动模型。在这个模型中,我有以下列:id、user_id、media_id、type、created_at、updated_at

我特别关心的一个活动是歌曲视图。例如。当用户点击一首歌曲时,歌曲开始播放。与此同时,每次用户查看歌曲页面时,我的应用都会为此创建一个活动。

这意味着我可以为用户活动保留某种历史时间线。即

Foobar listened to Song A 2 hours ago
Foobar listened to Song A yesterday
Foobar listened to Song B 2 days ago
etc

将来,如果应用程序/网站获得大量人气,这会在某些方面影响数据库性能吗?我担心这个表会为每个查看歌曲的用户快速填充。我忍不住看 youtube 上的视频,每个视频的观看次数约为 100k ++。

我应该担心吗?还是只是为了添加索引并确保数据库可以在内存和磁盘空间方面进行扩展?

【问题讨论】:

    标签: ruby-on-rails database postgresql


    【解决方案1】:

    我认为活动模型做的太多了,因为您还存储数据,而这从不需要。

          table
    ------------------------
    user_id        int
    media_id       int
    listened_at    TIMESTAMP
    

    我省略了类型,因为这应该在 media_id 的上下文中

    如果您确实在每个视图中获得了很多点击,那么简单的数据库将无法处理这个问题。即使是事件数据库集群可能也有问题。但我实际上不会在早期担心这些事情。

    【讨论】:

    • 我在那里有一个类型字段的原因。是因为 type 可以是 View、Like、Comment 等。activity 模型的目的是存储所有类型的用户交互。如果您认为活动模型做得太多,您有什么建议? :-)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-09-10
    • 1970-01-01
    • 2020-02-20
    • 1970-01-01
    • 1970-01-01
    • 2012-08-16
    • 2010-12-01
    相关资源
    最近更新 更多