javascript - 最好使用包含大量对象或大量文档的文档？

Question

所以我有一些关于公司里很多人的数据，比如他们的名字，年龄和性别。我要把他们的信息储存在MongoDB中。对我来说，将他们的信息存储在大量文档中还是作为一堆独立的对象存储在一个文档中更好？是否有任何性能或内存问题会使一种方法优于另一种方法？
存储数据的示例方法：
很多文件

{
  _id: ObjectId('1'),
  name: 'Bart',
  age: 10,
  gender: 'Male'
},
{
  _id: ObjectId('2'),
  name: 'Lisa',
  age: 8,
  gender: 'Female'
}

一个文档中有很多对象

{
  _id: ObjectId('1'),
  'Bart': {
    age: 10,
    gender: 'Male'
  },
  'Lisa': {
    age: 8,
    gender: 'Female'
  }
}

如果有人想知道我会用mongo的projection参数查询第二个示例，例如。

db.families.find({_id:ObjectId('1')},{_id:0,'Bart':1});

另外，我问这个问题的唯一原因是我打算在这里储存来自多家公司的人员。它们将由集合和单独列为文档（如第一个示例）的人员或文档中的人员以及单独列为公司文档中对象的人员分隔。

Answer 1

第一个比较好。
每个文档有16 MB的限制。因此，将所有内容放在一个文档中可能会遇到这个障碍，您必须手动执行文档拆分，最终会为同一个（伪）集合生成多个文档。您需要额外的程序代码来找到正确的片段，甚至在应用程序中组合文档来执行一些集合级操作。除非有很好的理由这样做，否则我会不惜任何代价避免这样做。
此外，它可能与您的访问模式最匹配。您还有更多的优化选项，例如，您可以在名称上定义一个索引，这在第二个示例中是无法实现的。此外，更新该文档的速度越快，文档越小（尤其是在无法进行就地更新的情况下）。
如果要让多个公司拥有用户，可以为每个公司使用单独的集合，也可以在文档上添加公司属性。这取决于你将支持多少家公司，但假设不是只有2家或3家，我宁愿选择后者。它更易于维护、扩展（即分片）、优化（索引等）或扩展。

{
  _id: ObjectId('1'),
  name: 'Bart',
  age: 10,
  gender: 'Male'
  company: 'XYZ'
}

编辑：
关于性能的更多考虑。两个选项的基本事件流如下：
单文档策略（带投影）
使用索引（在内存中）快速按objectid查找文档
根据文档的大小加载整个文档（从dics）可能会很慢
投影（内存中）快速
N-DOC策略（无投影）
按objectid或name查找文档，使用索引（在内存中），快速
从光盘加载（小）文档，速度慢，但比加载大文档快
特别是对于1-doc策略，当它变得比n-doc策略慢时，特别是当文档变大时，可能会有一个临界点。对于较小的文档，它可能是相等的，也可能更快，特别是当缓存发挥作用或出现其他边缘情况时（即，名称的范围是有限的，这使得对名称的查询不是很有选择性，但在这种情况下，无论如何，您都会使用1-doc方法）
Mongo对模式设计的建议如下：
1:1关系：使用嵌入文档
1:少关系：使用嵌入文档
1:很多使用多个集合
你打算做的是建立一种公司关系：人际关系，这可能是第三种或第二种选择。所以要么你有两个收藏：
公司
人员（公司外键）
或
公司（嵌入人员）
不管怎样，我都会把这个人塑造成

person:
{
  _id: ObjectId('1'),
  name: 'Bart',
  age: 10,
  gender: 'Male'
  company: 'XYZ' //only for foreign key relationship to separate collection
}

如果是嵌入式的人，它将是公司中的一个数组

company:
{
  name: 'companyA',
  persons: [..] //and not use person's name as key here
}

我可以在persons.name和/或company上添加索引。因此，搜索一个人完全在内存中运行（使用索引），加载个人文档应该很快，因为只有一个小文档是从磁盘读取的。
因此，这两种方法都给了我最大的灵活性，同时访问速度仍然很快。
虽然可能会有这样的情况，当投影速度很快时（可能有小的“公司”文档并且它们已经被缓存），但我不会这样做，因为它有一些严重的缺点（其中一些对性能也有负面影响）。
你不能有人的索引
如果文档增长超过16MB（这可能最终发生），则需要额外的应用程序逻辑。
你不能处理相同的名字（这可能会发生）
您的灵活性较低（更改模式、在分布式环境中选择更新操作的原子性、添加其他访问模式，如列出公司的所有人员）
维护可能会变得很麻烦（您必须仔细检查公司文档才能找到人员的姓名）
可能有副作用的碎片或复制，我没有想到现在
它违反了面向对象的设计原则（扪心自问：“bart”是一个家庭的财产还是“儿子”或更普遍的“孩子”？-也使得它不易维护
因此，即使没有证明一个appproach比另一个快，我也不会使用投影方法来过滤用户，因为到目前为止，缺点超过了（假定的）优点。