MongoDb 多键索引——稀疏、唯一、增长问题

Question

对于first pattern example of Mongodb Model One-to-Many Relationships with Document References-

我有一些关于在 book 数组字段上为发布者 O'Reilly Media 创建多键索引的问题：

出于学习目的，我将假设将来 book 数组只会最多增长 5 个元素，所以我想只关注这种模式使用数组：

1. 当我将objectId添加到book数组时，它会自动索引新元素吗？

2. 当我创建db.publishers.createIndex(books) 时，我想创建 背景是真的，所以当我添加到书籍时它不会阻塞 稍后数组并索引新值？

3. 我看到unique 的默认值是假的。我很困惑 这是因为我不知道 MongoDb 索引的内部工作原理。 books 数组上的唯一值不需要为真吗？
4. 对于sparse，我为什么要使用它，为什么它设置为假？这 books 数组已经是一个指定的字段。
5. 如果我删除了数组的一个元素，索引的大小 自动减少？

6. 我假设如果我稍后修改书籍文档，它不会影响 写入性能，因为它的 objectId 之前已经被索引 出版商书籍数组，对吗？

   {
      name: "O'Reilly Media",
      founded: 1980,
      location: "CA",
      books: [12346789, 234567890, ...]
   }
   
   {
       _id: 123456789,
       title: "MongoDB: The Definitive Guide",
       author: [ "Kristina Chodorow", "Mike Dirolf" ],
       published_date: ISODate("2010-09-24"),
       pages: 216,
       language: "English"
   }
   

Answer 1

1. MongoDB 会自动将书籍 ID 添加到多键索引中。但是，这个索引当然不包括实际的图书文档。
2. 该块仅在创建索引时发生，而不是在添加项目时发生（尽管将新项目放入索引中的开销非常小）。想象一下，您已经有 10,000 个出版物，每个出版物有 200,000 本书 - 为这些出版物编制索引只需要一段时间，或者阻止任何操作，因此速度更快，我们在后台进行。
3. null 值也是唯一值。因此，如果没有出版书籍，就不可能有两个出版商。
4. 使用稀疏索引来节省宝贵的 RAM。如果您有数百万个文档，其中只有一小部分具有某个字段，那么拥有几百万个null 条目只会浪费 RAM。如今，部分索引是首选，它提供与稀疏诱导相同的功能。
5. 是的，根据您删除的值。如果该数组因删除而被清空，并且您使用了稀疏或部分索引，则对文档的相应引用也将被删除。

6. 大错特错。索引 - 大大简化 - 只不过是索引 field 的寄存器和数据文件中相应文档的位置。对于 books 数组，这将是包含索引值的发布者文档。同样，被索引的不是书籍文档，而是包含对书籍文档的引用的字段。 books 字段被编入索引的原因是对于 给定 书，可以更快地找到出版商：

   db.publishers.find({books:someBookId})
   

   在编辑书籍文档时，您仍然必须首先找到它并应用最终需要同步到磁盘（甚至之前同步到日志）的更改。索引不会神奇地消除对持久数据的需求。