Rails 问一个 ruby-china 的 notification 的效率问题

xranthoar · 2012年05月26日 · 最后由 ashchan 回复于 2012年05月27日 · 3239 次阅读

现在 ruby-china 的通知是一个单独的表,和用户做关联,基于通知多样性的原因用了一个叫做 Notification::Base 的基类,

class Notification::Base
  include Mongoid::Document
  include Mongoid::Timestamps::Created
  include Mongoid::BaseModel
  # ...
  belongs_to :user
  # ...
end

另外一种比较常见的处理方法是 embed 在 user 里,后者的查询时间是 O(1) 的,前者会随着表的增大速度变慢,ruby-china 有否考虑过这点,有考虑 ? 如何考虑的 : 考虑一下吧。 @huacnlee

不懂 mongodb,弱弱问一句,按照这个理论,所有和 user 关联的表都可以 embed 到 user 表里面,然后查询时间都 O(1)了。这样理解对吗

@hooopo embed 的东西关联性很弱,因为是不成表直接存在 document 里的,所以不能直接找到,必须先找到 User 才能找到 Notification(如果 embed),所以 has_many :notifications 这种东西就不能直接写了,所以不可能都 embed 进来的。如果确定是比较单一的联系,比如评论几乎只和新闻相关,于是 embed 在新闻里,是非常合适的。

数据太多 (之前我的通知就有 100 页),嵌入不合适。另外一点就是目前这样速度挺好的,分离出来干干净净

@huacnlee 那我就比较放心了。。之前一直在纠结要效率还是要清爽。。

当然要清爽啊

@xranthoar ruby-china 的 notification 都是只有一个接收者,所以可以把 read 写到 notification model 里,咱们的是多接收者的,如果也把 read 写到 notification model 的话,就相当于是一个多对多的关系,这样每次获取某个用户的所有通知时,判断是否已读的代价会不会很高(通知接收者可能很多)?

@xranthoar 也许用一些假数据做测试才能回答这种性能问题,做好索引也许也会有帮助。

mongo 中如果一条数据 embed 的数据很多会出问题的,比如我们以前就碰到过单条 document 超过 16m 的问题。。。还有其他一些问题

@richarddong 目前还挺快的,慢了再说

@huacnlee 嗯,我和 @xranthoar 一起给学校做网站,在讨论提醒的实现机制 = =

#8 楼 @donnior 纯文本应该不至于吧。。

embed 在 User 里面 user object 就会变大,试想这个帖子页面为了显示每个回帖用户都把他的消息都载入进来。为了避免无关的地方载入了消息,又要把所有查询 except 掉 notification……考虑到读消息是少数操作,所以应该分离出去。

有个可以优化的地方是把 unread_notification_count 加到 User 里面。

#12 楼 @Rei embed 文档过大是个很实际的问题。我在项目中遇到需要用又要考虑大小和查询的时候,一般会做成 1 to 1 的文档里去存。如 user has one user_notifications,然后 user_notifications 里去内嵌数据,主键手工设成跟 user 一样。这样即保留 embed doc 的优势,又避免单一文档过大,额外带来方便(分 collection)备份的好处。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号