为相似的数据结构选择 MongoDB 集合结构答案

【问题标题】：Choosing MongoDB collections structure for similar data structures为相似的数据结构选择 MongoDB 集合结构
【发布时间】：2012-02-07 08:05:31
【问题描述】：

在 MongoDB 中存储类似结构的更好方法是什么？为全部选择一个集合还是为每个结构选择一个？拥有一个/几个有什么好处？

例如，我必须存储一些日志，以便进一步分析。每个结构都有一个共同的部分和一些特定于某些统计类型的数据，例如：

{ 
  timestamp: ...,
  client: { ... },
  type: 'stats_for_item1',
  data: { 
     id: ObjectId('xxx'),
     field1: 1,
     field2: 2 
  } 
},
{ 
  timestamp: ...,
  client: { ... },
  type: 'stats_for_item2',
  data: { 
     id: ObjectId('zzz'),
     field3: 3,
     field4: {
        field5: [5, 1]
     }
  } 
}

如您所见，我们有共同的部分和 data 字段，item1 和 item2 的不同字段很少。

似乎只有timestamp 和type 字段将被索引（当然还有_id）。并且此类物品的数量有限，总共有 3 种物品类型。写的多，读的少

那么，我的问题是，如何组织这样的结构？使用一个大集合stats 并将所有内容存储在那里？不会创建几个集合stats_item1、stats_item2 和stats_item3。什么是最优的？有什么好处吗？从 mongo 的角度来看，用于分片/索引/查询/锁定/等？

【问题讨论】：

标签： mongodb

【解决方案1】：

我可能会保留一个收藏。如果您稍后确实获得了另一种统计类型，则不必围绕必须添加的新集合重新构建代码。您可以通过在“类型”上创建索引来专门搜索具有特定类型的项目，但您也可以通过所有项目进行搜索，因为您将它们全部放在具有“时间戳”索引的集合中”。（请注意，MongoDB 还会为每个文档添加一个 _id 字段，并且它也会添加一个索引）。

对于分片，您需要为每个集合选择一个密钥。我不知道您的写入/读取比率是多少以及您打算如何读取数据，但我怀疑您稍后会进行某种日志记录和一些分析。在这种情况下，也许“客户端”上的分片键最有意义。时间戳可能是一个糟糕的选择，因为它会强制所有写入到一个分片。

一个或三个用于锁定的集合之间的区别并没有太大的区别，因为现在 mongoDB 不会对每个集合进行锁定（仅在 2.0 中每个服务器实例都有锁产生，而每个数据库都有锁产生在即将发布的 2.2 中）。

干杯，

德里克

【讨论】：