MongoDB面试专题

---

NoSQL 数据库

1. 概念： NoSQL 数据库是指非关系型数据库，其中的“NoSQL”代表“Not Only SQL”。

2. 区别： NoSQL 数据库与关系型数据库（RDBMS）在数据存储方式上有明显区别。关系型数据库采用结构化数据存储，而 NoSQL 数据库采用键值对的方式存储数据。

3. 使用和不使用 NoSQL 数据库的原因：

• 使用 NoSQL 数据库：

  • 处理非结构化/半结构化的大数据时更为高效。
  • 需要在水平方向上进行扩展，适用于分布式环境。
  • 数据项动态增加时，NoSQL 数据库更为灵活。

• 不使用 NoSQL 数据库：

  • 考虑数据库成熟度、支持、分析和商业智能等因素时，关系型数据库可能更为合适。
  • 对于管理和专业性要求较高的应用场景，关系型数据库也是优选。

4. NoSQL 数据库的优点：

• 灵活的数据模型： NoSQL 数据库支持各种数据模型，包括键值存储、文档存储、列存储和图形数据库等，能够更好地满足不同场景的需求。
• 高性能和可伸缩性： NoSQL 数据库通常设计为分布式架构，能够在集群环境下实现高性能和良好的可伸缩性。
• 容错性和高可用性： NoSQL 数据库在设计时考虑了容错和高可用性，能够应对节点故障或网络分区等情况，保证系统的稳定性。
• 适用于大数据处理： NoSQL 数据库更适用于处理大规模的非结构化或半结构化数据，能够处理数据量大、变化快的场景。

NoSQL 数据库有哪些类型?

1. 键值存储（Key-Value Stores）： 这种类型的数据库将数据存储为键值对的形式，每个键都唯一地对应一个值。这种类型的数据库适用于需要快速读写以及简单数据模型的场景。

   • 例子：Redis、MemcacheDB、Voldemort。

2. 文档存储（Document Stores）： 文档存储数据库以文档（如 JSON 或 XML）的形式存储数据，文档可以包含各种不同结构的数据。这种数据库适用于具有复杂结构的数据和灵活的查询需求。

   • 例子：MongoDB、CouchDB、Couchbase。

3. 列存储（Column Stores）： 列存储数据库将数据存储在列族中，每个列族包含一组行，每行由唯一标识符和多个列组成。这种数据库适用于需要快速读取大量数据的场景，如数据仓库和分析应用。

   • 例子：Cassandra、HBase、Hypertable。

4. 图形数据库（Graph Databases）： 图形数据库使用图形结构来表示和存储数据，其中节点表示实体，边表示节点之间的关系。这种数据库适用于需要处理复杂关系和网络的场景。

   • 例子：Neo4j、ArangoDB、OrientDB。

5. 对象存储（Object Stores）： 对象存储数据库将数据存储为对象的形式，每个对象包含数据以及与之相关的元数据。这种数据库适用于分布式存储和云存储场景。

   • 例子：Amazon S3、Google Cloud Storage。

6. 时间序列数据库（Time Series Databases）： 时间序列数据库专门用于存储和处理按时间顺序排列的数据，如传感器数据、日志数据等。

   • 例子：InfluxDB、Prometheus。

每种类型的 NoSQL 数据库都有其特定的优势和适用场景，选择合适的类型取决于应用程序的需求和数据模型。

MySQL 与 MongoDB 之间最基本的差别是什么?

最基本的差别在于数据存储结构和数据模型的不同，即关系型数据库和文档型数据库之间的差异。

1. 数据存储结构：

   • MySQL 是关系型数据库，数据以表格的形式存储，每个表格包含行和列，数据之间通过键值关联。
   • MongoDB 是文档型数据库，数据以文档的形式存储，文档是一种类似 JSON 的数据结构，可以包含键值对、数组和嵌套文档。

2. 数据模型：

   • MySQL 使用结构化的数据模型，需要预先定义表格的结构和关系，严格遵循数据库范式。
   • MongoDB 使用灵活的数据模型，文档可以根据需要动态添加字段，不需要事先定义模式。

3. 查询语言：

   • MySQL 使用结构化查询语言（SQL）进行数据查询和操作。
   • MongoDB 使用基于文档的查询语言，可以执行类似于 SQL 的查询，同时也支持更灵活的查询方式。

4. 事务支持：

   • MySQL 支持事务（ACID 特性），能够确保数据的一致性和可靠性。
   • MongoDB 在某些版本中开始支持事务，但与关系型数据库相比，其事务性能和功能还不完全成熟。

5. Schema 设计和定义：

   • 在 MySQL 中，需要预先定义表格的结构和关系，严格遵循数据库范式。
   • 在 MongoDB 中，文档的结构是灵活的，可以根据需要动态添加字段，不需要严格定义模式。

6. 标准化：

   • MySQL 遵循严格的标准化设计，强调数据的一致性和关系的清晰性。
   • MongoDB 更加灵活，允许存储冗余数据以提高查询性能，但也需要更多的管理和维护工作。

7. 速度和性能：

   • 由于 MongoDB 的文档型存储方式以及无需执行复杂的连接操作，适合处理大量数据和高并发访问，通常在某些场景下速度和性能更高。
   • MySQL 在处理复杂的关系查询和事务时可能更为稳定和可靠。

通过比较以上方面，可以更好地了解 MySQL 和 MongoDB 之间的最基本差别，以及它们适用的不同场景和优缺点。

比较 MongoDB、CouchDB 及 CouchBase?

MongoDB、CouchDB和Couchbase都是面向文档的数据库，但它们在实现细节、特性和适用场景上有一些不同。以下是它们之间的比较：

1. 数据模型：

   • MongoDB：采用 JSON 类似的 BSON 格式来存储文档，文档可以包含键值对、数组和嵌套文档。
   • CouchDB：使用 JSON 来存储文档，文档以纯文本形式存储，并且每个文档都有一个唯一的标识符。
   • Couchbase：也使用 JSON 存储文档，文档包含键值对，但与CouchDB不同，Couchbase支持多文档事务，并提供了更强大的缓存和查询功能。

2. 接口和查询语言：

   • MongoDB：提供了丰富的查询语言和强大的聚合管道操作，支持复杂的查询和数据操作。
   • CouchDB：使用 MapReduce 查询，也支持基于 JavaScript 的查询。
   • Couchbase：支持基于N1QL（SQL for JSON）的查询语言，允许类似于SQL的查询操作。

3. 复制方法：

   • MongoDB：采用主从复制和分片复制的方式来实现数据复制和高可用性。
   • CouchDB：使用多主复制（Multi-Master Replication）来实现数据复制，每个节点都是独立的主节点。
   • Couchbase：通过 XDCR（Cross Datacenter Replication）实现数据的复制和同步，可以实现跨数据中心的高可用性和容灾备份。

4. 对象存储：

   • MongoDB：提供了 GridFS 来存储大型二进制文件和多媒体文件。
   • CouchDB：也可以存储大型二进制文件，但它将文件分割成小块并存储在B树中。
   • Couchbase：不提供类似 GridFS 的对象存储功能，但可以通过其他方式实现类似的功能。

5. 适用场景：

   • MongoDB：适用于需要高性能、高可用性和灵活数据模型的应用场景，如Web应用、内容管理系统等。
   • CouchDB：适用于需要离线同步、版本控制和复杂查询的应用场景，如移动应用、协作工具等。
   • Couchbase：适用于需要分布式缓存、高扩展性和大规模数据处理的应用场景，如实时分析、大数据处理等。

综上所述，MongoDB、CouchDB和Couchbase在实现细节、特性和适用场景上有所不同，选择适合自己业务需求的数据库取决于具体的应用场景和数据处理要求。

MongoDB 成为最好 NoSQL 数据库的原因是什么?

MongoDB 成为最受欢迎的 NoSQL 数据库之一，原因如下：

1. 面向文档的存储模型： MongoDB 使用面向文档的存储模型，数据以类似于 JSON 的 BSON 格式存储。这种模型使得数据结构更加灵活，能够轻松地存储和查询复杂的数据结构。

2. 高性能： MongoDB 的设计和实现注重性能优化，支持水平扩展，能够在集群环境下实现高性能的数据读写操作。

3. 高可用性： MongoDB 提供了副本集（Replica Set）和分片集群（Sharded Cluster）等机制来实现数据的高可用性和容错性，确保数据在发生故障时仍然可用。

4. 易扩展性： MongoDB 能够轻松地通过增加节点来实现系统的水平扩展，从而满足不断增长的数据需求和用户量。

5. 丰富的查询语言： MongoDB 提供了强大而灵活的查询语言，包括查询操作符、聚合管道等，能够支持复杂的查询和数据分析需求。

综上所述，MongoDB 以其面向文档的存储模型、高性能、高可用性、易扩展性和丰富的查询语言等特点，成为了最受欢迎的 NoSQL 数据库之一。它适用于各种场景，包括 Web 应用、大数据分析、实时数据处理等，成为许多开发者和企业的首选数据库解决方案。

32 位系统上有什么细微差别?

在32位系统上，特别是在处理大型数据时，会存在一些细微差别，其中一些已经被提及了：

1. 内存限制： 32位系统由于地址空间的限制，通常只能寻址4GB内存。这意味着对于大型数据库，其可用内存受到限制，可能会影响性能和扩展性。

2. 文件大小限制： 32位系统的文件大小受到限制，通常限制在2GB或4GB，这取决于操作系统和文件系统。因此，在32位系统上运行的数据库可能无法处理超过这个限制的大型数据集。

3. 性能： 由于内存和文件大小的限制，以及32位系统的架构限制，可能会导致性能上的一些挑战，特别是在处理大型数据集时。

4. journaling的默认状态： 由于journaling会激活额外的内存映射文件，这可能会进一步限制32位系统上数据库的大小。因此，在32位系统上，默认情况下可能会禁用journaling来减轻这种限制。

总的来说，尽管在32位系统上运行数据库可能会面临一些限制和挑战，但仍然可以通过优化和合理的配置来实现良好的性能和可靠性。然而，对于处理大型数据集和需要更高性能的场景，通常会建议使用64位系统。

journal 回放在条目(entry)不完整时(比如恰巧有一个中途故障了)会遇到问题吗?

在 journal 回放过程中，如果条目（entry）不完整，例如在写操作尚未完成时发生中断，可能会导致一些问题。具体取决于 journaling 的实现方式和数据库系统的特性，可能会遇到以下情况：

1. 数据一致性问题： 如果 journal 中的条目不完整或部分损坏，可能会导致数据的不一致性。因为 journal 记录了数据库的写操作，如果无法正确回放这些操作，可能会导致数据丢失或损坏。

2. 恢复失败： 如果 journal 中的某些条目不完整，可能会导致在数据库恢复过程中出现错误，使得数据库无法正确恢复到一致的状态。

3. 日志回放错误： 如果 journal 中的写操作不完整或损坏，可能会导致在日志回放过程中出现错误，使得数据库无法正确重放写操作，进而影响数据库的完整性和可用性。

为了解决这些问题，数据库系统通常会采取一些措施，例如：

• 检查和修复工具： 数据库系统通常会提供检查和修复工具，用于检查 journal 中的条目是否完整，并尝试修复损坏的条目。

• 恢复机制： 数据库系统可能会实现一些恢复机制，用于在恢复过程中处理不完整的 journal 条目，尽可能地恢复数据库的一致性状态。

• 持久化策略： 数据库系统通常会采取持久化策略，确保 journal 中的写操作在完全完成后才记录到磁盘中，以减少写操作不完整的可能性。

总的来说，尽管在 journal 回放过程中遇到不完整的条目可能会导致一些问题，但数据库系统通常会采取措施来尽量减少这种情况的发生，并尽可能地保障数据的一致性和可靠性。

分析器在 MongoDB 中的作用是什么?

在 MongoDB 中，分析器（Analyzer）是一个用于监视和分析数据库性能的工具。它的作用主要包括以下几点：

1. 性能分析： 分析器可以帮助识别数据库中性能较差的操作，包括查询（读操作）和写操作。通过分析器，你可以查看查询执行的时间、CPU 使用情况、磁盘 IO 等性能指标，以及查询执行的计划。

2. 优化查询： 分析器可以帮助优化查询性能。通过分析慢速查询的执行计划和性能指标，你可以确定是否需要添加索引、调整查询条件或者优化数据模型，以提高查询性能。

3. 监控系统健康状态： 除了查询性能，分析器还可以帮助监控数据库系统的健康状态。你可以通过分析器查看系统的资源利用情况、连接数、操作延迟等指标，及时发现并解决潜在的性能问题。

4. 识别瓶颈： 分析器可以帮助识别系统中的瓶颈，包括硬件瓶颈、查询性能瓶颈等。通过分析器，你可以了解系统中哪些部分存在性能瓶颈，从而有针对性地进行优化。

总的来说，MongoDB 中的分析器是一个非常有用的工具，可以帮助你监视和优化数据库的性能，提高系统的稳定性和可靠性。通过分析器，你可以及时发现性能问题，并采取相应的措施来解决这些问题，从而提升数据库的整体性能和用户体验。

名字空间(namespace)是什么?

在 MongoDB 中，名字空间（Namespace）是指数据库和集合（丛集）名称的组合，用句点（.）连接起来的字符串。具体来说，一个名字空间包括数据库名称和该数据库下的集合名称。

例如，如果有一个名为 mydatabase 的数据库，其中包含一个名为 mycollection 的集合，则该集合的名字空间为 mydatabase.mycollection。

名字空间在 MongoDB 中被广泛用于标识和引用数据库中的集合。它在内部用于管理数据存储，索引和其他元数据。每个集合在物理存储上对应一个文件，该文件的命名方式就是使用了集合所属数据库的名称以及集合的名称。

MongoDB 使用名字空间来唯一标识每个集合，确保在同一数据库中没有重复的集合名称，并且可以通过名字空间来快速定位和访问特定的集合。名字空间的概念是 MongoDB 数据库系统中的一个基本概念，为数据库的组织和管理提供了便利。

如果用户移除对象的属性，该属性是否从存储层中删除?

在 MongoDB 中，当用户移除对象的属性时，该属性会从存储层中删除。具体来说，如果用户通过更新操作或者直接删除操作将对象的某个属性移除，然后将对象重新保存（re-save），MongoDB 会将更新后的对象重新持久化到数据库中，并且已经移除的属性不会包含在更新后的对象中，因此在存储层中也会被删除。

举例来说，如果有一个文档如下：

{
   "_id": ObjectId("60969ac0e1bb4f5686c593b0"),
   "name": "John",
   "age": 30,
   "email": "john@example.com"
}

然后，用户移除了这个文档中的 “email” 属性，然后重新保存该文档，那么在存储层中，这个文档就会变成：

{
   "_id": ObjectId("60969ac0e1bb4f5686c593b0"),
   "name": "John",
   "age": 30
}

这就是因为 “email” 属性已经从文档中移除，再次保存文档时，该属性不会被包含在更新的文档中，因此在存储层中也不会存在。

总之，当用户移除对象的属性后，该属性会从存储层中删除，但需要注意的是，这种删除操作并不是物理上的删除，而是逻辑上的删除，因为实际的数据仍然存在于存储引擎中，只是在读取时被忽略了。

能否使用日志特征进行安全备份?

是的，可以使用日志（journal）特征来进行安全备份。在 MongoDB 中，日志特征允许在数据写入到数据文件之前先写入到日志文件中，这样可以确保即使在数据库发生故障或崩溃时，数据也不会丢失。这个过程称为写入持久化（write durability）。

使用日志特征进行安全备份的一般步骤如下：

1. 启用日志记录： 首先需要确保 MongoDB 实例启用了日志记录（journaling）。通常情况下，journaling 默认是启用的，但是也可以通过设置参数来显式启用。

2. 执行备份操作： 一旦日志记录功能启用，你可以执行备份操作。备份可以采用多种方式，例如使用 mongodump 工具进行逻辑备份，或者直接复制数据文件进行物理备份。

3. 检查备份完整性： 完成备份操作后，建议进行备份数据的完整性检查，确保备份数据的一致性和可靠性。

4. 定期备份： 建议定期执行备份操作，以确保数据的安全性和可恢复性。备份的频率取决于你的业务需求和数据变化的频率。

通过使用日志特征进行备份，可以确保备份的数据是完整的、一致的，并且可以在数据库发生故障时进行恢复。这种方式可以提高数据的安全性和可靠性，保护数据免受意外损坏或丢失的影响。

允许空值 null 吗?

在 MongoDB 中，允许对象成员（文档中的字段）为空值 null。这意味着可以在文档中将某个字段的值设置为 null。例如：

{
   "_id": ObjectId("60969ac0e1bb4f5686c593b0"),
   "name": "John",
   "age": null,
   "email": null
}

在这个示例中，“age” 和 “email” 字段的值都是 null。

然而，需要注意的是，用户不能够直接将空值（null）添加到数据库集合（collection）中。因为在 MongoDB 中，数据是以文档的形式存储的，而 null 本身不是一个对象，因此不能够直接将 null 添加到集合中。但是，用户可以将空对象（{}）添加到集合中，从而实现类似于空值的效果。例如：

db.collection.insertOne({})

这将在集合中插入一个空对象，类似于空值的概念。

总的来说，虽然在 MongoDB 中允许对象成员为空值 null，但是不能直接将 null 添加到集合中，但可以通过添加空对象的方式实现类似的效果。

更新操作立刻 fsync 到磁盘?

在 MongoDB 中，默认情况下，更新操作不会立即将数据写入磁盘，而是采用延迟执行的方式。写操作可能会延迟一段时间后才会被持久化到磁盘上。具体来说，默认情况下，MongoDB 会每隔一段时间将写操作刷新到磁盘，这个时间间隔通常是 60 秒（但也可以通过配置进行调整）。

举例来说，如果在一秒钟内数据库收到了一千个递增操作，那么这些操作可能会被积累起来，直到下一次刷新磁盘的操作才会一次性写入磁盘。

虽然在 MongoDB 中可以通过设置 fsync 选项来要求立即将数据写入磁盘，但默认情况下写操作是延迟执行的。这样设计的目的是为了提高写入性能和减少磁盘 I/O 操作的频率，从而提升数据库的性能和吞吐量。

需要注意的是，尽管 fsync 选项在命令行和通过 getLastError_old 是有效的，但 MongoDB 仍然会根据配置的延迟策略来执行写入操作，而不会立即将数据写入磁盘。

如何执行事务/加锁?

在 MongoDB 中，执行事务和加锁的方式与传统关系型数据库不同。MongoDB 的设计宗旨是轻量、快速和高性能，因此采用了不同的方法来处理数据一致性和并发控制。

具体来说，MongoDB 没有使用传统的锁或复杂的带回滚的事务机制。相反，MongoDB 提供了一种简化的事务模型，通常称为原子操作（Atomic Operations）。原子操作是指 MongoDB 中的单个操作，它要么完全执行成功，要么完全不执行，不会出现部分执行的情况。

由于 MongoDB 的原子操作是单个操作，因此不需要显式地开启和提交事务。每个操作都是原子性的，要么成功，要么失败，不会导致数据处于中间状态。这种设计使得 MongoDB 在处理大量并发操作时能够保持高性能。

对于需要跨多个文档或集合的操作，MongoDB 提供了一些原子操作的组合，例如使用事务性读写操作或者使用条件更新等。这些操作虽然不是严格意义上的事务，但能够满足许多应用场景的需求。

总的来说，MongoDB 的事务和加锁机制相对简单，但能够提供足够的并发控制和数据一致性，适用于大部分应用场景。对于一些需要严格的事务控制和回滚机制的应用，可能需要考虑其他数据库解决方案。

为什么我的数据文件如此庞大?

MongoDB 数据文件看起来庞大的一个主要原因是 MongoDB 的预分配和预留空间机制。

在 MongoDB 中，默认情况下，数据文件会被预分配和预留一定的空间。这意味着 MongoDB 在数据文件中预先分配一定数量的空间，即使这些空间并没有实际存储数据，也会被文件系统保留。这样做的目的是为了防止文件系统碎片化，并提高数据写入的性能。

当 MongoDB 写入新数据时，它会使用预先分配的空间，而不需要动态增长文件大小，从而避免了频繁的文件大小调整操作，提高了写入性能。但这也意味着即使数据文件中并没有实际存储数据，也会占据一定的磁盘空间，导致数据文件看起来很庞大。

如果你希望减小数据文件的大小，可以考虑进行压缩或者手动调整预分配的空间大小。你可以使用 mongodump 和 mongorestore 工具来备份和恢复数据，或者使用 compact 命令来对数据库进行压缩操作。另外，你也可以通过配置 MongoDB 实例的参数来调整预分配空间的大小，以满足你的存储需求。

总的来说，MongoDB 通过积极的预分配和预留空间来提高数据写入的性能，但也会导致数据文件看起来很庞大。通过压缩和调整预分配空间的大小等方法，可以对数据文件进行管理和优化。

启用备份故障恢复需要多久?

启用备份故障恢复通常需要的时间取决于具体的系统配置和环境条件，但一般情况下，从备份数据库被提升为新的主数据库的过程可能需要 10 到 30 秒的时间。

在这段时间内，如果主数据库宕机，那么对主数据库的操作将会失败，包括写入操作和强一致性读取操作。这是因为主数据库不可用，无法处理任何新的写入请求或强一致性的读取请求。

然而，在这段时间内，您仍然可以在备份数据库上执行最终一致性查询操作（eventually consistent query），即使在备份数据库被提升为新的主数据库之前。这是因为备份数据库仍然可以接收读取请求，并且可以返回最终一致性的数据，尽管可能会存在一些数据滞后的情况。

需要注意的是，实际的故障恢复时间可能会受到多种因素的影响，包括网络延迟、系统负载、数据量大小等。因此，虽然通常情况下备份故障恢复可能需要 10 到 30 秒的时间，但在某些情况下可能会更长。

什么是 master 或 primary?

在 MongoDB 中，“master” 或 “primary” 是指备份集群（replica set）中负责处理所有写入操作的主要节点或主要成员。在一个备份集群中，通常会有多个节点，其中一个节点被指定为主节点，负责接收客户端的写入请求并将数据写入到集群中。

主节点是备份集群中的关键角色，它负责维护数据的一致性和可用性。主节点接收写入操作并将其应用到自己的数据集中，然后将这些写入操作复制到其他备份节点（secondary nodes）上，以确保数据的复制和冗余。因此，主节点在备份集群中起着至关重要的作用。

当备份集群中的主节点发生故障或失效时，备份集群将自动进行故障转移（failover）操作，选择另一个节点作为新的主节点，以确保系统的可用性和数据的一致性。新的主节点被选举后，客户端将开始向新的主节点发送写入请求，并且备份节点将开始复制新的主节点的数据，以恢复备份集群的正常运行状态。

总之，主节点（master）或主要节点（primary）是备份集群中负责处理所有写入操作的关键节点，在备份集群中起着至关重要的作用。

什么是 secondary 或 slave?

在 MongoDB 中，“secondary” 或 “slave” 是指备份集群（replica set）中的备份节点，负责从当前主节点（primary）复制相应的操作。备份集群中通常会有一个主节点和多个备份节点，备份节点即为 secondary。

备份节点通过从当前主节点上的操作日志（oplog）进行复制来与主节点保持数据的同步。主节点上的操作会被记录到 oplog 中，而备份节点会持续监听主节点的 oplog，并根据其中的操作来复制相应的数据变更操作，从而保持数据的一致性。

备份节点的主要作用是提供数据的冗余备份以及分担主节点的读取压力。尽管备份节点不接收客户端的写入请求，但它们可以响应客户端的读取请求，并且可以在主节点发生故障时接管主节点的职责，成为新的主节点。

需要注意的是，MongoDB 中的备份节点（secondary）并不是传统意义上的从属节点（slave），因为备份节点不仅仅是 passively 被动地接收主节点的操作，而且还可以独立地响应客户端的读取请求，并且可以在必要时参与备份集群的故障转移操作。

总之，备份节点（secondary）是 MongoDB 备份集群中的节点，负责从当前主节点复制相应的操作，以保持数据的同步和一致性，并且可以在必要时接管主节点的职责。

我必须调用 getLastError 来确保写操作生效了么?

在 MongoDB 中，不一定需要调用 getLastError 来确保写操作生效。实际上，在默认情况下，即使没有显式调用 getLastError，服务器也会执行写操作，并且操作会被持久化到磁盘中。

调用 getLastError 主要是为了确认写操作是否成功提交，以及获取操作的执行结果。虽然经常会希望获得这样的确认，但是写操作的安全性和是否生效并不是由调用 getLastError 决定的。

在 MongoDB 中，写操作默认是"fire-and-forget"，也就是说客户端发送写操作请求后，不会等待服务器的响应，而是立即返回。这种方式可以提高写操作的性能和吞吐量，但也可能会导致客户端无法得知写操作是否成功。因此，如果对写操作的成功性有严格的要求，可以在写操作后显式调用 getLastError 来获取确认。

总的来说，虽然调用 getLastError 可以获得写操作的确认，但并不是必须的。大多数情况下，MongoDB 会确保写操作的安全性和生效，即使没有显式调用 getLastError。

我应该启动一个集群分片(sharded)还是一个非集群分片的 MongoDB 环境?

根据 MongoDB 的官方建议和一般最佳实践，你应该在开始一个 MongoDB 环境时选择非集群分片（unsharded）的方式，除非以下情况之一：

1. 数据集太大： 如果你的数据集已经很大，一台服务器已经无法存放你的初始数据集，那么就应该考虑使用集群分片（sharded）的方式来扩展数据库的存储容量。

2. 需要更高的读写吞吐量： 如果你的应用需要更高的读写吞吐量，或者需要更好的性能和可伸缩性，那么集群分片（sharded）可以提供更好的水平扩展性。

3. 对高可用性和容错性要求高： 集群分片（sharded）可以提供更高的高可用性和容错性，因为数据会被分片和复制到多个节点中，从而减少了单点故障的风险。

然而，如果你的数据集还不是很大，或者对读写吞吐量和性能要求不是很高，那么非集群分片（unsharded）的方式足以满足需求，并且能够简化开发和维护过程。此外，非集群分片（unsharded）的部署方式更为简单，更容易管理和维护。

需要注意的是，从非集群分片升级到集群分片是无缝的，因此在数据集还不是很大或对吞吐量要求不高的情况下，可以先选择非集群分片（unsharded）的方式开始，等到需要时再进行升级。这样可以降低部署和维护的复杂度，并且能够根据实际需求灵活调整数据库的架构。

分片(sharding)和复制(replication)是怎样工作的?

分片（sharding）和复制（replication）是 MongoDB 中两种不同的数据处理和存储策略，它们分别用于解决不同的问题和提供不同的功能。

1. 分片（Sharding）：

   • 分片是 MongoDB 中用于横向扩展数据库的一种策略。它通过将数据分布到多个独立的服务器节点（称为分片或 shard）上，以实现数据的分区和负载均衡。
   • 每个分片都是一个逻辑的数据集合，包含了数据集中的部分数据。当数据量增长到一定程度时，可以将数据集按照某种规则（例如基于数据的某个字段值）划分为多个分片，从而将数据分散存储到不同的服务器上。
   • 分片集群中通常还包含了一组路由器节点（mongos），用于接收客户端的请求并将请求路由到相应的分片上。

2. 复制（Replication）：

   • 复制是 MongoDB 中用于提高数据可用性和容错性的一种策略。它通过在多个服务器节点上复制数据副本，以确保即使部分节点发生故障，系统仍然能够继续提供服务。
   • 在 MongoDB 中，一个复制集（replica set）包含了一个主节点（primary）和多个备份节点（secondary）。主节点负责处理客户端的写入操作，并将写入操作的结果复制到备份节点上，从而保持数据的一致性。
   • 复制集中的每个节点都可以接收客户端的读取请求，因此客户端可以从任意节点读取数据，提高了读取性能和可扩展性。

总的来说，分片和复制是 MongoDB 中用于实现数据扩展、负载均衡、高可用性和容错性的两种重要的数据处理和存储策略。通过合理地使用分片和复制，可以满足不同规模和需求的数据库系统的要求。

数据在什么时候才会扩展到多个分片(shard)里?

在 MongoDB 中，数据扩展到多个分片（shard）中是基于数据划分的。MongoDB 的分片策略是基于区域（range）的，意味着数据集合（collection）中的数据会根据某个字段的值范围被划分为不同的区域，然后分布到不同的分片上。

具体来说，每个集合中的数据都被划分为多个块（chunk），每个块的默认大小是 64MB。在初始阶段，当集合中的数据量较小时，数据可能仅存在于一个块中，并且仅存储在一个分片上。

当集合中的数据量逐渐增大，超过了单个块的容量时，MongoDB 会根据预定义的划分规则将数据划分为多个块，并且开始在多个分片之间分布数据。只有当集合的数据被划分为多个块时，才会有多个分片可以获取数据的选项。这时，数据扩展到多个分片中才会成为可能。

需要注意的是，为了实施数据的迁移，至少需要有 64MB 的空间来容纳一个块。因此，在进行数据扩展到多个分片之前，需要确保集群中至少有足够的可用空间来容纳块的迁移和复制。否则，数据的迁移操作可能会失败或导致系统性能下降。

当我试图更新一个正在被迁移的块(chunk)上的文档时会发生什么?

当你试图更新一个正在被迁移的块（chunk）上的文档时，更新操作会立即在旧的分片（shard）上发生。MongoDB 不会阻止对正在迁移的块上的文档进行更新操作。更新操作将在原始分片上执行，然后更改将被复制到新的分片上。

这种行为是由 MongoDB 分片的设计所决定的。MongoDB 分片是基于区域（range）的，每个区域都包含一个或多个块（chunk）。当需要迁移数据时，MongoDB 将会移动整个块而不是单个文档。在数据迁移的过程中，如果有更新操作发生在迁移的块上，更新操作将继续在原始分片上进行，然后更新的结果会被复制到新的分片上。这样做可以确保更新操作的一致性，并且不会因为数据迁移而导致更新操作失败或产生冲突。

需要注意的是，尽管更新操作会立即在原始分片上执行，但由于数据复制的过程可能需要一些时间，因此在迁移过程中可能会存在一定的延迟，直到更新操作的结果完全同步到新的分片上。因此，在进行数据迁移时，建议尽量避免对迁移的块上的文档进行频繁的更新操作，以减少潜在的一致性问题。

如果在一个分片(shard)停止或者很慢的时候，我发起一个查询会怎样?

当一个分片（shard）停止或者响应很慢时，发起的查询会有不同的行为：

1. 分片停止：

   • 如果一个分片停止了，那么默认情况下，查询会返回一个错误。因为 MongoDB 默认要求所有的分片都必须处于可用状态，如果有任何一个分片不可用，查询会失败。
   • 可以通过设置查询的选项为 “Partial” 来允许部分失败。在这种情况下，如果一个或多个分片停止了，查询仍然会继续执行，并且会返回那些可用的分片的数据。需要注意的是，部分失败可能会导致数据不完整或不一致，因此需要谨慎使用。

2. 分片响应很慢：

   • 如果一个分片响应很慢，MongoDB 会等待它的响应。MongoDB 的默认行为是等待所有分片的响应，然后将结果返回给客户端。这意味着如果一个分片响应很慢，查询可能会花费更长的时间才能完成。
   • 在某些情况下，如果一个分片的响应非常慢，可能会导致整个查询的性能下降。在这种情况下，可以考虑调整分片集群的配置，或者排查分片节点的性能问题，以提高查询的性能和可靠性。

总的来说，当一个分片停止或者响应很慢时，查询的行为取决于查询的设置以及 MongoDB 的配置。可以通过设置查询选项为 “Partial” 来允许部分失败，并且可以通过调整分片集群的配置来优化查询的性能和可靠性。

我可以把 moveChunk 目录里的旧文件删除吗?

是的，你可以删除 moveChunk 目录中的旧文件。这些文件是在 MongoDB 分片执行均衡操作（balancing）时生成的临时文件。一旦均衡操作完成，相关的临时文件就应该被删除。

然而，需要注意的是，MongoDB 目前不会自动清理这些临时文件，因此你需要手动删除它们。在删除这些文件之前，请确保相关的均衡操作已经顺利完成，并且没有其他进程正在使用这些临时文件。此外，你也可以先备份这些文件，以防万一需要恢复。

总之，可以安全地删除 moveChunk 目录中的旧文件，但请谨慎操作，并确保删除操作不会影响到 MongoDB 的正常运行。

我怎么查看 Mongo 正在使用的链接?

要查看 MongoDB 正在使用的连接，你可以使用 connPoolStats 命令。在 MongoDB 中，可以通过以下方式执行该命令：

db._adminCommand("connPoolStats");

这条命令将返回一个包含连接池统计信息的文档，其中包括当前连接数、空闲连接数、活动连接数等信息。通过查看这些信息，你可以了解 MongoDB 正在使用的连接情况，以及连接池的状态。

需要注意的是，connPoolStats 命令在内部使用了 _adminCommand 方法，因此需要在系统权限下执行。另外，连接池统计信息可能会因为 MongoDB 版本的不同而略有差异，具体的输出格式可能会有所不同。

总之，通过执行 connPoolStats 命令，你可以查看 MongoDB 正在使用的连接情况，从而更好地监控和管理数据库的连接资源。

如果块移动操作(moveChunk)失败了，我需要手动清除部分转移的文档吗?

在 MongoDB 中，块移动操作（moveChunk）是一致性（consistent）和确定性（deterministic）的，这意味着当移动操作失败时，MongoDB 会自动进行重试，并且在最终完成移动操作后，数据只会存在于新的分片（shard）中。

因此，当块移动操作失败时，你无需手动清除部分转移的文档。MongoDB 会自动处理重试并确保数据的一致性。一旦移动操作成功完成，数据将只存在于目标分片中，而不会在源分片和目标分片之间存在任何冗余数据。

需要注意的是，尽管 MongoDB 会自动处理移动操作的失败和重试，但在某些情况下，移动操作可能会由于不可恢复的错误而失败，例如网络故障或硬件故障。在这种情况下，你可能需要手动进行故障排除，并尝试修复问题以重新启动移动操作。然而，大多数情况下，MongoDB 能够自动处理移动操作的失败，并确保数据的一致性和完整性。

如果我使用复制技术(replication),可以一部分使用日志(journaling)而其他部分则不使用吗?

是的，在 MongoDB 中，你可以部分地使用日志（journaling）技术来进行复制（replication）。MongoDB 允许你为每个成员节点（member）设置不同的日志记录选项，包括是否启用日志记录和日志记录的延迟等。这样可以根据实际需求和场景来灵活配置复制的行为。

在 MongoDB 复制集（replica set）中，每个成员节点可以独立地配置其日志记录选项。这意味着你可以选择只为某些成员节点启用日志记录，而其他成员节点则不使用日志记录。这种灵活性可以根据实际情况来调整日志记录的级别和行为，以满足不同节点的要求。

需要注意的是，在复制集中，如果某个成员节点启用了日志记录，而其他成员节点没有启用日志记录，那么启用日志记录的成员节点将会在写入数据时进行日志记录，而其他成员节点则不会记录日志。这可能会导致在故障转移（failover）或数据同步时出现一些额外的延迟或不一致性，因此需要谨慎地根据实际情况来配置日志记录选项。

总的来说，MongoDB 提供了灵活的日志记录选项，允许你根据需要对复制集中的每个成员节点进行单独配置，以实现部分使用日志记录的复制技术。

当更新一个正在被迁移的块（Chunk）上的文档时会发生什么？

当更新一个正在被迁移的块（Chunk）上的文档时，更新操作会立即发生在原始块（Chunk）所在的旧分片上。这意味着更新操作将直接在原始分片上执行，并且不会等待迁移操作完成。

MongoDB 在进行块迁移时采用了一个流程，即先更新旧分片上的文档，然后再复制更改到新的目标分片上。因此，即使在迁移过程中，更新操作也会在旧分片上立即生效。

需要注意的是，在更新操作执行后，更改会在所有权转移之前被复制到新的目标分片上。这意味着在迁移操作完成之前，新的目标分片可能不会立即反映更新后的状态。因此，在进行大规模迁移操作时，应谨慎处理更新操作，以确保数据的一致性和正确性。

总的来说，更新一个正在被迁移的块上的文档时，更新操作会立即在旧分片上生效，并且更改会在迁移完成后复制到新的目标分片上。

MongoDB 在 A:{B,C}上建立索引，查询 A:{B,C}和 A:{C,B}都会使用索引吗？

在 MongoDB 中，如果建立了一个复合索引 {A: 1, B: 1, C: 1}，那么查询 {A: value, B: value, C: value} 和 {A: value, C: value, B: value} 都可以使用这个索引，因为索引键的顺序并不影响查询的匹配。索引的建立顺序与查询时指定的键的顺序可以不一致。

换句话说，对于复合索引，只要查询的条件与索引中的键完全匹配，就可以使用该索引。因此，无论是 {A: value, B: value, C: value} 还是 {A: value, C: value, B: value}，都可以使用 {A: 1, B: 1, C: 1} 这个索引来加速查询。

所以，在这种情况下，查询 {A: value, B: value, C: value} 和 {A: value, C: value, B: value} 都会使用索引 {A: 1, B: 1, C: 1}。

如果一个分片（Shard）停止或很慢的时候，发起一个查询会怎样？

当一个分片（Shard）停止或者响应很慢时，发起的查询会有不同的行为：

1. 分片停止：

   • 如果一个分片停止了，那么默认情况下，查询会返回一个错误。因为 MongoDB 默认要求所有的分片都必须处于可用状态，如果有任何一个分片不可用，查询会失败。
   • 可以通过设置查询的选项为 “Partial” 来允许部分失败。在这种情况下，如果一个或多个分片停止了，查询仍然会继续执行，并且会返回那些可用的分片的数据。需要注意的是，部分失败可能会导致数据不完整或不一致，因此需要谨慎使用。

2. 分片响应很慢：

   • 如果一个分片响应很慢，MongoDB 会等待它的响应。MongoDB 的默认行为是等待所有分片的响应，然后将结果返回给客户端。这意味着如果一个分片响应很慢，查询可能会花费更长的时间才能完成。
   • 在某些情况下，如果一个分片的响应非常慢，可能会导致整个查询的性能下降。在这种情况下，可以考虑调整分片集群的配置，或者排查分片节点的性能问题，以提高查询的性能和可靠性。

总的来说，当一个分片停止或者响应很慢时，查询的行为取决于查询的设置以及 MongoDB 的配置。可以通过设置查询选项为 “Partial” 来允许部分失败，并且可以通过调整分片集群的配置来优化查询的性能和可靠性。

MongoDB 支持存储过程吗？如果支持的话，怎么用？

是的，MongoDB 支持存储过程，存储过程以 JavaScript 的形式编写，并保存在特殊的集合 system.js 中。

要创建一个存储过程，可以按照以下步骤操作：

1. 编写 JavaScript 函数，实现存储过程的逻辑。例如：

   // 定义存储过程函数
   var myStoredProcedure = function() {
       // 存储过程逻辑
       print("This is a stored procedure.");
   };
   

2. 将 JavaScript 函数添加到 MongoDB 中的 system.js 集合中。可以使用 db.loadServerScripts() 方法加载 JavaScript 文件，或直接使用 db.system.js 集合的 insert() 方法添加函数定义。例如：

   // 使用 db.loadServerScripts() 方法加载 JavaScript 文件
   db.loadServerScripts("/path/to/your_script.js");
   
   // 或直接添加函数定义到 system.js 集合
   db.system.js.insert({
       _id: "myStoredProcedure",
       value: function() {
           // 存储过程逻辑
           print("This is a stored procedure.");
       }
   });
   

3. 调用存储过程。在 MongoDB Shell 中，可以直接调用已经定义的存储过程。例如：

   // 调用存储过程
   myStoredProcedure();
   

需要注意的是，存储过程是在 MongoDB Shell 中执行的，它们是作为 JavaScript 函数存储在数据库中的，而不是像传统关系型数据库中一样被编译成二进制形式。因此，在 MongoDB 中，存储过程的执行可能会受到 Shell 的执行环境和权限限制。此外，存储过程是在 MongoDB 服务器端执行的，因此会占用服务器资源，需要谨慎设计和使用。

如何理解 MongoDB 中的 GridFS 机制，MongoDB 为何使用 GridFS 来存储文件？

在 MongoDB 中，GridFS 是一种用于存储和检索大型文件的文件规范和机制。GridFS 允许将大文件分割成多个小的文档进行存储，从而克服了 BSON 文档大小的限制，并提供了高效的方式来管理大型文件。

理解 MongoDB 中的 GridFS 机制可以从以下几个方面进行：

1. 文件存储方式：

   • GridFS 将大文件分割成多个小的文档进行存储，每个文档表示文件的一部分。这些小文档可以存储在 MongoDB 的普通集合中，通常分为两个集合：文件存储集合（chunks collection）和文件信息集合（files collection）。

2. 文件分割和索引：

   • GridFS 将大文件分割成固定大小的块（chunks），默认大小为 255KB。每个块都有一个唯一的标识符，并且在文件信息文档中有一个对应的索引，用于表示块的顺序和关系。

3. 元数据存储：

   • GridFS 使用文件信息文档来存储文件的元数据，例如文件名、大小、类型等信息。这些信息可以帮助管理和检索文件。

4. 查询和检索：

   • 对于用户来说，可以通过 MongoDB 提供的 GridFS API 来方便地上传、下载和查询文件。GridFS API 提供了一系列方法来管理文件，例如存储文件、检索文件、删除文件等。

为何使用 GridFS 来存储文件？

1. 适用于大文件：

   • MongoDB 的普通文档有大小限制，不能直接存储大文件。GridFS 解决了这个问题，允许将大文件分割成多个小文档进行存储，从而可以有效地存储和管理大型文件。

2. 一致性和可靠性：

   • GridFS 使用了 MongoDB 的复制和分片机制，保证了文件的一致性和可靠性。即使在发生故障或节点失效时，也能够确保文件的完整性和可用性。

3. 与 MongoDB 集成：

   • GridFS 是 MongoDB 官方支持的文件存储机制，与 MongoDB 集成紧密，可以直接使用 MongoDB 提供的 API 来管理文件，简化了开发和维护的复杂性。

总的来说，MongoDB 中的 GridFS 机制提供了一种高效、可靠且适用于大文件的存储解决方案，为了存储大文件和解决 BSON 文档大小限制问题，MongoDB 使用了 GridFS。