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或LBS
2、中小公司用它没有问题 量大肯定不行
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(常用)
遇到的坑及解决方案
大量删除数据及解决方案
背景
解决方案
大量数据碎片(空洞)及解决方案
背景
大量删除数据 产生内存碎片
数据删除完之后 会留下很多空洞 不会马上回收
早期用的MMAP
空洞数据也会加载到内存中去
比如64G内存 大量空洞数据 有效数据仅占内存10G
解决方案
碎片整理方案
-
线上数据压缩
-
收缩数据库
具体数据收缩步骤
压缩效果对比
搜索前85G 压缩后34G 节省了51G内存 大大提升了性能
上述步骤大致流程
1、把从库 rm -rf *
2、重启从库
3、从主库重新同步一份 从库上面完全没有碎片
4、主库上执行stepDown 主库变成从库 从库变成主库
5、删掉从库 重启 再同步 同步完了 从库就变成新的了
(删除之后同步数据 碎片数据不会同步)
注:
a、一主二从 主库降权 数据最新的从库会提升为主
b、主从同步之间丢失的数据 业务系统通过补偿机制保存MongoDB