- MongoDB CRUD 操作 >
- CRUD 概念 >
- 写操作 >
- 分布式写操作
分布式写操作¶
分片集群上的写操作¶
对于 分片集群 上的分片集合而言, mongos 程序将写操作从应用导入 负责该数据集的特定 * 部分 * 的分片。 mongos 使用来自于 config database 的集群元数据将写操作路由到合适的分片。
MongoDB将分片集合中的数据基于 片键 的值合并到 ranges 中。然后,MongoDB将这些数据段分发到分片中。 片键决定了从数据段到分片的分布,这将影响到集群中写操作的性能。
重要
影响一个 单一 文档的更新操作 必须 包含 片键 或者 _id 字段。在一些情况下,有 片键 、影响多个文档的更新操作将会更高效,但是相关的更新操作会广播到所有的分片。
如果片键的值随着每个插入操作增加或者减少,这就说明所有的插入操作都是针对于一个单一的分片。因此,单一分片的容量将会成为该分片集群插入容量的极限。
请查阅 集群教程 以及 MongoDB中的批量插入 了解更多详细信息。
复制集上的写操作¶
在 复制集 <replica set>`中,所有的写操作都会到达该集合的 :term:`主节点 :首先执行该写操作然后将该操作记录到主节点的操作日志或者 oplog 中。 这个 oplog 是一个可复写的、对于数据集的操作序列。该集合的 从节点 成员需要持续复制该optlog,并且使用一个异步的进程将这些操作应用与本身。
写操作(特别是批量操作)的大容量很有可能会造成以下情形:从节点成员很难以一个高效的速率将操作从主节点中复制过来,这将导致从节点的状态滞后于主节点。从节点远远滞后于主节点将意味着:该复制集的正常操作存在问题,特别是 rollbacks 形式带来的 failover ,以及比较常见的 read consistency 。
为了避免上述问题,您可以定制 write concern ,每100或1,000个操作之后将写操作的确认信息返回复制集的另一个成员 [1] 。这就为从节点与主节点保持一致提供了机会。 写关注可以减缓写操作的总体进度,同时办证从节点能够与主节点保持大量的并行状态。
请查阅 副本集确认型(Replica Acknowledged) 、 Oplog大小 以及 修改Oplog大小 了解更多关于复制集和写操作的信息。
[1] | 间断性地将一个写关注分配给一个值为 2 或者 majority 的 w 将会减缓写请求的吞吐量,然而,这种做法将会允许从节点与主节点的状态保持一致。 在 2.6 版更改: 在 Master/Slave 的部署中, MongoDB将 w: "majority" 视为与 w: 1 等价。在MongoDB之前的版本中, w: "majority" 将会在 master/slave 的部署中产生一个错误。 |