mongodb基础知识

1 mongodb与mysql的比较

2 mongodb的优缺点

优势：
（1）高性能： 持久化化是先存储到内存中，在异步刷新到磁盘中，所以读写速度很快；
（2）高可用： 使用了复制集（副本集）能实时同步一份相同的数据，能够自动进行故障转移；
（3）可扩展： Sharded cluster （分片集群）
（4）灵活： 采用BSON方式存储，类似于JSON格式，文档型的存储方式，和对象转换方便；

缺点：
（1）没有事务机制，不能回滚；
（2）锁只有集合锁，没有行级锁；

mongodb和mysql相似点：
所有数据都是持久化到磁盘中，只是热点数据缓存到内存中，都有备份日志可以恢复数据。

3 适用场景

日志记录
队列消息:bjson格式存储，消息字段新增，不用改表结构
监控数据‘

4 存储结构

BJSON（类似于json）格式
BJSON有json没有的类型 Date BinData

支持的数据类型

{
"name":"zhangsan",  //字符串
"isDangYuan":true, //boolean
"age":23, //数字
"address":{  //内嵌文档
"province":"山东省",
"city":"泰山市"
},
location:["1","2"]  //数组

}

5 关键特性

高性能和丰富的查询语言
高可用
可扩展
支持多种存储引擎

(1) 高性能和丰富的查询语言

高性能：

a 高性能的数据持久化；（保存）
和mysql直接存储到磁盘的区别，mongodb先存储到内存中， 在异步以100ms刷新到磁盘中存储，
对于热点数据直接从内存中读取速度是很快的；
b 索引（查询）

丰富的查询语言：

a crud查询
b 数据聚合
c 文本搜索和地理空间查询

(2)高可用性和数据持久化

高可用性：

mongodb的复制集（相当于副本集）提供：
自动故障转移；
数据冗余

数据持久化：

副本集是一个保证和master保持相同数据的集合， 保证了数据持久化的可用性；

(3)可扩展

使用场景：

当MongoDB复制集遇到下面的业务场景时，你就需要考虑使用Sharded cluster
存储容量需求超出单机磁盘容量
活跃的数据集超出单机内存容量，导致很多请求都要从磁盘读取数据，影响性能
写IOPS超出单个MongoDB节点的写服务能力

分片集群架构：

实现分片集群时，MongoDB 引入 Config Server 来存储集群的元数据，引入 mongos 作为应用访问的入口，mongos 从 Config Server 读取路由信息，并将请求路由到后端对应的 Shard 上

角色说明

A.数据分片（Shards）
用来保存数据，保证数据的高可用性和一致性。可以是一个单独的mongod实例，也可以是一个副本集。
在生产环境下Shard一般是一个Replica Set，以防止该数据片的单点故障。所有Shard中有一个PrimaryShard，里面包含未进行划分的数据集合：
B.配置服务器（Config servers）
保存集群的元数据（metadata），包含各个Shard的路由规则。
C.查询路由（Query Routers）
Mongos是Sharded cluster的访问入口，其本身并不持久化数据(Sharded cluster所有的元数据都会存储到Config Server,而用户的数据则会分散存储到各个shard)
Mongos启动后，会从config server加载元数据，开始提供服务，将用户的请求正确路由到对应的Shard
Sharding集群可以有一个mongos，也可以有多mongos以减轻客户端请求的压力

（4）存储引擎

MMAP 3.2版本之前

库级锁： 并发处理能力差
删除不及时： 磁盘空间和内存空间难以及时清理掉
（MMAP存储时，集合和索引是混合存储在一份磁盘文件中，及时删除掉了集合或者索引，占用的磁盘空间也很难及时清除掉）

WiredTiger 3.2版本之后（含）

文档级别锁：允许并发的更新同一个集合中不同的文档，提高了吞吐能力
支持压缩： 支持集合和索引Block方式压缩，减少了磁盘空间占用
及时删除： 集合和索引分别存储在不同文件中，集合或者索引删除后，对应的存储文件会随即删除；

In-Memory存储引擎

将数据只存储在内存中，只将少量的元数据和诊断日志（Diagnostic）存储到硬盘文件中，由于不需要Disk的IO操作

6 GridFS存储原理

（1）GridFS简介
用来存储大文件

（2）存储过程
通过GridFS存储一个文件时，都会存储到2个集合中， 一个fs.files用来存储文件的元数据，另一个是fs.chunks用来存储文件内容的二进制数据.

每个文件在fs.files中只有一个文档，记录着该文件的元信息，其中“_id"具有文件唯一性； 每个文件在fs.chunks有一到多个文档用来存储文件内容，其中"files_id"与fs.files中”_id"对应，n代表文件内容的顺序； 查找文件时，先从fs.files中找到该文件元信息的文档，获取"_id", 在用"_id"去匹配fs.chunks中的"files_id"找到文件内容，根据n自然顺序排序就能获取该文件的所有内容。

fs.files文档的格式：

fs.chunks文档的格式：

7 架构

复制集： （高可用）

三个对等节点构成复制集群，节点分成master和secondray角色，其中master负责读写、secondrary只负责读，master中写入的数据会同步到2个secondrary数据库中，当master出现宕机，会重新选举出一个新的master， 实现了自动故障转移

分片集群：（可扩展）

当单机服务器磁盘空间达到最大，需要考虑引入分片存储数据， 同一个集合数据根据分片策略存储到不同的
节点数据库中， 当查询数据的时候，根据sharing 条件，路由到特定节点数据库中

8 存储过程

wiredTiger引擎存储过程

模块介绍

journal: 类似于orcal的redo日志，当数据库突发宕机时，可以从journal中恢复之前的写操作;

data file: mongodb在存储数据的磁盘文件；

shared view: 每60s或者内存写操作数据达到2G, 会刷新此内存中数据到data file中存储；

private view: 每个写操作发生时，会先存储到private view内存中存储，提高mongodb吞吐量

存储过程
1 当发生一个写操作，先存储到privateview内存中，每100ms会刷新private view内存中数据到journal中，
然后同步更新数据到shared view内存中；

2 每隔60s或者shared view内存中数据达到2G, mongodb会刷新shared view中内存到data file文件中，
然后同步清除掉journal中被刷新到data file中的写操作，并同步更新数据到private view，防止private
view内存过脏

3 当数据库出现突发宕机，可以从journal中恢复日志数据，然后同步到shared view，最后刷新到data file
文件中