面向文档的NoSQL数据库MongoDB

NoSQL优势

全称:Not Only SQL 不仅仅是数据库

海量的扩展能力
读写高性能
与关系型数据库（RDBMS）相辅相成

NoSQL产品

键值存储型(Key-Value) Redis/Codis
列存储型 HBase

Hbase数据分析用的比较多

图形(Graph)数据库

Neo4j知识图片用的较多

文档型 MongoDB

MongoDB概念

举例：描述人

关系型数据库

MongoDB

MongoDB特性

可扩展(scalable)
高性能(high-performance)
开源(open source) NoSQL database
C++语言编写
Document-Oriented Storage
Full Index Support
Replication & High Availability
Auto-Sharding
Rich Querying
Updates
Map/Reduce
GridFS 存储二进制文件

MongoDB稳定性

如何解决数据丢失

恢复日志(journal)

写关注

写入大多数节点

MongoDB高可用

核心业务SLASLA 99.99%以上怎么做到的？

MongoDB 副本集(replica set)

数据多分冗余
跨交换机部署
更快的选举方式(参考raft协议)

架构

主从复制+高可用方案

分片

架构

1、对业务方来说没有分库分表的概念不管数据量多大 对业务方来说都是单库单表对于关系型数据库来说比如Myql有分库分表的概念比如1T数据 MongoDB分2个片 每一个片存储500G数据

2、Router可以有很多台3、分片信息存储在config server中4、一个分片就是一个副本集(replica set)5、Router先访问config server获取分片信息，Router再访问分片集（replica set）

表的分片(MongoDB Collection)

分片规则

Sharding Range-based

基于范围分片用的较多

Mysql B+ Tree本质也是Range-based

Sharding Hash-based

取模分片

Java HashMap是Hash-based查询速度比较快不支持范围查询对于数据库来说 不支持范围查询肯定不合适

分片集群架构

1、3个配置节点、3个路由节点（mongos）都是stateless（无状态的即数据都一样）2、每个分片就是一个replica set(一主两从) 一个分片3台机器3、cnofig和mongos也可以混合部署在一个sharding上

应用场景

1、位置即GPS或LBS2、中小公司用它没有问题 量大肯定不行3、非交易相关的都可以用a、事务支持的比较弱b、mongodb 4.0已经支持事务 并且支持跨行事务

可扩展存储

1、最早的操作引擎是MMAP 支持表级锁 也是操作系统自带的一种机制缺点就是内存利用率不高

2、WireTigger支持行级锁

文档设计

_id 全局唯一标识 表粒度不填写默认生成一个12字节的objectid占用空间比较大 一般用业务主键比如uid等代替掉 否则和自增主键一样 无意义

_id默认生成规则(不推荐)

1、collection是表级

2、a、1位16进制占4个字节即4个bytes 代表一个字符串   b、一个字节占2位即2个字符串   c、_id 一共有12个字节即24个字符串

3、可读性很差 占空间比较大

_id推荐生成规则

1、uint64_t 其实就是long类型 占8个字节2、objectid是默认类型也是是整型、long类型、浮点型

Free Shcama

意味着重复的Schema、All Schema

如何应对

字段名选取

字段名简化了如何保证可读性

MongoDB数据量限制

MongoDB限制每一个doc(文档)最大16MB

数据较少场景

考试成绩、个人信息

数据较多场景

三国杀和武将牌

常规引用关联

内嵌文档

日志场景引用更有效 Host&Log

机器和日志不能用内嵌只能用引用

锁机制

悲观锁

悲观锁并发控制

使用写锁来保护资源不被同时访问
读写操作为互斥操作

悲观锁范围

1、sql解析2、创建一个写命令3、从磁盘中读文档 把数据读取到内存4、针对内存数据执行写命令5、对内存结构做修改（仅在这一步加锁）6、返回结果

乐观锁

MongoDB 3.0 WT MVCC机制

乐观派 lock-free并发控制

乐观锁意义

压缩算法

Snappy

Zlib(常用)

遇到的坑及解决方案

大量删除数据及解决方案

背景

解决方案

大量数据碎片（空洞）及解决方案