MongoDB性能

Question

我需要设计mongoDB数据库来保存历史记录通知。 我考虑两种可能的解决方案。

1）每个用户将有这样的1个文档：

{
_id: 1234567890abcdefgh,
emailfrom: email1@example.com,
history: {
  email2@example,com: {
    {
      read: 1,
      text: 'hey man',
      time: 2015-11-20-23-05-15
    },
    {
      read: 0,
      text: 'hey whats up',
      time: 2015-11-20-23-10-10
    }
  },
  email3@example,com: {
    {
      read: 1,
      text: 'oooh',
      time: 2015-11-20-23-05-11
    }
  }
}

}

2）第二个解决方案是为每个通知自己的文件做这样的：

{
 _id: 1234567890abcd
 emailfrom: email1@example.com,
 emailto: email2@example.com,
 text: 'hey man',
 read: 1,
 time: 2015-11-20-23-05-15
},
{
 _id: 1234567890abcd
 emailfrom: email1@example.com,
 emailto: email2@example.com,
 text: 'hey whats up',
 read: 0,
 time: 2015-11-20-23-05-15
},
{
 _id: 1234567890abcd
 emailfrom: email1@example.com,
 emailto: email3@example.com,
 text: 'oooh',
 read: 1,
 time: 2015-11-20-23-05-11
},

我的问题是关于这两种方法的表现。 当有成千上万的通知时，我会想要选择，更新或查找：

1）查找从email1@example.com发送的所有通知并阅读：0 - 我认为第一种方法会更快

2）我想保存新的通知 - 我认为第二种方法会更快

3）我想更新阅读0 - >阅读1 emailfrom email1@example.com email到email2@example.com - 我不知道哪种方法会更快。

任何人都可以帮我这个吗？ 哪一个是保存此类数据的正确方法？ 谢谢你的评论！

Answer 1

我猜第一种方法中存在拼写错误。 “email2 @ example，com”和“email3 @ example，com”的类型应该是数组，对吧？ 无论如何，根据您提到的用例，我更喜欢选择选项2.只需为该表添加适当的索引，例如“ emailfrom + read ”和“ emailfrom + emailto ”的复合索引，这可以确保您在查询期间具有高性能。

最常见的情况是通过emailfrom查询以及选项1无法帮助的另一个条件。 由于将来会有很多通知，您仍然认为mongoDB中每个文档大小都有16M的限制。

Answer 2

如果您将来考虑成千上万的通知，我强烈建议不要因为文档大小的限制而在每个用户的文档中存储嵌入的通知历史记录。

这里的文章给出了一些方法来设计的MongoDB架构，这似乎是类似的（收件箱）。

此外， HERE是docs.mongodb.org的一个很棒的简短指南，它可以帮助您决定MongoDB数据模型最适合您。