MongoDB写入数据战略

上篇文章引见了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 useswrite ahead loggingto 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等，可以经过上方形式设置。

总之，Journaling 是MongoDB中十分关键的一项性能，相似于相关数据库中的事务日志。Journaling能够使MongoDB由于异常缺点后极速复原。在2.0版本后，自动开启了该性能。和MySQL一样，Mongo 实例启动时会审核journal日志文件，确认能否有须要复原的数据。不过由于提交journal日志会发生写入阻塞，所以它对写入的操作有性能影响，但在消费环境中通常还是开启Journaling的。

数据写入战略

writeconcern 是Mongo针对写操作的参数，示意写恳求对 mongod 实例确实认级别，选择数据的耐久性。它可以用上方三个选项示意。

 w value j  wtimeout number 

◀writeconcern 选项▶

w指定写操作须要运行到多少个数据节点才干前往成功，可认为0、1、2、3或许majority。

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

Delayed secondaries can return write acknowledgment no earlier than the configuredslaveDelay.

留意：

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

b、提前节点的前往写ack，不会早于性能的slavedelay值 。

假设集群有 3 三个数据节点，在w: majority形式下 ，只要要写入两个数据节点即可前往，流程如下：

j示意写操作能否要被耐久化，只能选填 true 或 false。

从3.2版本后，假设指定j:true，即使w:0，只要在恳求的成员数(包括主成员)写入日志后才前往数据。因此，j:true设置保障了MongoDB的数据耐久化。

Changed in version 3.2:Withj: 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 写入战略包括以下几个方面：

在实践经常使用中，可以依据详细的业务需求和系统环境来选用适宜的写入战略，以到达最佳的性能和牢靠性。例如，在数据分歧性要求高的场景中，可以经常使用 majority 写入确认来保障数据同步的牢靠性。而在性能要求高、数据不敏感的场景中，可以经常使用 w 值较小的写入关注点来提高写入性能。