我开始一个 MongoDB 项目只是为了好玩和学习 MongoDB/NoSQL 模式的机会。这将是一个实时聊天应用程序,堆栈包括:Rails 3、Ruby 1.9.2、Devise、Mongoid/MongoDB、CarrierWave、Redis、JQuery。
我将分别处理实时聊天轮询/消息队列。不确定如何使用 Node.js、APE 或自定义 EventMachine 应用程序。但是关于 Mongo,我正在考虑将它用于应用程序中的所有其他内容,特别是聊天日志和历史记录。
我的问题是如何最好地设计架构,因为我之前的所有经验都是使用 MySQL 和关系数据库架构。作为一个子问题,什么时候最适合我们嵌入文档和相关文档。
应用程序将具有:
- 拥有多个房间的多个帐户
- 多个房间
- 每个房间有多个用户
- 允许用户进入的房间列表
- 每个房间有多个用户聊天
- 每个房间和每个用户的可搜索聊天日志
- 给定聊天的可选文件附件
鉴于 Mongo(至少在我上次检查时)的文档限制为 4MB,我不认为拥有房间集合并将所有房间聊天存储为嵌入式文档会很好。
从我目前的想法来看,我正在考虑做类似的事情:
- 帐户集合
- 房间系列
- 每个房间都与一个帐户相关联
- 聊天室中所有聊天消息的聊天集合中的相关文档
- 列出当前房间内所有用户的嵌入式文档
- 供用户使用的集合
- 列出用户当前所在的所有房间的嵌入式文档
- 列出用户被允许进入的所有房间的嵌入式文档
- 聊天合集
- 每个聊天都与房间集合中的一个房间相关
- 每个聊天都与用户集合中的用户相关
- 包含可选上传文件附件信息的嵌入式文档。
我主要关心的是我要走多远才能最终看起来像一个关系模式并且我违背了目的?肯定比嵌入更相关。
另一个问题是引用相关文档比访问我听说过的嵌入文档要慢得多。
我想进行通用查询,例如:
- 给我一个帐户的所有房间
- 给我房间内的所有聊天记录(或按日期范围过滤)
- 给我来自特定用户的所有聊天记录
- 给我一个给定房间或给定组织的所有上传文件
- 等
关于如何以可扩展的方式有效地构建架构有什么建议吗?谢谢大家。
最佳答案
我认为你的方向是正确的。我会使用 capped collection对于聊天行,每行包含用户 ID、房间 ID、时间戳和所说的内容。一旦达到上限集合的“结束”,此数据就会过期,因此如果您需要历史日志,您希望定期将数据从上限集合复制到“日志”集合中,但上限集合是专门为记录而设计的 -样式应用程序,您不会删除文档,并且插入顺序很重要。在聊天的情况下,这是一个完美的匹配。
我建议的唯一其他更改是将上传内容保存在单独的集合中。
关于ruby-on-rails - 需要有关 MongoDB Schema for Chat App 的建议。嵌入式与相关文档,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3652632/