用 mongodb 储存多态消息/提醒类数据（转）

前天看到 javaeye 计划采用mongoDB实现网站全站消息系统，很有同感，mongodb 很适合储存消息类数据。之前讨论了如何构建一个微博型广播，这次讨论一下怎么储存消息/提醒类数据。

下面的内容不涉及关于海量数据储存的问题，只讨论数据模式。

1. 需求

消息/提醒类数据有不少例子，比如豆瓣的好友广播（我说、电影/书籍已读状态、网址推荐等），Twitter 的推信息 Tweet，SNS 的好友状态。

这类信息的一个特点是模式多变，豆瓣的好友广播有好几种模式，“我说”以用户发布的文本为主；动作消息（上传了什么）不带文本，但是需要关联别的数据，例如书本，图片；推荐消息则要带文本和关联数据。Twitter 推信息则需要保存多样的信息，比如 mention 到的用户、回复到哪条推、附带的 url、地理位置，但这些数据有时是为空的。可以在这里看读取一个 twitter 消息会带有多少内容。

总的来说，关键词就是“多变”，并且随着应用的升级，状态信息还会增加更多模式和更多的项。

2. 使用 Mongodb 储存多态的消息

现在直接拿 CodeCampo 的例子来说明怎么用 Mongodb 储存这类多态的数据。Campo 的代码使用 Ruby on Rails 和 mongoid，完整的代码可以在 github 仓库看到。

CodeCampo 中对消息的定义是建议用户立即查看，阅后即焚，并且过期会被删除的，所以设计为内嵌入 user 文档中储存，并且有数量限制（自动删除最旧的）。如果需要持久的储存消息（比如微博消息），可以用引用(DbRef）取代内嵌（Embed），将 notification 单独储存在一个 collection。

2.1 mongodb 中的模式

理想中 mongodb 会这样保存 notification 的数据。（注：Notification::Follower 和 Notification::Other 并未实现，只是用作举例）

> db.users.findOne()
{
    _id : ObjectId(...),
    ...
    notifications : [
        {
            _id : ObjectId(...),
            _type : 'Notification::Mention',
            replyer_id : ObjectId(...),
            topic_id : ObjectId(...),
            reply_id : ObjectId(...),
            text : '@rei some message'
        }
        {
            _id : ObjectId(...),
            _type : 'Notification::Follower',
            follower_id : ObjectId(...)
        }
        {
            _id : ObjectId(...),
            _type : 'Notification::Other',
            Other_column : 'value'
        }
    ]
}

2.2 用 Mongoid 实现

如果你熟悉 Mongodb，应该对怎么操作上面的文档有了大概的想法。这里展示一下用 mongoid 实现这样的数据结构的方法（如果你不熟悉 mongoid，可能需要看它的文档，特别是继承章节。）

首先建立一个 Notification::Base 用于和 User 建立关联。

class Notification::Base
  include Mongoid::Document
  include Mongoid::Timestamps

  field :text

  embedded_in :user, :inverse_of => :notifications
end

当别的类继承 Notification::Base，会继承其所有关联定义。

然后在 User 中定义 embed。

Class User
  include Mongoid::Document
  include Mongoid::Timestamps

  ...
  embeds_many :notifications, :class_name => 'Notification::Base'
  ...
end

现在，可以用 @user.notifications.create(attributes) 的方法建立一个消息提醒了。但默认使用的 Notification::Base 并不是最终需要创建的消息类型，所以继续新建一个 Notification::Mention。

class Notification::Mention < Notification::Base
  referenced_in :topic
  referenced_in :reply
  referenced_in :reply_user, :class_name => 'User'
end

注意这个 Mention 类中并没有定义和 user 的 embed 关系，但因为它继承了 Notification::Base，所以将 Base 的模块和 embed 关联一并继承了。Mention 类只需要定义自有部分的逻辑。

现在，创建一个 Mention 消息的 Ruby 代码会是这样：

@user.notifications.create({:reply_user_id  => user_id,
                            :topic_id       => topic_id,
                            :reply_id       => reply_id,
                            :text           => 'summary text',
                            Notification::Mention)

保存到 mongodb 中的数据如下

> db.users.findOne()
{
    _id : ObjectId(...),
    ...
    notifications : [
        {
            _id : ObjectId(...),
            _type : 'Notification::Mention',
            replyer_id : ObjectId(...),
            topic_id : ObjectId(...),
            reply_id : ObjectId(...),
            text : 'summary text'
        }
        ....
    ]
}

保存的数据跟理想中的一样。需要新增消息类型，就仿照 Notification::Mention，建立新的 Notification::Base 子类就可以了。

3. 用 SQL 数据库如何实现？

豆瓣和 Twitter 都是使用 MySQL 储存广播和推数据，那么他们是怎么实现这样多态的数据结构呢？我并不知道他们的内部情况，不过 SQL 如何实现多态也有不少文章（例如铁道书里面介绍 ActiveRecord 就支持多态和继承），这里举一些方案做对比。

alt text

3.1 单表继承

简单的说就是把一个表映射到不同的模型上。怎么做到的呢？方法是在一个表内保存整个继承体系涉及的所有字段。例如

notifications(id, type, user_id, reply_id, topic_id, replyer_id, text, ...）

区别消息类型的字段就是 type，在应用层根据 type 的不同应用不同的逻辑。但是，即使某类消息（例如 follower 提醒）并不使用所有的字段，它都需要以数据库一行记录的方式保存在库中。

显而易见，这样会带来大量的空字段，影响表的纯洁性。即使尝试对一些字段进行合并重用，随着应用的发展，渐渐还是会带来维护和迁移的麻烦。需要指出的是，即使用方法2的多态关联，也有可能为了减少表的数量而渐渐走入字段重用的歧路。

3.2 多态关联

另一种实现异构对象聚合的方法是多态关联。它的原理是用一张表某个字段多态的引用多个表。例如：

notifications(id, user_id, type, entry_id)
mention_nofitications(id, reply_id, topic_id, replyer_id, text)
follower_notifications(id, follower_id)
other...

关联的逻辑依赖 notifications 的 type 和 entry_id 字段，type 的值可以取 “mention”、"follower"等等消息的类型，从而选择读取哪一个 xxx_notifications 表的数据。

多态关联很好的维护了表的纯洁性，但有一个缺点就是无法使用 JOIN 查询，会导致 N + 1 查询问题（也许SQL专家可以告诉我怎么在一个查询查出不同类型的消息，但可以预计SQL的逻辑比较复杂，而且JOIN的表太多也会影响效率）。

如果使用这种方法，最好给数据库加上一个缓存层，缓存取出的完整消息数据，减少数据库查询。Twitter 有一个 Row Cache 层，估计就是用来干这事。

3.3 序列化后保存

还有一种方案是将各种字段序列化后储存，每次读取出来先反序列化后判断内容类型。这样就可以节省很多表字段，也避免 N + 1 查询的问题。

notifications(id, user_id, serialized_entry)

这种方案其实也不错，一个缺点是不便于做后续处理，比如用序列化来保存一个推特信息的 mention 用户ID，那么就无法反过来查询有哪条信息 mention 了某用户。这样就要把需要查询的信息独立为字段，无法避免一些情况下空字段的问题。

4. 总结

比较了上面几种多态数据的实现方案之后，还是认为 MongoDb 的方案较为优雅。SQL 数据库在储存复杂结构的数据时，通常需要一个缓存层来掩护。而 MongoDb 内建对复杂结构的储存支持，开发的难度就小一些（少一个层，少一个烦恼）。所以用 MongoDb 开发 web 程序，真的能减少不少技术成本。

限于视野，可能有些好的方法我未曾见过和想过，欢迎留言告诉我这些方法。