应用错误收集

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

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

我们心中的选择。

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

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

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

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

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

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

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

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

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

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

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

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

https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/yolfc6B3JL8

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

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

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

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

MongoDB演示文稿：

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

http://www.manning.com/banker/（MongoDB in Action）

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

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

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

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

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

Mongodb可扩展的集合

2 个答案: