MongoDB写入数据策略

数据库 MariaDB
在实际使用中,可以根据具体的业务需求和系统环境来选择适合的写入策略,以达到最佳的性能和可靠性。例如,在数据一致性要求高的场景中,可以使用 majority 写入确认来保证数据同步的可靠性。而在性能要求高、数据不敏感的场景中,可以使用 w 值较小的写入关注点来提高写入性能。

上篇文章介绍了Mongo读取数据的策略(​​MongoDB读数据策略​​),主要是readconcern、readpreference两参数,其中readconcern作用于服务端,决定了什么时候能读取到数据;readpreference在客户端配置,决定读哪个节点的数据。本文将要介绍Mongo的写入策略,在介绍写入策略前,先简单说明MongoDB的Journaling特性。

Journaling介绍

MongoDB也有防carsh能力,和MySQL类似,也是通过预先写日志(WAL)到文件实现,这文件就是Journaling功能。

To provide durability in the event of a failure, MongoDB uses write ahead logging to on-disk journal files.

◀日志文件▶

开启Journaling功能后,Mongo 会在数据库目录下创建 journal目录,用来存放journal日志,以WiredTiger引擎为例,文件格式是WiredTigerLog.<sequence>,其中<sequence>是从0000000001开始的零填充数字。journal日志文件默认大小为100 MB,超过该限制后,将创建一个新的日记文件,并会自动删除旧的日志文件,仅保留从上一个检查点恢复所需的文件。所以journal日志文件一般情况下只会生成两三个,除非每秒有大量的写操作发生。

◀日志记录▶

journal记录有这几个特点:

它包括由初始写入引起的任何内部写入操作。例如,对集合中文档的更新可能会导致对索引的修改;WiredTiger创建单个日志记录,其中包含更新操作及其关联的索引修改。

每个记录都有一个唯一的标识符。

WiredTiger的最小日志记录大小为128字节。

另外,为了提高存储效率,MongoDB牺牲了一些CPU性能,对WiredTiger引擎对日志数据使用压缩存储,默认压缩方式是snappy压缩,也支持其他压缩方式,比如:zstd、zlib等,可以通过下面方式设置。

storage.wiredTiger.engineConfig.journalCompressor

总之,Journaling 是MongoDB中非常重要的一项功能,类似于关系数据库中的事务日志。Journaling能够使MongoDB由于意外故障后快速恢复。在2.0版本后,默认开启了该功能。和MySQL一样,Mongo 实例启动时会检查journal日志文件,确认是否有需要恢复的数据。不过由于提交journal日志会产生写入阻塞,所以它对写入的操作有性能影响,但在生产环境中通常还是开启Journaling的。

数据写入策略

writeconcern 是Mongo针对写操作的参数,表示写请求对 mongod 实例的确认级别,决定数据的持久性。它可以用下面三个选项表示。

{ w: <value>, j: <boolean>, wtimeout: <number> }

◀writeconcern 选项▶

w指定写操作需要应用到多少个数据节点才能返回成功,可以为0、1、2、3或者majority。

  • w: 0 表示客户端不需要收到任何有关写操作,就直接返回成功。
  • w: 1 表示写主成功,就直接返回成功。
  • w: majority 需要收到多数节点(含主节点)关于操作执行成功的确认,具体个数根据复制集配置自动得出。比如,一主两从3节点的集群,则需要2个节点确认写入成功即可。
  • w: N(N > 1)表示N个数据节点确认才返回成功。w 值越大,对客户端来说,数据的安全性保证越强,同时写操作的延迟越大。w 设置的节点数越多,等待的延迟也就越大。如果 w 等于总节点数,那么一旦其中某个节点出现故障就会导致整个写入失败,这也是有风险的。另外,针对Hidden、delayed和priority为0的数据节点,官方也特别做了说明,如下:

NOTE

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.

注意:

a、副本集中Hidden、delayed和priority为0的成员,可以确认w: <number>的写操作。

b、延迟节点的返回写ack,不会早于配置的slavedelay值  。

如果集群有 3 三个数据节点,在w: majority模式下 ,只需要写入两个数据节点即可返回,流程如下:

图片

j表示写操作是否要被持久化,只能选填 true 或 false。

  • j:false 表示写操作到cache即算作成功。
  • j:true 表示写操作到文件中才算成功。

从3.2版本后,如果指定j:true,即使 w:0 ,只有在请求的成员数(包括主成员)写入日志后才返回数据。因此,j:true设置保证了MongoDB的数据持久化。

Changed in version 3.2: With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal.

另外,仅仅j:true 不保证集群 failover 时发生回滚的写操作。

j: true does not by itself guarantee that the write will not be rolled back due to replica set primary failover.

wtimeout:返回确认的超时时间,单位为毫秒。

如果写入操作超过该值,则返回错误,即使最终写入是成功了,但数据库不会撤销超时写入的数据。如果没有指定 wtimeout 值,则写入操作将无限期阻塞,wtimeout:0 等同于该选项未设置值。同时,这个参数和 WriteConncern 的w值有关,并且只适用于w大于0的情况。比如:w:0,表示可以超时无限大,则不返回错误;w:1,只和主节点确认的超时时间;w:majority,表示需要和多数节点确认超时时间。

◀数据提交策略▶

MongoDB也有和MySQL有类似的提交策略,是由 commitIntervalMs 参数控制,它是日志持久化的间隔时间(以毫秒为单位)。如果想要更好的数据安全,可以设为每毫秒对cache中的数据做硬盘层面的sync;如果需要更好的写入性能,最大可以改为每500毫秒做一次sync。它的取值范围是1 ~ 500毫秒,默认值是100毫秒,不支持in-memory 存储引擎。

总结

MongoDB 写入策略包括以下几个方面:

  • w:指定写入数据后需要在多少个节点上同步写入成功后,才返回确认信息。
  • j:设置 j:true 会将数据写入日志中,可以在节点宕机时恢复数据。但是 j:true 并不保证数据已经写入磁盘文件中。
  • wtimeout:指定写入超时时间。当写入操作达到超时时间时,即使最终成功写入也会返回错误信息。

在实际使用中,可以根据具体的业务需求和系统环境来选择适合的写入策略,以达到最佳的性能和可靠性。例如,在数据一致性要求高的场景中,可以使用 majority 写入确认来保证数据同步的可靠性。而在性能要求高、数据不敏感的场景中,可以使用 w 值较小的写入关注点来提高写入性能。

本文转载自微信公众号「云数据库技术」,可以通过以下二维码关注。转载本文请联系云数据库技术公众号。


责任编辑:武晓燕 来源: 云数据库技术
相关推荐

2023-03-09 11:16:57

MongoDB数据节点

2023-12-18 16:07:15

2017-07-07 10:55:14

数据库MongoDB设计模式

2023-08-03 07:39:10

MongoDB数据备份

2023-09-01 10:20:05

数据库解密

2023-10-26 10:59:13

2023-07-24 09:00:00

数据库

2019-06-24 15:00:52

数据迁移数据转换数据集成

2018-04-25 14:42:00

决胜策略数据

2012-07-26 08:32:38

MongoDB

2017-02-05 14:59:18

MongoDB数据建模数据库

2024-01-10 08:03:50

数据安全网络安全

2013-03-07 10:21:10

大数据策略大数据架构

2021-12-27 09:00:00

数据泄露安全数据丢失

2021-08-16 07:11:56

Go语言进程

2013-03-29 09:28:41

2023-02-16 17:44:13

2022-06-02 13:59:57

数据迁移数据

2020-01-15 14:51:04

Redis5.0数据策略

2009-02-06 09:56:56

软件测试数据仓库测试开发与执行
点赞
收藏

51CTO技术栈公众号