mongodb学习笔记

作者: 彳亍口巴 | 来源:发表于2021-11-01 19:36 被阅读0次

1、MongoDB特点

面向集合存储：MongoDB 是面向集合的，数据以 collection 分组存储。每个 collection 在数据库中都有唯一的名称。
模式自由：集合的概念类似 MySQL 里的表，但它不需要定义任何模式。
结构松散：对于存储在数据库中的文档，不需要设置相同的字段，并且相同的字段不需要相同的数据类型，不同结构的文档可以存在同一个 collection 里。
高效的二进制存储：存储在集合中的文档，是以键值对的形式存在的。键用于唯一标识一个文档，一般是 ObjectId 类型，值是以 BSON 形式存在的。BSON = Binary JSON，是在 JSON 基础上加了一些类型及元数据描述的格式。
支持索引：可以在任意属性上建立索引，包含内部对象。MongoDB 的索引和 MySQL 的索引基本一样，可以在指定属性上创建索引以提高查询的速度。除此之外，MongoDB 还提供创建基于地理空间的索引的能力。
支持 mapreduce：通过分治的方式完成复杂的聚合任务。
支持 failover：通过主从复制机制，可以实现数据备份、故障恢复、读扩展等功能。基于复制集的复制机制提供了自动故障恢复的功能，确保了集群数据不会丢失。
支持分片：MongoDB 支持集群自动切分数据，可以使集群存储更多的数据，实现更大的负载，在数据插入和更新时，能够自动路由和存储。
支持存储大文件：MongoDB 中 BSON 对象最大不能超过 16 MB。对于大文件的存储，BSON 格式无法满足。GridFS 机制提供了一个存储大文件的机制，可以将一个大文件分割成为多个较小的文档进行存储。

2、MongoDB要素

database: 数据库。
collection: 数据集合，相当于 MySQL 的 table。
document: 数据记录行，相当于 MySQL 的 row。
field: 数据域，相当于 MySQL 的 column。
index: 索引。
primary key: 主键。

3、MongoDB数据库

MongoDB副本集默认会创建local、admin数据库，local数据库主要存储副本集的元数据，admin数据库则主要存储MongoDB的用户、角色等信息。

3.1慎用local数据库

local数据库，从名字可以看出，它只会在本地存储数据，即local数据库里的内容不会同步到副本集里其他节点上去；目前local数据库主要存储副本集的配置信息、oplog信息，这些信息是每个Mongod进程独有的，不需要同步到副本集种其他节点。

在使用MongoDB时，重要的数据千万不要存储在local数据库中，否则当一个节点故障时，存储在local里的数据就会丢失。

另外，对于重要的数据，除了不能存储在local数据库，还要注意MongoDB默认的WriteConcern是{w: 1}，即数据写到Primary上（不保证journal已经写成功）就向客户端确认，这时同样存在丢数据的风险。对于重要的数据，可以设置更高级别的如{w: "majority"}来保证数据写到大多数节点后再向客户端确认，当然这对写入的性能会造成一定的影响。

3.2慎用admin数据库

当Mongod启用auth选项时，用户需要创建数据库帐号，访问时根据帐号信息来鉴权，而数据库帐号信息就存储在admin数据库下。

mongo-9551:PRIMARY> use admin
switched to db admin
mongo-9551:PRIMARY> db.getCollectionNames()
[ "system.users", "system.version" ]

system.version存储authSchema的版本信息
system.users存储了数据库帐号信息
如果用户创建了自定义的角色，还会有system.roles集合

用户可以在admin数据库下建立任意集合，存储任何数据，但强烈建议不要使用admin数据库存储应用业务数据，最好创建新的数据库。

admin数据库里的system.users、system.roles2个集合的数据，MongoDB会cache在内存里，这样不用每次鉴权都从磁盘加载用户角色信息。目前cache的维护代码，只有在保证system.users、system.roles的写入都串行化的情况下才能正确工作，详情参考官方issue SERVER-16092

从代码中我们可以看出，MongoDB将admin数据库上的意向写锁(MODE_IX)直接升级为写锁(MODE_X)，也就是说admin数据库的写入操作的锁级别只能到DB级别，不支持多个collection并发写入，在写入时也不支持并发读取。如果用户在admin数据库里存储业务数据，则可能遭遇性能问题。


          if (supportsDocLocking() || enableCollectionLocking) {                 
                   if (supportsDocLocking() || enableCollectionLocking) {
 +
 +            // The check for the admin db is to ensure direct writes to auth collections
 +            // are serialized (see SERVER-16092).
 +            if (_id == resourceIdAdminDB && !isRead) {
 +                _mode = MODE_X;
 +            }
 +
              _lockState->lock(_id, _mode);

3.3config数据库

当 MongoDB 使用分片设置时，config 数据库可用来保存分片的相关信息。

一个 MongoDB 实例的数据结构如下图：

4 MongoDB 索引

4.1 为什么需要索引？

当你抱怨MongoDB集合查询效率低的时候，可能你就需要考虑使用索引了，为了方便后续介绍，先科普下MongoDB里的索引机制（同样适用于其他的数据库比如mysql）。

mongo-9552:PRIMARY> db.person.find()
{ "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack", "age" : 19 }
{ "_id" : ObjectId("571b5dae1b0d530a03b3ce83"), "name" : "rose", "age" : 20 }
{ "_id" : ObjectId("571b5db81b0d530a03b3ce84"), "name" : "jack", "age" : 18 }
{ "_id" : ObjectId("571b5dc21b0d530a03b3ce85"), "name" : "tony", "age" : 21 }
{ "_id" : ObjectId("571b5dc21b0d530a03b3ce86"), "name" : "adam", "age" : 18 }

当你往某各个集合插入多个文档后，每个文档在经过底层的存储引擎持久化后，会有一个位置信息，通过这个位置信息，就能从存储引擎里读出该文档。比如mmapv1引擎里，位置信息是『文件id + 文件内offset 』，在wiredtiger存储引擎（一个KV存储引擎）里，位置信息是wiredtiger在存储文档时生成的一个key，通过这个key能访问到对应的文档；为方便介绍，统一用pos(position的缩写)来代表位置信息。

比如上面的例子里，person集合里包含插入了4个文档，假设其存储后位置信息如下(为方便描述，文档省去_id字段)

位置信息	文档
pos1	{"name" : "jack", "age" : 19 }
pos2	{"name" : "rose", "age" : 20 }
pos3	{"name" : "jack", "age" : 18 }
pos4	{"name" : "tony", "age" : 21}
pos5	{"name" : "adam", "age" : 18}

假设现在有个查询 db.person.find( {age: 18} ), 查询所有年龄为18岁的人，这时需要遍历所有的文档（『全表扫描』），根据位置信息读出文档，对比age字段是否为18。当然如果只有4个文档，全表扫描的开销并不大，但如果集合文档数量到百万、甚至千万上亿的时候，对集合进行全表扫描开销是非常大的，一个查询耗费数十秒甚至几分钟都有可能。

如果想加速 db.person.find( {age: 18} ），就可以考虑对person表的age字段建立索引。

db.person.createIndex( {age: 1} )  // 按age字段创建升序索引

建立索引后，MongoDB会额外存储一份按age字段升序排序的索引数据，索引结构类似如下，索引通常采用类似btree的结构持久化存储，以保证从索引里快速（O(logN)的时间复杂度）找出某个age值对应的位置信息，然后根据位置信息就能读取出对应的文档。

age	位置信息
18	pos3
18	pos5
19	pos1
20	pos2
21	pos4

简单的说，索引就是将文档按照某个（或某些）字段顺序组织起来，以便能根据该字段高效的查询。有了索引，至少能优化如下场景的效率：

查询，比如查询年龄为18的所有人
更新/删除，将年龄为18的所有人的信息更新或删除，因为更新或删除时，需要根据条件先查询出所有符合条件的文档，所以本质上还是在优化查询
排序，将所有人的信息按年龄排序，如果没有索引，需要全表扫描文档，然后再对扫描的结果进行排序

众所周知，MongoDB默认会为插入的文档生成_id字段（如果应用本身没有指定该字段），_id是文档唯一的标识，为了保证能根据文档id快递查询文档，MongoDB默认会为集合创建_id字段的索引。

mongo-9552:PRIMARY> db.person.getIndexes() // 查询集合的索引信息
[
    {
        "ns" : "test.person",  // 集合名
        "v" : 1,               // 索引版本
        "key" : {              // 索引的字段及排序方向
            "_id" : 1           // 根据_id字段升序索引
        },
        "name" : "_id_"        // 索引的名称
    }
]

4.2 MongoDB索引类型

MongoDB支持多种类型的索引，包括单字段索引、复合索引、多key索引、文本索引等，每种类型的索引有不同的使用场合。

4.2.1 单字段索引（Single Field Index）

    db.person.createIndex( {age: 1} )

上述语句针对age创建了单字段索引，其能加速对age字段的各种查询请求，是最常见的索引形式，MongoDB默认创建的id索引也是这种类型。

{age: 1} 代表升序索引，也可以通过{age: -1}来指定降序索引，对于单字段索引，升序/降序效果是一样的。

4.2.2 复合索引 (Compound Index)

复合索引是Single Field Index的升级版本，它针对多个字段联合创建索引，先按第一个字段排序，第一个字段相同的文档按第二个字段排序，依次类推，如下针对age, name这2个字段创建一个复合索引。

    db.person.createIndex( {age: 1, name: 1} )

上述索引对应的数据组织类似下表，与{age: 1}索引不同的时，当age字段相同时，在根据name字段进行排序，所以pos5对应的文档排在pos3之前。

age,name	位置信息
18,adam	pos5
18,jack	pos3
19,jack	pos1
20,rose	pos2
21,tony	pos4

复合索引能满足的查询场景比单字段索引更丰富，不光能满足多个字段组合起来的查询，比如db.person.find( {age： 18， name: "jack"} )，也能满足所以能匹配符合索引前缀的查询，这里{age: 1}即为{age: 1, name: 1}的前缀，所以类似db.person.find( {age： 18} )的查询也能通过该索引来加速；但db.person.find( {name: "jack"} )则无法使用该复合索引。如果经常需要根据『name字段』以及『name和age字段组合』来查询，则应该创建如下的复合索引

db.person.createIndex( {name: 1, age: 1} )

除了查询的需求能够影响索引的顺序，字段的值分布也是一个重要的考量因素，即使person集合所有的查询都是『name和age字段组合』（指定特定的name和age），字段的顺序也是有影响的。

age字段的取值很有限，即拥有相同age字段的文档会有很多；而name字段的取值则丰富很多，拥有相同name字段的文档很少；显然先按name字段查找，再在相同name的文档里查找age字段更为高效。

4.2.3 多key索引（Multikey Index）

当索引的字段为数组时，创建出的索引称为多key索引，多key索引会为数组的每个元素建立一条索引，比如person表加入一个habbit字段（数组）用于描述兴趣爱好，需要查询有相同兴趣爱好的人就可以利用habbit字段的多key索引。

{"name" : "jack", "age" : 19, habbit: ["football, runnning"]}
db.person.createIndex( {habbit: 1} )  // 自动创建多key索引
db.person.find( {habbit: "football"} )

4.2.4 其他类型索引

哈希索引（Hashed Index）是指按照某个字段的hash值来建立索引，目前主要用于MongoDB Sharded Cluster的Hash分片，hash索引只能满足字段完全匹配的查询，不能满足范围查询等。

地理位置索引（Geospatial Index）能很好的解决O2O的应用场景，比如『查找附近的美食』、『查找某个区域内的车站』等。

文本索引（Text Index）能解决快速文本查找的需求，比如有一个博客文章集合，需要根据博客的内容来快速查找，则可以针对博客内容建立文本索引。

4.3 索引额外属性

MongoDB除了支持多种不同类型的索引，还能对索引定制一些特殊的属性。

唯一索引 (unique index)：保证索引对应的字段不会出现相同的值，比如_id索引就是唯一索引
TTL索引：可以针对某个时间字段，指定文档的过期时间（经过指定时间后过期或在某个时间点过期）
部分索引 (partial index): 只针对符合某个特定条件的文档建立索引，3.2版本才支持该特性
稀疏索引(sparse index): 只针对存在索引字段的文档建立索引，可看做是部分索引的一种特殊情况

4.4 索引优化

4.4.1 db profiling

MongoDB支持对DB的请求进行profiling，目前支持3种级别的profiling。

0：不开启profiling
1：将处理时间超过某个阈值(默认100ms)的请求都记录到DB下的system.profile集合（类似于mysql、redis的slowlog）
2：将所有的请求都记录到DB下的system.profile集合（生产环境慎用）

通常，生产环境建议使用1级别的profiling，并根据自身需求配置合理的阈值，用于监测慢请求的情况，并及时的做索引优化。

如果能在集合创建的时候就能『根据业务查询需求决定应该创建哪些索引』，当然是最佳的选择；但由于业务需求多变，要根据实际情况不断的进行优化。索引并不是越多越好，集合的索引太多，会影响写入、更新的性能，每次写入都需要更新所有索引的数据；所以你system.profile里的慢请求可能是索引建立的不够导致，也可能是索引过多导致。

4.4.2 查询计划

索引已经建立了，但查询还是很慢怎么破？这时就得深入的分析下索引的使用情况了，可通过查看下详细的查询计划来决定如何优化。通过执行计划可以看出如下问题

根据某个/些字段查询，但没有建立索引
根据某个/些字段查询，但建立了多个索引，执行查询时没有使用预期的索引。

建立索引前，db.person.find( {age： 18} )必须执行COLLSCAN，即全表扫描。

mongo-9552:PRIMARY> db.person.find({age: 18}).explain()
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.person",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "age" : {
                "$eq" : 18
            }
        },
        "winningPlan" : {
            "stage" : "COLLSCAN",
            "filter" : {
                "age" : {
                    "$eq" : 18
                }
            },
            "direction" : "forward"
        },
        "rejectedPlans" : [ ]
    },
    "serverInfo" : {
        "host" : "localhost",
        "port" : 9552,
        "version" : "3.2.3",
        "gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"
    },
    "ok" : 1
}

建立索引后，通过查询计划可以看出，先进行IXSCAN(从索引中查找)，然后FETCH，读取出满足条件的文档。

mongo-9552:PRIMARY> db.person.find({age: 18}).explain()
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.person",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "age" : {
                "$eq" : 18
            }
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "age" : 1
                },
                "indexName" : "age_1",
                "isMultiKey" : false,
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 1,
                "direction" : "forward",
                "indexBounds" : {
                    "age" : [
                        "[18.0, 18.0]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ ]
    },
    "serverInfo" : {
        "host" : "localhost",
        "port" : 9552,
        "version" : "3.2.3",
        "gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"
    },
    "ok" : 1
}

5 MongoDB ObjectId

ObjectId 可以快速生成并排序，长度为 12 个字节，包括：

一个 4 字节的时间戳，表示 unix 时间戳
5 字节随机值
3 字节递增计数器，初始化为随机值
在 MongoDB 中，存储在集合中的每个文档都需要一个唯一的 _id 字段作为主键。如果插入的文档省略了 _id 字段，则自动为文档生成一个 _id。

6 MongoDB 复制集

复制集简介

Mongodb复制集由一组Mongod实例（进程）组成，包含一个Primary节点和多个Secondary节点，Mongodb Driver（客户端）的所有数据都写入Primary，Secondary从Primary同步写入的数据，以保持复制集内所有成员存储相同的数据集，提供数据的高可用。

下图（图片源于Mongodb官方文档）是一个典型的Mongdb复制集，包含一个Primary节点和2个Secondary节点。

6.1 Primary选举

复制集通过replSetInitiate命令（或mongo shell的rs.initiate()）进行初始化，初始化后各个成员间开始发送心跳消息，并发起Priamry选举操作，获得『大多数』成员投票支持的节点，会成为Primary，其余节点成为Secondary。

初始化复制集

config = {
    _id : "my_replica_set",
    members : [
         {_id : 0, host : "rs1.example.net:27017"},
         {_id : 1, host : "rs2.example.net:27017"},
         {_id : 2, host : "rs3.example.net:27017"},
   ]
}

rs.initiate(config)

『大多数』的定义

假设复制集内投票成员（后续介绍）数量为N，则大多数为 N/2 + 1，当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。

投票成员数	大多数	容忍失效数
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

通常建议将复制集成员数量设置为奇数，从上表可以看出3个节点和4个节点的复制集都只能容忍1个节点失效，从『服务可用性』的角度看，其效果是一样的。（但无疑4个节点能提供更可靠的数据存储）

6.2 特殊的Secondary

正常情况下，复制集的Seconary会参与Primary选举（自身也可能会被选为Primary），并从Primary同步最新写入的数据，以保证与Primary存储相同的数据。

Secondary可以提供读服务，增加Secondary节点可以提供复制集的读服务能力，同时提升复制集的可用性。另外，Mongodb支持对复制集的Secondary节点进行灵活的配置，以适应多种场景的需求。

6.2.1 Arbiter

Arbiter节点只参与投票，不能被选为Primary，并且不从Primary同步数据。

比如你部署了一个2个节点的复制集，1个Primary，1个Secondary，任意节点宕机，复制集将不能提供服务了（无法选出Primary），这时可以给复制集添加一个Arbiter节点，即使有节点宕机，仍能选出Primary。

Arbiter本身不存储数据，是非常轻量级的服务，当复制集成员为偶数时，最好加入一个Arbiter节点，以提升复制集可用性。

6.2.2 Priority0

Priority0节点的选举优先级为0，不会被选举为Primary

比如你跨机房A、B部署了一个复制集，并且想指定Primary必须在A机房，这时可以将B机房的复制集成员Priority设置为0，这样Primary就一定会是A机房的成员。（注意：如果这样部署，最好将『大多数』节点部署在A机房，否则网络分区时可能无法选出Primary）

6.2.3 Vote0

Mongodb 3.0里，复制集成员最多50个，参与Primary选举投票的成员最多7个，其他成员（Vote0）的vote属性必须设置为0，即不参与投票。

6.2.4Hidden

Hidden节点不能被选为主（Priority为0），并且对Driver不可见。

因Hidden节点不会接受Driver的请求，可使用Hidden节点做一些数据备份、离线计算的任务，不会影响复制集的服务。

6.2.5 Delayed

Delayed节点必须是Hidden节点，并且其数据落后与Primary一段时间（可配置，比如1个小时）。

因Delayed节点的数据比Primary落后一段时间，当错误或者无效的数据写入Primary时，可通过Delayed节点的数据来恢复到之前的时间点。

6.3 数据同步

Primary与Secondary之间通过oplog来同步数据，Primary上的写操作完成后，会向特殊的local.oplog.rs特殊集合写入一条oplog，Secondary不断的从Primary取新的oplog并应用。

因oplog的数据会不断增加，local.oplog.rs被设置成为一个capped集合，当容量达到配置上限时，会将最旧的数据删除掉。另外考虑到oplog在Secondary上可能重复应用，oplog必须具有幂等性，即重复应用也会得到相同的结果。

如下oplog的格式，包含ts、h、op、ns、o等字段

{
  "ts" : Timestamp(1446011584, 2),
  "h" : NumberLong("1687359108795812092"), 
  "v" : 2, 
  "op" : "i", 
  "ns" : "test.nosql", 
  "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" } 
}

ts：操作时间，当前timestamp + 计数器，计数器每秒都被重置
h：操作的全局唯一标识
v：oplog版本信息
op：操作类型
- i：插入操作
- u：更新操作
- d：删除操作
- c：执行命令（如createDatabase，dropDatabase）
- n：空操作，特殊用途
ns：操作针对的集合
o：操作内容，如果是更新操作
o2：操作查询条件，仅update操作包含该字段

Secondary初次同步数据时，会先进行init sync，从Primary（或其他数据更新的Secondary）同步全量数据，然后不断通过tailable cursor从Primary的local.oplog.rs集合里查询最新的oplog并应用到自身。

init sync过程包含如下步骤

T1时间，从Primary同步所有数据库的数据（local除外），通过listDatabases + listCollections + cloneCollection敏命令组合完成，假设T2时间完成所有操作。
从Primary应用[T1-T2]时间段内的所有oplog，可能部分操作已经包含在步骤1，但由于oplog的幂等性，可重复应用。
根据Primary各集合的index设置，在Secondary上为相应集合创建index。（每个集合_id的index已在步骤1中完成）。

oplog集合的大小应根据DB规模及应用写入需求合理配置，配置得太大，会造成存储空间的浪费；配置得太小，可能造成Secondary的init sync一直无法成功。比如在步骤1里由于DB数据太多、并且oplog配置太小，导致oplog不足以存储[T1, T2]时间内的所有oplog，这就Secondary无法从Primary上同步完整的数据集。

6.4 修改复制集配置

当需要修改复制集时，比如增加成员、删除成员、或者修改成员配置（如priorty、vote、hidden、delayed等属性），可通过replSetReconfig命令（rs.reconfig()）对复制集进行重新配置。

比如将复制集的第2个成员Priority设置为2，可执行如下命令

cfg = rs.conf();
cfg.members[1].priority = 2;
rs.reconfig(cfg);

6.5 细说Primary选举

Primary选举除了在复制集初始化时发生，还有如下场景

复制集被reconfig
Secondary节点检测到Primary宕机时，会触发新Primary的选举
当有Primary节点主动stepDown（主动降级为Secondary）时，也会触发新的Primary选举

Primary的选举受节点间心跳、优先级、最新的oplog时间等多种因素影响。

6.5.1 节点间心跳

复制集成员间默认每2s会发送一次心跳信息，如果10s未收到某个节点的心跳，则认为该节点已宕机；如果宕机的节点为Primary，Secondary（前提是可被选为Primary）会发起新的Primary选举。

6.5.2 节点优先级

每个节点都倾向于投票给优先级最高的节点
优先级为0的节点不会主动发起Primary选举
当Primary发现有优先级更高Secondary，并且该Secondary的数据落后在10s内，则Primary会主动降级，让优先级更高的Secondary有成为Primary的机会。

6.5.3 Optime

拥有最新optime（最近一条oplog的时间戳）的节点才能被选为主。

6.5.4 网络分区

只有更大多数投票节点间保持网络连通，才有机会被选Primary；如果Primary与大多数的节点断开连接，Primary会主动降级为Secondary。当发生网络分区时，可能在短时间内出现多个Primary，故Driver在写入时，最好设置『大多数成功』的策略，这样即使出现多个Primary，也只有一个Primary能成功写入大多数。

6.6 复制集的读写设置

6.6.1 Read Preference

默认情况下，复制集的所有读请求都发到Primary，Driver可通过设置Read Preference来将读请求路由到其他的节点。

primary：默认规则，所有读请求发到Primary
primaryPreferred： Primary优先，如果Primary不可达，请求Secondary
secondary：所有的读请求都发到secondary
secondaryPreferred：Secondary优先，当所有Secondary不可达时，请求Primary
nearest：读请求发送到最近的可达节点上（通过ping探测得出最近的节点）

6.6.2 Write Concern

默认情况下，Primary完成写操作即返回，Driver可通过设置[Write Concern(https://docs.mongodb.org/manual/core/write-concern/)来设置写成功的规则。

如下的write concern规则设置写必须在大多数节点上成功，超时时间为5s。

db.products.insert(
  { item: "envelopes", qty : 100, type: "Clasp" },
  { writeConcern: { w: majority, wtimeout: 5000 } }
)

上面的设置方式是针对单个请求的，也可以修改副本集默认的write concern，这样就不用每个请求单独设置。

cfg = rs.conf()
cfg.settings = {}
cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }
rs.reconfig(cfg)

6.7 异常处理（rollback）

当Primary宕机时，如果有数据未同步到Secondary，当Primary重新加入时，如果新的Primary上已经发生了写操作，则旧Primary需要回滚部分操作，以保证数据集与新的Primary一致。

旧Primary将回滚的数据写到单独的rollback目录下，数据库管理员可根据需要使用mongorestore进行恢复。

7 MongoDB分片集

7.1 为什么需要Sharded cluster？

MongoDB目前3大核心优势：『灵活模式』+ 『高可用性』 + 『可扩展性』，通过json文档来实现灵活模式，通过复制集来保证高可用，通过Sharded cluster来保证可扩展性。

当MongoDB复制集遇到下面的业务场景时，你就需要考虑使用Sharded cluster

存储容量需求超出单机磁盘容量
活跃的数据集超出单机内存容量，导致很多请求都要从磁盘读取数据，影响性能
写IOPS超出单个MongoDB节点的写服务能力

如上图所示，Sharding Cluster使得集合的数据可以分散到多个Shard（复制集或者单个Mongod节点）存储，使得MongoDB具备了横向扩展（Scale out）的能力，丰富了MongoDB的应用场景。

7.2 Sharded cluster架构

Sharded cluster由Shard、Mongos和Config server 3个组件构成。

Mongos是Sharded cluster的访问入口，强烈建议所有的管理操作、读写操作都通过mongos来完成，以保证cluster多个组件处于一致的状态。

Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server（下一节详细介绍），而用户的数据则会分散存储到各个shard。Mongos启动后，会从config server加载元数据，开始提供服务，将用户的请求正确路由到对应的Shard。

7.3 数据分布策略

Sharded cluster支持将单个集合的数据分散存储在多个shard上，用户可以指定根据集合内文档的某个字段即shard key来分布数据，目前主要支持2种数据分布的策略，范围分片（Range based sharding）或hash分片（Hash based sharding）。

7.3.1 范围分片

如上图所示，集合根据x字段来分片，x的取值范围为[minKey, maxKey]（x为整型，这里的minKey、maxKey为整型的最小值和最大值），将整个取值范围划分为多个chunk，每个chunk（通常配置为64MB）包含其中一小段的数据。

Chunk1包含x的取值在[minKey, -75)的所有文档，而Chunk2包含x取值在[-75, 25)之间的所有文档... 每个chunk的数据都存储在同一个Shard上，每个Shard可以存储很多个chunk，chunk存储在哪个shard的信息会存储在Config server种，mongos也会根据各个shard上的chunk的数量来自动做负载均衡。

范围分片能很好的满足『范围查询』的需求，比如想查询x的值在[-30, 10]之间的所有文档，这时mongos直接能将请求路由到Chunk2，就能查询出所有符合条件的文档。

范围分片的缺点在于，如果shardkey有明显递增（或者递减）趋势，则新插入的文档多会分布到同一个chunk，无法扩展写的能力，比如使用_id作为shard key，而MongoDB自动生成的id高位是时间戳，是持续递增的。

7.3.2 Hash分片

Hash分片是根据用户的shard key计算hash值（64bit整型），根据hash值按照『范围分片』的策略将文档分布到不同的chunk。

Hash分片与范围分片互补，能将文档随机的分散到各个chunk，充分的扩展写能力，弥补了范围分片的不足，但不能高效的服务范围查询，所有的范围查询要分发到后端所有的Shard才能找出满足条件的文档。

7.3.3 合理的选择shard key

选择shard key时，要根据业务的需求及『范围分片』和『Hash分片』2种方式的优缺点合理选择，同时还要注意shard key的取值一定要足够多，否则会出现单个jumbo chunk，即单个chunk非常大并且无法分裂（split）；比如某集合存储用户的信息，按照age字段分片，而age的取值非常有限，必定会导致单个chunk非常大。

7.4 Mongos

Mongos作为Sharded cluster的访问入口，所有的请求都由mongos来路由、分发、合并，这些动作对客户端driver透明，用户连接mongos就像连接mongod一样使用。

Mongos会根据请求类型及shard key将请求路由到对应的Shard

7.4.1 查询请求

查询请求不包含shard key，则必须将查询分发到所有的shard，然后合并查询结果返回给客户端
查询请求包含shard key，则直接根据shard key计算出需要查询的chunk，向对应的shard发送查询请求

7.4.2 写请求

写操作必须包含shard key，mongos根据shard key算出文档应该存储到哪个chunk，然后将写请求发送到chunk所在的shard。

7.4.3 更新/删除请求

更新、删除请求的查询条件必须包含shard key或者_id，如果是包含shard key，则直接路由到指定的chunk，如果只包含_id，则需将请求发送至所有的shard。

7.4.4 其他命令请求

除增删改查外的其他命令请求处理方式都不尽相同，有各自的处理逻辑，比如listDatabases命令，会向每个Shard及Config Server转发listDatabases请求，然后将结果进行合并。

7.5 Config Server

7.5.1 config database

Config server存储Sharded cluster的所有元数据，所有的元数据都存储在config数据库，3.2版本后，Config Server可部署为一个独立的复制集，极大的方便了Sharded cluster的运维管理。

mongos> use config
switched to db config
mongos> db.getCollectionNames()
[
    "shards",
    "actionlog",
    "chunks",
    "mongos",
    "collections",
    "lockpings",
    "settings",
    "version",
    "locks",
    "databases",
    "tags",
    "changelog"
]

7.5.2 config.shards

config.shards集合存储各个Shard的信息，可通过addShard、removeShard命令来动态的从Sharded cluster里增加或移除shard。如下所示，cluster目前拥有2个shard，均为复制集。

mongos> db.addShard("mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003")
mongos> db.addShard("mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003")
mongos> db.shards.find()
{ "_id" : "mongo-9003", "host" : "mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003" }
{ "_id" : "mongo-9004", "host" : "mongo-9004/10.1.72.135:9004,10.1.72.136:9004,10.1.72.137:9004" }

7.5.3 config.databases

config.databases集合存储所有数据库的信息，包括DB是否开启分片，primary shard信息，对于数据库内没有开启分片的集合，所有的数据都会存储在数据库的primary shard上。

如下所示，shtest数据库是开启分片的（通过enableSharding命令），primary shard为mongo-9003；而test数据库没有开启分片，primary shard为mongo-9003。

mongos> sh.enableSharding("shtest")

{ "ok" : 1 }

 mongos> db.databases.find()
 { "_id" : "shtest", "primary" : "mongo-9003", "partitioned" : true }
 { "_id" : "test", "primary" : "mongo-9003", "partitioned" : false }

Sharded cluster在数据库创建时，为用户选择当前存储数据量最小的shard作为数据库的primary shard，用户也可调用movePrimary命令来改变primary shard以实现负载均衡，一旦primary shard发生改变，mongos会自动将数据迁移到的新的primary shard上。

7.5.4 config.colletions

数据分片是针对集合维度的，某个数据库开启分片功能后，如果需要让其中的集合分片存储，则需调用shardCollection命令来针对集合开启分片。

如下命令，针对shtest数据里的hello集合开启分片，使用x字段作为shard key来进行范围分片。


mongos> sh.shardCollection("shtest.coll", {x: 1})
{ "collectionsharded" : "shtest.coll", "ok" : 1 }
mongos> db.collections.find()
{ "_id" : "shtest.coll", "lastmodEpoch" : ObjectId("57175142c34046c3b556d302"), "lastmod" : ISODate("1970-02-19T17:02:47.296Z"), "dropped" : false, "key" : { "x" : 1 }, "unique" : false }

7.5.5 config.chunks

集合分片开启后，默认会创建一个新的chunk，shard key取值[minKey, maxKey]内的文档（即所有的文档）都会存储到这个chunk。当使用Hash分片策略时，也可以预先创建多个chunk，以减少chunk的迁移。

mongos> db.chunks.find({ns: "shtest.coll"})
{ "_id" : "shtest.coll-x_MinKey", "ns" : "shtest.coll", "min" : { "x" : { "$minKey" : 1 } }, "max" : { "x" : { "$maxKey" : 1 } }, "shard" : "mongo-9003", "lastmod" : Timestamp(1, 0), "lastmodEpoch" : ObjectId("5717530fc34046c3b556d361") }

当chunk里写入的数据量增加到一定阈值时，会触发chunk分裂，将一个chunk的范围分裂为多个chunk，当各个shard上chunk数量不均衡时，会触发chunk在shard间的迁移。如下所示，shtest.coll的一个chunk，在写入数据后分裂成3个chunk。

mongos> use shtest
mongos> for (var i = 0; i < 10000; i++) { db.coll.insert( {x: i} ); }
mongos> use config
 mongos> db.chunks.find({ns: "shtest.coll"})
 { "_id" : "shtest.coll-x_MinKey", "lastmod" : Timestamp(5, 1), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : { "$minKey" : 1 } }, "max" : { "x" : 1 }, "shard" : "mongo-9003" }
 { "_id" : "shtest.coll-x_1.0", "lastmod" : Timestamp(4, 0), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : 1 }, "max" : { "x" : 31 }, "shard" : "mongo-9003" }
 { "_id" : "shtest.coll-x_31.0", "lastmod" : Timestamp(5, 0), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : 31 }, "max" : { "x" : { "$maxKey" : 1 } }, "shard" : "mongo-9004" }

7.5.6 config.settings

config.settings集合里主要存储sharded cluster的配置信息，比如chunk size，是否开启balancer等

mongos> db.settings.find()
{ "_id" : "chunksize", "value" : NumberLong(64) }
{ "_id" : "balancer", "stopped" : false }

7.5.7 其他集合

config.tags主要存储sharding cluster标签（tag）相关的你洗，以实现根据tag来分布chunk的功能
config.changelog主要存储sharding cluster里的所有变更操作，比如balancer迁移chunk的动作就会记录到changelog里。
config.mongos存储当前集群所有mongos的信息
config.locks存储锁相关的信息，对某个集合进行操作时，比如moveChunk，需要先获取锁，避免多个mongos同时迁移同一个集合的chunk。

8 MongoDB 聚合

MongoDB 聚合框架（Aggregation Framework）是一个计算框架，功能是：
作用在一个或几个集合上。
对集合中的数据进行的一系列运算。
将这些数据转化为期望的形式。
MongoDB 提供了三种执行聚合的方法：聚合管道，map-reduce 和单一目的聚合方法（如 count、distinct 等方法）。

8.1 聚合管道

在聚合管道中，整个聚合运算过程称为管道（pipeline），它是由多个步骤（stage）组成的，每个管道的工作流程是：
接受一系列原始数据文档
对这些文档进行一系列运算
结果文档输出给下一个 stage
聚合计算基本格式如下：

pipeline = [ $stage1,$ stage2, ...$stageN];
db.collection.aggregate( pipeline, { options } )

8.2 map-reduce

map-reduce 操作包括两个阶段：map 阶段处理每个文档并将 key 与 value 传递给 reduce 函数进行处理，reduce 阶段将map 操作的输出组合在一起。map-reduce 可使用自定义 JavaScript 函数来执行 map 和 reduce 操作，以及可选的 finalize 操作。通常情况下效率比聚合管道低。

8.3 单一目的聚合方法

主要包括以下三个：

db.collection.estimatedDocumentCount()

db.collection.count()

db.collection.distinct()

11 MongoDB 一致性

分布式系统有个 PACELC 理论。根据 CAP，在一个存在网络分区（P）的分布式系统中，要面临在可用性（A）和一致性（C）之间的权衡，除此之外（E），即使没有网络分区的存在，在实际系统中，我们也要面临在访问延迟（L）和一致性（C）之间的权衡。MongoDB 的一致性模型对读写操作 L 和 C 的选择提供了丰富的选项。

9.1 因果一致性

单节点的数据库由于为读写操作提供了顺序保证，因此实现了因果一致性。分布式系统同样可以提供这些保证，但必须对所有节点上的相关事件进行协调和排序。

以下是一个不遵循因果一致性的例子：

为了保持因果一致性，必须有以下保证：

Read your writes	读操作必须能够反映出在其之前的写操作。
Monotonic reads	如果某个读操作已经读取到某个对象的某个值，那么任何后续访问都不应该返回在此之前的值。
Monotonic writes	如果某个写操作先于其它写操作执行，写操作顺序不应受到任何其他条件打乱。
Writes follow reads	如果某个写操作发生在读操作之后，则该写操作将等待读操作完成后进行。

实现因果一致性的单号读写应遵循以下流程：

为了建立复制集和分片集事件的全局偏序关系，MongoDB 实现了一个逻辑时钟，称为 lamport logical clock。每个写操作在应用于主节点时都会被分配一个时间值。这个值可以在副本和分片之间进行比较。从驱动到查询路由器再到数据承载节点，分片集群中的每个成员都必须在每条消息中跟踪和发送其最新时间值，从而允许分片之间的每个节点在最新时间保持一致。主节点将最新的时间值赋值给后续的写入，这为任何一系列相关操作创建了一个因果顺序。节点可以使用这个因果顺序在执行所需的读或写之前等待，以确保它在另一个操作之后发生。

从 MongoDB 3.6 开始，在客户端会话中开启因果一致性，保证 read concern 为 majority 的读操作和 write concern 为 majority 的写操作的关联序列具有因果关系。应用程序必须确保一次只有一个线程在客户端会话中执行这些操作。

对于因果相关的操作：

客户端开启客户端会话，需满足以下条件：read concern 为 majority，数据已被大多数复制集成员确认并且是持久化的；write concern 为 majority，确认该操作已应用于复制集中大多数可投票成员。
当客户端发出 read concern 为 majority 的读操作和 write concern 为 majority 的写操作的序列时，客户端将会话信息包含在每个操作中。
对于与会话相关联的每个 read concern 为 majority 的读操作和 write concern 为 majority 的写操作，即使操作出错，MongoDB 也会返回操作时间和集群时间。
相关的客户端会话会跟踪这两个时间字段。

9.2 线性一致性

线性一致性又被称为强一致性。CAP 中的 C 指的就是线性一致性。顺序一致性中进程只关心各自的顺序一样就行，不需要与全局时钟一致。线性一致性是顺序一致性的进化版，要求顺序一致性的这种偏序（partial order）要达到全序（total order）。

在实现了线性一致性的系统中，任何操作在该系统生效的时刻都对应时间轴上的一个点。把这些时刻连接成一条线，则这条线会一直沿时间轴向前，不会反向。任何操作都需要互相比较决定发生的顺序。

以下是一个线性一致性的系统示例：

在以上系统中，写操作生效之前的任何时刻，读取值均为 1，生效后均为 2。也就是说，任何读操作都能读到某个数据的最近一次写的数据。系统中的所有进程看到的操作顺序，都遵循全局时钟的顺序。

11.3 readConcern

MongoDB 可以通过 writeConcern 来定制写策略，3.2版本后又引入了 readConcern 来灵活的定制读策略。

9.3.1 readConcern vs readPreference

MongoDB 控制读策略，还有一个 readPreference 的设置，为了避免混淆，先简单说明下二者的区别。

readPreference 主要控制客户端 Driver 从复制集的哪个节点读取数据，这个特性可方便的实现读写分离、就近读取等策略。
- primary 只从 primary 节点读数据，这个是默认设置
- primaryPreferred 优先从 primary 读取，primary 不可服务，从 secondary 读
- secondary 只从 scondary 节点读数据
- secondaryPreferred 优先从 secondary 读取，没有 secondary 成员时，从 primary 读取
- nearest 根据网络距离就近读取
readConcern 决定到某个读取数据时，能读到什么样的数据。
- local 能读取任意数据，这个是默认设置
- majority 只能读取到『成功写入到大多数节点的数据』

readPreference 和 readConcern 可以配合使用。

9.3.2 readConcern 解决什么问题？

readConcern 的初衷在于解决『脏读』的问题，比如用户从 MongoDB 的 primary 上读取了某一条数据，但这条数据并没有同步到大多数节点，然后 primary 就故障了，重新恢复后这个primary 节点会将未同步到大多数节点的数据回滚掉，导致用户读到了『脏数据』。

当指定 readConcern 级别为 majority 时，能保证用户读到的数据『已经写入到大多数节点』，而这样的数据肯定不会发生回滚，避免了脏读的问题。

需要注意的是，readConcern 能保证读到的数据『不会发生回滚』，但并不能保证读到的数据是最新的，这个官网上也有说明。

Regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.

有用户误以为，readConcern 指定为 majority 时，客户端会从大多数的节点读取数据，然后返回最新的数据。

实际上并不是这样，无论何种级别的 readConcern，客户端都只会从『某一个确定的节点』（具体是哪个节点由 readPreference 决定）读取数据，该节点根据自己看到的同步状态视图，只会返回已经同步到大多数节点的数据。

readConcern 实现原理

MongoDB 要支持 majority 的 readConcern 级别，必须设置replication.enableMajorityReadConcern参数，加上这个参数后，MongoDB 会起一个单独的snapshot 线程，会周期性的对当前的数据集进行 snapshot，并记录 snapshot 时最新 oplog的时间戳，得到一个映射表。

最新 oplog 时间戳	snapshot	状态
t0	snapshot0	committed
t1	snapshot1	uncommitted
t2	snapshot2	uncommitted
t3	snapshot3	uncommitted

只有确保 oplog 已经同步到大多数节点时，对应的 snapshot 才会标记为 commmited，用户读取时，从最新的 commited 状态的 snapshot 读取数据，就能保证读到的数据一定已经同步到的大多数节点。

关键的问题就是如何确定『oplog 已经同步到大多数节点』？

primary 节点

secondary 节点在自身oplog发生变化时，会通过 replSetUpdatePosition 命令来将 oplog 进度立即通知给 primary，另外心跳的消息里也会包含最新 oplog 的信息；通过上述方式，primary 节点能很快知道 oplog 同步情况，知道『最新一条已经同步到大多数节点的 oplog』，并更新 snapshot 的状态。比如当t2已经写入到大多数据节点时，snapshot1、snapshot2都可以更新为 commited 状态。（不必要的 snapshot也会定期被清理掉）

secondary 节点

secondary 节点拉取 oplog 时，primary 节点会将『最新一条已经同步到大多数节点的 oplog』的信息返回给 secondary 节点，secondary 节点通过这个oplog时间戳来更新自身的 snapshot 状态。

9.3.3 注意事项

目前 readConcern 主要用于跟 mongos 与 config server 的交互上，参考MongoDB Sharded Cluster 路由策略
使用 readConcern 需要配置replication.enableMajorityReadConcern选项
只有支持 readCommited 隔离级别的存储引擎才能支持 readConcern，比如 wiredtiger 引擎，而 mmapv1引擎则不能支持。

11.4 MongoDB WriteConcern

MongoDB支持客户端灵活配置写入策略（writeConcern），以满足不同场景的需求。

db.collection.insert({x: 1}, {writeConcern: {w: 1}})

9.4.1 writeConcern选项

MongoDB支持的WriteConncern选项如下

w: <number>，数据写入到number个节点才向用客户端确认
- {w: 0} 对客户端的写入不需要发送任何确认，适用于性能要求高，但不关注正确性的场景
- {w: 1} 默认的writeConcern，数据写入到Primary就向客户端发送确认
- {w: "majority"} 数据写入到副本集大多数成员后向客户端发送确认，适用于对数据安全性要求比较高的场景，该选项会降低写入性能
j: <boolean> ，写入操作的journal持久化后才向客户端确认
- 默认为"{j: false}，如果要求Primary写入持久化了才向客户端确认，则指定该选项为true
wtimeout: <millseconds>，写入超时时间，仅w的值大于1时有效。
- 当指定{w: }时，数据需要成功写入number个节点才算成功，如果写入过程中有节点故障，可能导致这个条件一直不能满足，从而一直不能向客户端发送确认结果，针对这种情况，客户端可设置wtimeout选项来指定超时时间，当写入过程持续超过该时间仍未结束，则认为写入失败。

9.4.2 {w: "majority"}解析

{w: 1}、{j: true}等writeConcern选项很好理解，Primary等待条件满足发送确认；但{w: "majority"}则相对复杂些，需要确认数据成功写入到大多数节点才算成功，而MongoDB的复制是通过Secondary不断拉取oplog并重放来实现的，并不是Primary主动将写入同步给Secondary，那么Primary是如何确认数据已成功写入到大多数节点的？

Client向Primary发起请求，指定writeConcern为{w: "majority"}，Primary收到请求，本地写入并记录写请求到oplog，然后等待大多数节点都同步了这条/批oplog（Secondary应用完oplog会向主报告最新进度)。
Secondary拉取到Primary上新写入的oplog，本地重放并记录oplog。为了让Secondary能在第一时间内拉取到主上的oplog，find命令支持一个awaitData的选项，当find没有任何符合条件的文档时，并不立即返回，而是等待最多maxTimeMS(默认为2s)时间看是否有新的符合条件的数据，如果有就返回；所以当新写入oplog时，备立马能获取到新的oplog。
Secondary上有单独的线程，当oplog的最新时间戳发生更新时，就会向Primary发送replSetUpdatePosition命令更新自己的oplog时间戳。
当Primary发现有足够多的节点oplog时间戳已经满足条件了，向客户端发送确认。

10 Mongodb Wiredtiger存储引擎实现原理

Mongodb-3.2已经WiredTiger设置为了默认的存储引擎，按照Mongodb默认的配置，WiredTiger的写操作会先写入Cache，并持久化到WAL(Write ahead log)，每60s或log文件达到2GB时会做一次Checkpoint，将当前的数据持久化，产生一个新的快照。

Wiredtiger的Cache采用Btree的方式组织，每个Btree节点为一个page，root page是btree的根节点，internal page是btree的中间索引节点，leaf page是真正存储数据的叶子节点；btree的数据以page为单位按需从磁盘加载或写入磁盘。

Wiredtiger采用Copy on write的方式管理修改操作（insert、update、delete），修改操作会先缓存在cache里，以skiplist的形式组织；持久化时，修改操作不会在原来的leaf page上进行，而是写入新分配的page，每次checkpoint都会产生一个新的root page。

Checkpoint时，wiredtiger需要将btree修改过的PAGE都进行持久化存储，每个btree对应磁盘上一个物理文件，btree的每个PAGE以文件里的extent形式（由文件offset + size标识）存储，一个Checkpoit包含如下元数据：

root page地址，地址由文件offset，size及内容的checksum组成

alloc extent list地址，存储从上次checkpoint起新分配的extent列表
discard extent list地址，存储从上次checkpoint起丢弃的extent列表
available extent list地址，存储可分配的extent列表，只有最新的checkpoint包含该列表
file size 如需恢复到该checkpoint的状态，将文件truncate到file size即可

Mongodb里一个典型的Wiredtiger数据库存储布局大致如下

$tree
.
├── journal
│   ├── WiredTigerLog.0000000003
│   └── WiredTigerPreplog.0000000001
├── WiredTiger
├── WiredTiger.basecfg
├── WiredTiger.lock
├── WiredTiger.turtle
├── admin
│   ├── table1.wt
│   └── table2.wt
├── local
│   ├── table1.wt
│   └── table2.wt        
└── WiredTiger.wt

WiredTiger.basecfg存储基本配置信息
WiredTiger.lock用于防止多个进程连接同一个Wiredtiger数据库
table*.wt存储各个tale（数据库中的表）的数据
WiredTiger.wt是特殊的table，用于存储所有其他table的元数据信息
WiredTiger.turtle存储WiredTiger.wt的元数据信息
journal存储Write ahead log

一次Checkpoint的大致流程如下

对所有的table进行一次Checkpoint，每个table的Checkpoint的元数据更新至WiredTiger.wt
对WiredTiger.wt进行Checkpoint，将该table Checkpoint的元数据更新至临时文件WiredTiger.turtle.set
将WiredTiger.turtle.set重命名为WiredTiger.turtle

上述过程如中间失败，Wiredtiger在下次连接初始化时，首先将数据恢复至最新的快照状态，然后根据WAL恢复数据，以保证存储可靠性。

11 MongoDB如何使用wiredTiger？

Mongodb 3.0支持用户自定义存储引擎，用户可配置使用mmapv1或者wiredTiger存储引擎，本文主要介绍Mongodb是如何使用wiredTiger数据库作为底层的数据存储层。目前还没有读过wiredTiger的源码，本文的内容都是基于wiredTiger官方文档，以及Mongodb对wiredTiger封装代码，有问题请指出。

wiredTiger引擎存储布局

wiredTiger（简称WT）支持行存储、列存储以及LSM等3种存储形式，Mongodb使用时，只是将其作为普通的KV存储引擎来使用，mongodb的每个集合对应一个WT的table，table里包含多个Key-value pairs，以B树形式存储。

以下是一个典型的使用WT存储引擎的数据目录布局（配置了directoryPerDB选项，启用了journal）

$tree
.
├── admin
│   ├── collection-11--5764503550749656746.wt
│   ├── collection-14--6907424972913303461.wt
│   ├── collection-16--6907424972913303461.wt
│   ├── collection-20--6907424972913303461.wt
│   ├── collection-8--6907424972913303461.wt
│   ├── collection-9--5764503550749656746.wt
│   ├── index-10--5764503550749656746.wt
│   ├── index-12--5764503550749656746.wt
│   ├── index-13--5764503550749656746.wt
│   ├── index-15--6907424972913303461.wt
│   ├── index-17--6907424972913303461.wt
│   └── index-9--6907424972913303461.wt
├── journal
│   ├── WiredTigerLog.0000000003
│   └── WiredTigerPreplog.0000000001
├── local
│   ├── collection-0--5764503550749656746.wt
│   ├── collection-2--5764503550749656746.wt
│   ├── collection-4--5764503550749656746.wt
│   ├── collection-6--5764503550749656746.wt
│   ├── collection-7--5764503550749656746.wt
│   ├── index-1--5764503550749656746.wt
│   ├── index-3--5764503550749656746.wt
│   ├── index-5--5764503550749656746.wt
│   └── index-8--5764503550749656746.wt
├── _mdb_catalog.wt
├── mongod.lock
├── products
│   ├── collection-6--6907424972913303461.wt
│   └── index-7--6907424972913303461.wt
├── sizeStorer.wt
├── storage.bson
├── WiredTiger
├── WiredTiger.basecfg
├── WiredTiger.lock
├── WiredTiger.turtle
└── WiredTiger.wt

WiredTiger*等文件存储WT的一些配置信息。

local、journal、admin、products等每个目录代表一个DB，DB里包含集合数据及集合的索引数据，每个集合的数据对应一个WT的table（一个.wt后缀的文件），集合的每项索引也对应一个WT的table。

journal目录下存储WT的write ahead log，当服务crash时，可通过log来恢复数据。

_mdb_catalog.wt里存储了所有集合的元数据，包括集合对应的WT table名字，集合的创建选项，集合的索引信息等，WT存储引擎初始化时，会从_mdb_catalog.wt里读取所有的集合信息，并加载元信息到内存。

集合名与WT table名的对应关系可以通过db.collection.stats()获取

mongo-9552:PRIMARY> db.system.users.stats().wiredTiger.uri
statistics:table:admin/collection-10--1436312956560417970

也可以直接dump出_mdb_catalog.wt里的内容查看，dump出的内容为BSON格式，阅读起来不是很方便。

wt -C "extensions=[/usr/local/lib/libwiredtiger_snappy.so]"  -h . dump table:_mdb_catalog

sizeStorer.wt里存储所有集合的容量信息，如文档数、文档总大小等，当插入、删除、更新文档时，这些信息会先cache到内存，没操作1000次会刷盘一次；mongod进程crash可能导致sizeStorer.wt里的数据与实际信息不匹配，可通过validate()命令来重新扫描集合以订正统计信息。

wiredTiger API

WT官方提供了C、java、python API，mongodb使用C API来访问WT数据库，主要包括3个核心的数据结构。

WT_CONNECTION代表一个到WT数据库的连接，通常每个进程只用建立一个连接，WT_CONNECTION的所有方法都是线程安全的。
WT_SESSION代表一个数据库操作的上下文，每个线程需创建独立的session。
WT_CURSOR用于操作某个数据集（如某个table、file），可使用cursor来进行数据库插入、查询操作。

如下是使用wiredTiger C API的示例，展示了如何向WT数据库里插入数据，更多示例参考这里。

#include <wiredtiger.h>

char *home = "WT_HOME";

int main(void)
{
    WT_CONNECTION *conn;
    WT_CURSOR *cursor;
    WT_SESSION *session;
    const char *key, *value;
    int ret;

    /* Open a connection to the database */
    ret = wiredtiger_open(home, NULL, "create", &conn);

    /* Open a session in conn */
    ret = conn->open_session(conn, NULL, NULL, &session);

    /* Create table if not exist */
    ret = session->create(session,
        "table:access", "key_format=S,value_format=S");

    /* Open a cursor and insert key-value pair */
   ret = session->open_cursor(session,
        "table:access", NULL, NULL, &cursor);
    cursor->set_key(cursor, "key1");
    cursor->set_value(cursor, "value1");
    ret = cursor->insert(cursor);

    /* Close conn */
    ret = conn->close(conn, NULL);

   return ret;
}

上述示例包含如下步骤

wiredtiger_open()建立连接
conn->open_session建立session
session->create()创建access表，并指定key、value格式
session->open_cursor创建cursor，并插入key-value
访问结束后conn->close()关闭连接

wiredTiger in Mongodb

Mongodb使用wiredTiger作为存储引擎时，直接使用其C API来存储、查询数据。

wiredtiger_open

Mongodb在WiredTigerKVEngine构造的时候wiredtiger_open建立连接，在其析构时关闭连接，其指定的配置参数为：

配置项	含义说明
create	如果数据库不存在则先创建
cache_size=xx	cache大小，使用Mongod cacheSizeGB配置项的值
session_max=20000	最大session数量
eviction=(threads_max=4)	淘汰线程最大数量，用于将page从cache逐出
statistics=(fast)	统计数据采用fast模式
statistics_log=(wait=xx)	统计数据采集周期，使用mongod statisticsLogDelaySecs配置项的值
file_manager=(close_idle_time=100000)	空闲文件描述符回收时间
checkpoint=(wait=xx,log_size:2G)	开启周期性checkpoint，采用Mongod syncPeriodSecs配置项的值
log=(enabled=true,archive=true...	启用write ahead log，达到2G时触发checkpoint

重点介绍下checkpoint和log2个配置项，其决定了数据持久化的安全级别；wiredTiger支持2种数据持久化级别，分别是Checkpoint durability 和 Commit-level durability。

Checkpoint durability

wiredTiger支持对当前的数据集进行checkpoint，checkpoint代表当前数据集的一个快照（或镜像），wiredTiger可配置周期性的进行checkpoint（或当log size达到一定阈值是做checkpoint）。

比如WT配置了周期性checkpoint（没开启log），每5分钟做一次checkpoint，在T1时刻做了一次Checkpoint得到数据集C1，则在接下来的5分钟内，如果服务crash，则WT只能将数据恢复到T1时刻。

Commit-level durability

wiredTiger通过write ahead log来支持commit-level durability。

开启write ahead log后，对WT数据库的更新都会先写log，log的刷盘策略（通过trasaction_sync配置项或者 begion_transaction参数指定）决定了持久化的级别。

mongodb的使用的持久化级别配置为

checkpoint=(wait=60,log_size=2G)
log=(enabled=true,archive=true,path=journal,compressor=snappy)
begin_transcation("sync=true")

具体策略为

每60s做一次checkpoint
开启write ahead log，当log size达到2GB时做checkpoint；并自动删除不需要的log文件。
每次commit_transaction时，调用fsync持久化已经commit的log。

基于上述配置，mongodb可以保证服务crash时，所有已经commit的操作都能通过log恢复。

open_session

mongodb使用session pool来管理WT的session，isolation=snapshot指定隔离级别为snapshot。

 conn->open_session(conn, NULL, "isolation=snapshot", &_session);

create table

创建数据集合的参数如下

配置项	含义说明
create	如果集合不存在则先创建
memory_page_max=10m	page内存最大值
split_pct=90	page split百分比
checksum=on	开启校验
key_format=q,value_format=u	key为int64_t类型（RecordId），value为WT_ITEM

数据集合的key为int64_t类型的RecordId，RerordId在集合内部唯一，value为二进制的BSON格式。

创建索引集合的参数如下

配置项	含义说明
create	如果集合不存在则先创建
type=file,internal_page_max=16k,leaf_page_max=16k	配置树节点大小
checksum=on	开启校验
key_format=u,value_format=u	key-value均为WT_ITEM格式

索引集合的key、value均为二进制数据。

table创建好之后，就可以往table

比如，往某个集合插入一组元素

db.coll.insert({_id: "apple", count: 100});
db.coll.insert({_id: "peach", count: 200});
db.coll.insert({_id: "grape", count: 300});

对应一个coll的数据集合，其对应的WT数据类似于

key	value
1	{_id: "apple", count: 100}
2	{_id: "peach", count: 200}
3	{_id; "grape", count: 300}

以及基于id的索引集合，其对应的WT数据类似于

key	value
"apple"	1
"peach"	2
"grape"	3

接下来如果在count上建索引，索引会存储在新的WT table里，数据类似于

db.coll.ensureIndex({count: -1})

key	value
300	3
200	2
100	1

总结

Mongodb使用wiredTiger存储引擎时，其将wiredTiger作为一个KV数据库来使用，mongodb的集合和索引都对应一个wiredTiger的table。并依赖于wiredTiger提供的checkpoint + write ahead log机制提供高数据可靠性。

12 MongoDB的请求流程

Mongodb多存储引擎支持机制介绍了Mongodb存储层创建数据库、创建集合、插入文档等数据库操作接口，本文将介绍mongodb处理客户端请求的模型。

Mongod在启动时会调用createServer创建一个PortMessageServer对象，其继承MessageServer和Listener两个类，并依赖MyMessageHandler来处理请求。

class PortMessageServer: public MessageServer, public Listener {
public:
    void accepted(boost::shared_ptr<Socket> psocket, long long connectionId );
    void setupSockets();
    void run();
private:
   MessageHandler* _handler;
};

PortMessageServer

调用setupSockets为mongod配置的每个地址创建一个socket，并调用bind绑定地址。
调用initAndListen监听所有的地址，调用select等待监听fd上发生连接事件，调用accept系统调用接受新的连接请求，并为每个新连接创建一个线程，该线程执行handleIncomingMsg方法，不断处理该连接上的客户端请求。

handleIncomingMsg

连接建立时，调用MyMessageHander::connected方法，初始化一个新的Client对象，Client对象包含DB操作的上下文。
不断调用recv从连接上读取请求，当读取到一个完整请求时，其将请求反序列化为一个Message对象，并调用MyMessageHandler::process方法处理请求，处理完后给客户端发送应答。
连接断开时，调用MyMessageHander::disconnected方法停止该连接对应的线程，释放Client对象。

MyMessageHandler::process

调用assembleResponse方法，从Message对象里获取请求类型（参考Mongdb协议），根据请求类型进行响应的处理。

如果为请求dbQuery，调用receivedQuery处理
如果为请求dbInsert，调用receivedInsert处理
如果为请求dbUpdate，调用receivedUpdate处理
如果为请求dbDelete，调用receivedDelete处理
......

上述各种请求最终会调用Database类的接口来处理；比如receivedInsert，会先根据Database回去对应的Collection对象，最后调用insertDocument往集合中插入文档。请求处理完后，给客户端发送应答消息。

问题分析

select的使用

mongod调用select时，fdset里只会加入监听fd，而监听的地址通常很少，故不存在效率问题。

thread per client模型

mongod为每个连接创建一个线程，创建时做了一定优化，将栈空间设置为1M，减少了线程的内存开销。当线程太多时，线程切换的开销也会变大，但因为mongdb后端是持久化的存储，切换开销相比IO的开销还是要小得多。