Mongodb：多个集合或一个包含索引的大集合

我需要帮助在mongo中建模我的数据。我的大部分经验都是在关系数据库中，我刚刚开始与mongo合作。我正在为不同的事件建模数据

具有的每个“事件”都有相同的字段

每个“事件”将有数百到数百万个文档/行

事件是动态的，即将根据需要创建新的事件。即 也许会创造一个新的“2016年夏季奥运会”项目

可能最重要的是，在处理事件（CRUD操作）时，用户必须指定事件名称

到目前为止，我可以看到几种方法来实现这一点，我不想在以“错误”的方式设置数据模型时犯重大错误

1） 一个包含所有事件数据的“事件”集合。“事件”名称上的索引。查询将类似于：

db.events.find({event: 'Summer Olympics 2012');
{event: 'Summer Olympics 2012', attributes: [{name: 'joe smith', .... }
{event: 'Summer Olympics 2012', attributes: [{name: 'jane doe', .... }
{event: 'Summer Olympics 2012', attributes: [{name: 'john avery', .... }
{event: 'Summer Olympics 2012', attributes: [{name: 'ted williams', .... }

db.events.find({event: 'Summer Olympics 2013'})
{event: 'Summer Olympics 2013', attributes: [{name: 'steve smith', .... }
{event: 'Summer Olympics 2013', attributes: [{name: 'amy jones', .... }

2） 每个新事件的集合，w/集合用于跟踪所有事件名称。由于每个事件存储在不同的集合中，因此不需要对事件名称进行索引

// multiple collections, create new as needed
db.summer2012.find() // get summer 2012 docs

db.summer2016.find() // get summer 2016 docs

//'events' collection
db.events.find() // get all events that I would have collections for
{name: 'summer2012', title: 'Summer Olympics 2012'};
{name: 'summer2016', title: 'Summer Olympics 2016'};

对于#1，我有点担心，一旦我达到100个事件，每个事件都有数百万条记录，即使其中一个事件只有500个文档，每个“事件”的查找速度也会很慢

对于#2，我是否在这里通过每次创建一个新集合和一个活动来“绕过”mongo模型

欢迎发表任何意见/想法，因为我真的不知道哪一个最终会表现更好，或者哪一个会给我带来更多麻烦。我环顾了四周（包括mongo的网站），真的找不到具体的答案

来自mongo文档：

在某些情况下，您可以选择将信息存储在 多个集合，而不是单个集合

// multiple collections, create new as needed
db.summer2012.find() // get summer 2012 docs

db.summer2016.find() // get summer 2016 docs

//'events' collection
db.events.find() // get all events that I would have collections for
{name: 'summer2012', title: 'Summer Olympics 2012'};
{name: 'summer2016', title: 'Summer Olympics 2016'};

考虑一个用于存储日志文档的示例收集日志 各种环境和应用程序。日志集合包含 以下格式的文件：

{log:“dev”，ts:…，info:…}{log:“debug”，ts:…，info:…}

如果文档总数较低，您可以将文档分组到 按类型收集。对于日志，考虑维护不同日志 集合，例如logs.dev和logs.debug。logs.dev集合 将仅包含与开发环境相关的文档

一般来说，拥有大量的藏品没有什么意义 性能惩罚和结果非常好的表现。不同的 集合对于高通量批处理非常重要

也和10gen guy说话。对于真正大的收藏，他列出了将其分成更小更具体的收藏的多种好处。他对所有数据使用一个集合并使用索引的评论是：

仅仅因为你能做某事并不意味着你应该做。模型 您的数据将被正确地保存。可能很容易储存在一个大集合中 但这并不总是最好的方法

---

这些属性是什么？人？那么，您是否有参加活动的x个人？这些人在你的系统中注册了吗？如果您刚开始使用MongoDB，请查看以下内容：抱歉，这是一个糟糕的示例：（.实际上是它的地理空间数据。所以每个文档都有一个x，y。用户可以轻松地在地图上为他们当前的位置添加/放置一个pin，并附加一些关于该位置的元数据。例如图片/视频、标题、天气等。所以想象一下奥运会上有一群人在添加新数据。人/位置相同。问题是因为ea如果每个单独的事件都存在于自己的集合中，或者将所有事件文档放入同一个集合中，那么ch“event”可能有数百万个文档？一个集合有1000万个文档，或者10个集合每个集合有约100万个文档。这也仅仅是从Mongo开始的。我认为手册的这一部分很重要：。它将我引向这个改进MongoDb设计，可以，而且应该非常类似于db设计，所以，我会选择第一个选项，特别是如果你打算做“交叉事件”问题：如果我有一个包含所有事件的集合，它有3000万个文档。我有一个新事件，该事件只有10个文档。总数现在是3000010个文档。如果用户试图获取新事件的所有文档（只有10个文档）性能是否会因为一个集合的总体大小而受到影响。作为一个用户，我希望这10个文档会很快返回。没有跨事件查询，我说了一个“在处理事件（CRUD操作）时可能最重要”用户必须指定事件名称。您需要一个事件名称才能从事件中读取/创建/更新/删除文档。