分布式专题(8)之MongoDB存储原理&多文档变乱详解

一、MongoDB存储原理

        存储引擎是数据库的组件，负责管理数据怎样存储在内存和磁盘上，MongoDB支持多个存储引擎，由于差别的存储引擎对特定的工作负载体现更好，选择符合的存储引擎可以显着影相应用步调的性能。
1.1 WiredTiger先容

        MongoDB从3.0开始引入可插拔存储引擎的概念，告急有MMAPV1、WiredTiger存储引擎可供选择。从MongoDB 3.2开始，WiredTiger存储引擎是默认的存储引擎。从4.2版开始，MongoDB删除了废弃的MMAPv1存储引擎。
1.2 WiredTiger读写模子

        读缓存：理想环境下，MongoDB可以提供进似与内存级别的读写性能。WiredTiger引擎实现了数据的二级缓存，第一层是操纵体系的页面缓存，第二层则是引擎提供的内部缓存。

        读数据的流程如下：

• 数据库发起Buffer IO读操纵，由操纵体系将磁盘数据页加载到文件体系 得页缓存区；
  
• 引擎层读取页缓存区的数据，举行解压后存放到内部缓存区；
  
• 在内存中完成匹配查询，将结果返回给应用。
  

        MongoDB为了尽大概包管业务查询的“热数据”能快速被访问，其内部缓存的默认巨细到达了内存的一半，该值由wiredTigerCacheSize参数指定，其默认的盘算公式如下：
wiredTigerCacheSize=Math.max(0.5*(RAM-1GB),256MB)
        写缓存：当数据发生 写入时，MongoDB并不会立即恒久化到磁盘上，而是如今内存中记录这些变更，之后通过CheckPoint机制将变革的数据写入磁盘。如许子处置处罚告急有以下两个缘故原由：

• 如果每一次写入都操纵磁盘I/O，那么开销会非常大，而且相应时长会比力大。
  
• 多个变更的写入可以尽大概举行I/O归并，低落资源负荷；
  

        那MongoDB怎样包管单机的数据可靠性，告急包罗以下两个部分：
        CheckPoint（查抄点）机制：快照（snapshot）形貌了某一时候（point-in-time）数据在内存中的同等性视图，而这种数据的同等性是WiredTiger通过MVCC（多版本并发控制）实现的。当创建CheckPoint时，WiredTiger会在内存中创建全部数据的同等性快照，并将该快照覆盖的全部数据变革一并举行恒久化（fsync）。乐成之后，内存中数据的修改才得以真正生存。默认环境下，MongoDB每60s创建一次CheckPoint，在查抄点写入过程中，上一个查抄点仍然是可用的。如答应以包管一旦堕落，MongoDB仍然能规复到上一个查抄点。
          Journal日记：Journal是一种预写式日记（write ahead log）机制，告急用来增补CheckPoint机制的不敷。如果开启了Journal日记，那么WiredTiger会将每个写操纵的redo日记写入Journal缓冲区，该缓冲区会频仍地将日记恒久化到磁盘上。默认环境下，Journal缓冲区每100ms实行一次恒久化。别的，Journal日记到达100MB，或是应用步调指定journal：true，写操纵都会触发日记的恒久化。一旦MongoDB发生宕机，重启步调时会先规复到上一个查抄点，然后根据Journal日记规复增量的变革。由于Journal日记恒久化的隔断非常短，数据能得到更高的保障，如果按照当前版本的默认设置，则其在断电环境下最多会丢失100ms的写入数据。

        WiredTiger写入数据流程：

• 应用向MongoDB写入数据（插入、修改或删除）。
  
• 数据库从内部缓存中获取当前记录地点的页块，如果不存在则会从磁盘中加载（Buffer I/O）
  
• WiredTiger开始实行写变乱，修改的数据写入页块的一个更新记录表，此时原来的记录仍然保持稳定。
  
• 如果开启了Journal日记，则在写数据的同时会写入一条Journal日记（Redo Log）。该日记在最长不高出100ms之后写入磁盘
  
• 数据库每隔60s实行一次CheckPoint操纵，此时内存中的修改会真正刷入磁盘。
  

        Journal日记的革新周期可以通过参数storage.journal.commitIntervalMs指定，MongoDB 3.4及以下版本的默认值是50ms，而3.6版本之后调解到了100ms。由于Journal日记接纳的是次序I/O写操纵，频仍地写入对磁盘的影响并不是很大。

       CheckPoint的革新周期可以调解storage.syncPeriodSecs参数（默认值60s），在MongoDB 3.4及以下版本中，当Journal日记到达2GB时同样会触发CheckPoint举动。如果应用存在大量随机写入，则CheckPoint大概会造成磁盘I/O的抖动。在磁盘性能不敷的环境下，题目会更加显着，此时适当紧缩CheckPoint周期可以让写入平滑一些。

二、MongoDB多文档变乱详解

2.1变乱简介 

         变乱（transaction）是传统数据库所具备的一项根本本领，其根本目的是为数据的可靠性与同等性提供保障。而在通常的实现中，变乱包罗了一个系列的数据库读写操纵，这些操纵要么全部完成，要么全部取消。比方，在电子商城场景中，当顾客下单购买某件商品时，除了天生订单，还应该同时扣减商品的库存，这些操纵应该被作为一个团体的实行单元举行处置处罚，否则就会产生差别等的环境。
        数据库变乱须要包罗4个根本特性，即常说的ACID，详细如下：

• 原子性（atomicity）：变乱作为一个团体被实行，包罗在此中的对数据库的操纵要么全部被实行，要么都不实行。
  
• 同等性（consistency）：变乱应确保数据库的状态从一个同等状态变化为另一个同等状态。同等状态的寄义是数据库中的数据应满足完备性束缚。
  
• 隔离性（isolation）：多个变乱并发实行时，一个变乱的实行不应影响其他变乱的实行。
  
• 恒久性（durability）：已被提交的变乱对数据库的修改应该是永世性的。
  

2.2 MongoDB多文档变乱

        在MongoDB中，对单个文档的操纵是原子的。由于可以在单个文档结构中利用内嵌文档和数组来得到数据之间的关系，而不必跨多个文档和聚集举行范式化，以是这种单文档原子性制止了许多现实场景中对多文档变乱的需求。
        对于那些须要对多个文档（在单个或多个聚集中）举行原子性读写的场景，MongoDB支持多文档变乱。而利用分布式变乱，变乱可以跨多个操纵、聚集、数据库、文档和分片利用。
        MongoDB 固然已经在 4.2 开始全面支持了多文档变乱，但并不代表各人应该毫无控制地利用它。相反，对变乱的利用原则应该是：能不消只管不消。 通过公道地筹划文档模子，可以规避绝大部分利用变乱的须要性。    
        利用变乱的原则：

• 无论何时，变乱的利用总是能制止则制止；
  
• 模子筹划先于变乱，尽大概用模子筹划规避变乱；
  
• 不要利用过大的变乱（只管控制在 1000 个文档更新以内）；
  
• 当必须利用变乱时，尽大概让涉及变乱的文档分布在同一个分片上，这将有效地进步服从；
  

2.3 MongoDB对变乱的支持

变乱属性	支持程度
Atomocity 原子性	单表单文档 ： 1.x 就支持                         复制集多表多行：4.0                         分片集群多表多行：4.2
Consistency 同等性	writeConcern, readConcern (3.2)
Isolation 隔离性	readConcern (3.2)
Durability 恒久性	Journal and Replication

2.3.1 writeConcern

        writeConcern 决定一个写操纵落到多少个节点上才算乐成。MongoDB支持客户端机动设置写入计谋（writeConcern），以满足差别场景的需求。
        语法格式：
{ w: <value>, j: <boolean>, wtimeout: <number> }
         1）w: 数据写入到number个节点才向用客户端确认
{w:0}对客户端的写入不须要发送确认，实用于性能要求高，但不关注正确性的场景
{w:1}默认的writeConcern，数据写入到Primary就向客户端发送确认
{w:"majority"}数据写入到副本集大多数成员后向客户端发送确认，实用于数据安全性要求比力高的场景，该选项会低落写入性能

         2）j: 写入操纵的journal恒久化后才向客户端确认
默以为{i: false}，如果要求Primary写入恒久化了才向客户端确认，则指定该选项为true
         3）wtimeout: 写入超时时间，仅w的值大于1时有效。
当指定{w:}时，数据须要乐成写入number个节点才算乐成，如果写入过程中有节点故障，大概导致这个条件不停不能满足，从而不停不能向客户端发送确认结果，针对这种环境，客户端可设置wtimeout选项来指定超时时间，当写入过程连续高出该时间仍未竣事，则以为写入失败
         注意事项

• 固然多于半数的 writeConcern 都是安全的，但通常只会设置 majority，由于这是等候写入耽误时间最短的选择；
  
• 不要设置 writeConcern 即是总节点数，由于一旦有一个节点故障，全部写操纵都将失败；
  
• writeConcern 固然会增长写操纵耽误时间，但并不会显着增长集群压力，因此无论是否等候，写操纵终极都会复制到全部节点上。设置 writeConcern 只是让写操纵等候复制后再返回而已；
  
• 应对告急数据应用 {w: “majority”}，平凡数据可以应用 {w: 1} 以确保最佳性能。
  

         在读取数据的过程中我们须要关注以下两个题目：

• 从那边读？
  
• 什么样的数据可以读？
  

        第一个题目是是由 readPreference 来办理，第二个题目则是由 readConcern 来办理2.3.2 readPreference

        readPreference决定利用哪一个节点来满足正在发起的读哀求。可选值包罗：

• primary: 只选择主节点，默认模式；
  
• primaryPreferred：优先选择主节点，如果主节点不可用则选择从节点；
  
• secondary：只选择从节点；
  
• secondaryPreferred：优先选择从节点， 如果从节点不可用则选择主节点；
  
• nearest：根据客户端对节点的 Ping 值判断节点的远近，选择从近来的节点读取。
  

     公道的 ReadPreference 可以极大地扩展复制集的读性能，低落访问耽误。

   

        readPreference 场景举例

• 用户下订单后立即将用户转到订单详情页——primary/primaryPreferred。由于此时从节点大概还没复制到新订单；
  
• 用户查询自己下过的订单——secondary/secondaryPreferred。查询汗青订单对 时效性通常没有太高要求；
  
• 天生报表——secondary。报表对时效性要求不高，但资源需求大，可以在从节点单独处置处罚，制止对线上用户造成影响；
  
• 将用户上传的图片分发到全天下，让各地用户可以大概就近读取——nearest。每个地域的应用选择近来的节点读取数据。
  

        扩展：Tag

        readPreference 只能控制利用一类节点。Tag 则可以将节点选择控制到一个或几个节点。思量以了局景：

• 一个 5 个节点的复制集；
  
• 3 个节点硬件较好，专用于服务线上客户；
  
• 2 个节点硬件较差，专用于天生报表；
  

        可以利用 Tag 来到达如许的控制目的：

• 为 3 个较好的节点打上 {purpose: "online"}；
  
• 为 2 个较差的节点打上 {purpose: "analyse"}；
  
• 在线应用读取时指定 online，报表读取时指定 analyse。
  

2. # 为复制集节点添加标签
3. conf = rs.conf()
4. conf.members[1].tags = { purpose: "online"}
5. conf.members[4].tags = { purpose: "analyse"}
6. rs.reconfig(conf)
8. #查询
9. db.collection.find({}).readPref( "secondary", [ {purpose: "online"} ] )

复制代码

2.3.3 readConcern

        在 readPreference 选择了指定的节点后，readConcern 决定这个节点上的数据哪些是可读的，类似于关系数据库的隔离级别。可选值包罗：

• available：读取全部可用的数据;
  
• local：读取全部可用且属于当前分片的数据;
  
• majority：读取在大多数节点上提交完成的数据;
  
• linearizable：可线性化读取文档，仅支持从主节点读;
  
• snapshot：读取近来快照中的数据，仅可用于多文档变乱;
  

         readConcern: local 和 available，在复制会合 local 和 available 是没有区别的，两者的区别告急体如今分片集上。
        一个 chunk x 正在从 shard1 向 shard2 迁移；整个迁移过程中 chunk x 中的部分数据会在 shard1 和 shard2 中同时存在，但源分片 shard1仍然是chunk x 的负责方：
        全部对 chunkx的读写操纵仍然进入 shard1;config 中记录的信息 chunkx仍然属于 shard1;
        此时如果读 shard2，则会体现出 local 和 available 的区别：

• local:只取到应有由shard2负责的数据(不包罗x);
  
• available:shard2上有什么就读什么(包罗x)
  

        注意事项

• 固然看上去总是应该选择 local，但究竟对结果集举行过滤会造成额外斲丧。在一些无关紧急的场景（比方统计）下，也可以思量 available；
  
• MongoDB <=3.6 不支持对从节点利用 {readConcern: "local"}；
  
• 从主节点读取数据时默认 readConcern 是 local，从从节点读取数据时默认readConcern 是 available（向前兼容缘故原由）
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。