需要有关 MongoDB Schema for Chat App 的建议。嵌入式与相关文档

Question

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

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

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

应用程序将具有：

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

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

从我目前的想法来看，我正在考虑做类似的事情：

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

我主要关心的是我要走多远才能最终看起来像一个关系模式并且我违背了目的？肯定比嵌入更相关。

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

我想进行通用查询，例如：

• 给我一个帐号的所有房间
• 给我房间内的所有聊天记录（或按日期范围过滤）
• 给我来自特定用户的所有聊天记录
• 给我在给定房间或给定组织上传的所有文件
• 等

关于如何以可扩展的方式有效地构建架构有什么建议吗？谢谢大家。

Answer 1

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

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

Answer 2

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

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

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

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

我在沙发上看到了一个open source showcase project。它与您的目标有一些相似之处：Anologue。你应该检查一下。

PS : 抱歉有点跑题了，但是我忍不住了。