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 回答