OPTIONS
翻译或纠错本页面

分布式写操作

分片集群上的写操作

对于 分片集群 上的分片集合而言, mongos 程序将写操作从应用导入 负责该数据集的特定 * 部分 * 的分片。 mongos 使用来自于 config database 的集群元数据将写操作路由到合适的分片。

Diagram of a sharded cluster.

Diagram of a sharded cluster.

MongoDB将分片集合中的数据基于 片键 的值合并到 ranges 中。然后,MongoDB将这些数据段分发到分片中。 片键决定了从数据段到分片的分布,这将影响到集群中写操作的性能。

Diagram of the shard key value space segmented into smaller ranges or chunks.

Diagram of the shard key value space segmented into smaller ranges or chunks.

重要

影响一个 单一 文档的更新操作 必须 包含 片键 或者 _id 字段。在一些情况下,有 片键 、影响多个文档的更新操作将会更高效,但是相关的更新操作会广播到所有的分片。

如果片键的值随着每个插入操作增加或者减少,这就说明所有的插入操作都是针对于一个单一的分片。因此,单一分片的容量将会成为该分片集群插入容量的极限。

请查阅 集群教程 以及 MongoDB中的批量插入 了解更多详细信息。

复制集上的写操作

复制集 <replica set>`中,所有的写操作都会到达该集合的 :term:`主节点 :首先执行该写操作然后将该操作记录到主节点的操作日志或者 oplog 中。 这个 oplog 是一个可复写的、对于数据集的操作序列。该集合的 从节点 成员需要持续复制该optlog,并且使用一个异步的进程将这些操作应用与本身。

Diagram of default routing of reads and writes to the primary.

Diagram of default routing of reads and writes to the primary.

写操作(特别是批量操作)的大容量很有可能会造成以下情形:从节点成员很难以一个高效的速率将操作从主节点中复制过来,这将导致从节点的状态滞后于主节点。从节点远远滞后于主节点将意味着:该复制集的正常操作存在问题,特别是 rollbacks 形式带来的 failover ,以及比较常见的 read consistency

为了避免上述问题,您可以定制 write concern ,每100或1,000个操作之后将写操作的确认信息返回复制集的另一个成员 [1] 。这就为从节点与主节点保持一致提供了机会。 写关注可以减缓写操作的总体进度,同时办证从节点能够与主节点保持大量的并行状态。

Write operation to a replica set with write concern level of ``w:2`` or write to the primary and at least one secondary.

Write operation to a replica set with write concern level of w:2 or write to the primary and at least one secondary.

请查阅 副本集确认型(Replica Acknowledged)Oplog大小 以及 修改Oplog大小 了解更多关于复制集和写操作的信息。

[1]

间断性地将一个写关注分配给一个值为 2 或者 majorityw 将会减缓写请求的吞吐量,然而,这种做法将会允许从节点与主节点的状态保持一致。

在 2.6 版更改: Master/Slave 的部署中, MongoDB将 w: "majority" 视为与 w: 1 等价。在MongoDB之前的版本中, w: "majority" 将会在 master/slave 的部署中产生一个错误。

←   写关注 写操作性能  →