Mongodb可扩展的集合

时间:2012-10-11 17:48:51

标签: mongodb collections scalability

创建可扩展且具有最佳读取性能的MongDB集合的最佳方法是什么?以下是假设

  • 用户每天有100个条目。条目对用户是私有的。
  • 我们可能有200,000个用户。因此,每天几乎200 * 200,000 = 20M条目。
  • 用户喜欢在插入后立即查看条目。
  • 用户喜欢搜索他们自己的条目,即使数据是3个月大。在3个月内,20M * 90 = 180M条目。
  • 没有更新。只插入和删除。

我们心中的选择。

  • 根据用户名进行分片。 A .. D在一个碎片等。但仍然很难扩展。
  • 为每个用户创建一个集合。我们知道这是一种极端的方法,但为什么不呢。我们没有对用户数据进行聚合。 MongoDB中收集数量的任何限制

任何建议将不胜感激。 感谢。

2 个答案:

答案 0 :(得分:3)

不幸的是,由于limits您可以拥有的命名空间数量(24,000),每个用户的一个集合将无法工作。

我认为有一些好的方向可以去。你肯定会想要使用统一分发的分片密钥 - 用户名会很好。您对其可扩展性有何顾虑?

您可能需要查看TTL(生存时间)集合,以及Read preference以便从辅助服务器中读取您的应用程序。这可以通过分配工作负载来加快查询时间。

答案 1 :(得分:1)

在MongoDB世界中,没有一种最佳的架构设计。在MongoDB中,模式设计取决于应用程序如何访问数据。

以下是为MongoDB设计好的架构时需要回答的关键问题:

  • 你有多少数据?
  • 您最常见的操作是什么?您是主要插入新数据,更新现有数据还是进行查询?
  • 您最常见的疑问是什么?
  • 您最常见的更新是什么?
  • 您希望每秒进行多少次I / O操作?

在MongoDB中,您有多种选择:您可以嵌入数据,可以创建链接关系,可以复制和非规范化数据,也可以使用混合方法。

@Shelman已经提到了“阅读偏好”,这是值得关注的,利用辅助词。

在扩展方面,Sharding似乎适合您。分片上的MongoDB Manual非常广泛,涵盖了体系结构,基础知识,部署,管理和内部(如果您非常热衷)。我强烈建议你阅读它。但是,正如@Shelman所说,你需要明智地选择你的分片键。 StackOverflow和MongoDB Google User Group上广泛涵盖了此主题。

避免连续分片键的一个原因是它会在插入上创建热点:在任何给定时间,单个分片将占用所有插入负载。您可能想要选择复合分片键。谷歌集团对此有一些很好的讨论:

如果您选择{username:1,timestamp:1}之类的内容,则用户的数据将在需要时分解为多个块并分布在服务器上。

这是关于选择分片键的文档的exact link

=============================

以下是关于MongoDB架构设计的一些很好的一般参考。

MongoDB演示文稿:

这是一本关于MongoDB架构设计的书,我认为你会发现它很有用:

以下是一些示例架构设计:

=============================

以下是在MongoDB架构设计中使用'bucketed'方法的一些示例:

=============================

最近MongoNYC最近发表的一些分片报道: