17

我开始一个 MongoDB 项目只是为了好玩,并作为学习 MongoDB/NoSQL 模式的机会。这将是一个实时聊天应用程序,堆栈包括:Rails 3、Ruby 1.9.2、Devise、Mongoid/MongoDB、CarrierWave、Redis、JQuery。

我将分别处理实时聊天轮询/消息队列。不确定如何使用 Node.js、APE 或自定义 EventMachine 应用程序。但是关于 Mongo,我正在考虑将它用于应用程序中的所有其他内容,特别是聊天日志和历史记录。

我的问题是如何最好地设计模式,因为我之前的所有经验都是使用 MySQL 和关系数据库模式。作为一个子问题,什么时候最适合我们嵌入文档和相关文档。

该应用程序将具有:

  • 拥有多个房间的多个帐户
  • 多个房间
  • 每个房间有多个用户
  • 允许用户进入的房间列表
  • 每个房间有多个用户聊天
  • 每个房间和每个用户的可搜索聊天日志
  • 给定聊天的可选文件附件

鉴于 Mongo(至少我上次检查时)的文档限制为 4MB,我不认为拥有房间集合并将所有房间聊天存储为嵌入式文档会很好。

从我到目前为止的想法来看,我正在考虑做类似的事情:

  • 帐户集合
  • 房间系列
    • 每个房间都与一个帐户相关联
    • 聊天室中所有聊天消息的聊天集合中的相关文档
    • 列出当前在房间内的所有用户的嵌入式文档
  • 用户集合
    • 列出用户当前所在的所有房间的嵌入式文档
    • 列出用户被允许进入的所有房间的嵌入式文档
  • 聊天合集
    • 每个聊天都与房间集合中的一个房间相关联
    • 每个聊天都与用户集合中的用户相关
    • 包含可选上传文件附件信息的嵌入式文档。

我主要关心的是我要走多远,直到这最终看起来像一个关系模式并且我打败了目的?肯定比嵌入更多相关。

另一个问题是引用相关文档比访问我听说过的嵌入文档要慢得多。

我想进行通用查询,例如:

  • 给我所有房间的帐户
  • 给我一个房间里的所有聊天(或按日期范围过滤)
  • 给我来自特定用户的所有聊天记录
  • 给我一个给定房间或给定组织的所有上传文件
  • ETC

关于如何以可扩展的方式有效地构建模式的任何建议?感谢大家。

4

2 回答 2

5

我认为你几乎走在正确的轨道上。我会为聊天行使用上限集合,每行包含用户 ID、房间 ID、时间戳和所说的内容。一旦达到上限集合的“结束”,此数据就会过期,因此如果您需要历史日志,您希望定期将数据从上限集合复制到“日志”集合中,但上限集合是专门为记录而设计的 -样式应用程序,您不会删除文档,并且插入顺序很重要。在聊天的情况下,这是一个完美的匹配。

我建议的唯一其他更改是将上传内容也保留在单独的集合中。

于 2010-09-07T05:58:32.133 回答
2

我也是 mongodb 作为文档数据库的忠实粉丝。但是你确定你使用 mongodb 是出于正确的原因吗?mongodb有什么厉害之处?

这是一个主观问题,但对我来说,对文档进行就地(原子)更新是 mongodb 强大的原因。而且我真的看不到你使用它那么多。最重要的是,您还遇到了文档大小限制问题。(根据经验,我可以告诉您将文件嵌入到 mongodb 不是一个好主意)。您也希望在数据库之上拥有一个实时聊天应用程序。

您的文档架构似乎合乎逻辑。但是对于这种应用程序严重依赖插入的项目,我不会使用 mongodb。我会选择 CouchDB。

使用 CouchDB,您不必担心附件问题,您可以轻松嵌入它们。“_changes”将使您的生活更加轻松,以构建实时聊天应用程序/长池/馈送搜索引擎(如果您想实现一个)。

我在沙发上看到了一个开源展示项目。它与您的目标有一些相似之处:Anologue。你应该检查一下。

PS:对不起,这有点跑题了,但我无法控制自己。

于 2011-03-01T22:45:19.560 回答