mysql vs mongodb

工作中mysql和mongodb总是交替的使用，基本上都是别人使用mongodb就跟着用mongodb，别人使用mysql就跟着用mysql，作为研发人员，虽然不至于像dba大神们一样对这两个数据库知根知底，但是什么时候用mongodb，什么时候用mysql，这两个数据库的特效是什么，还是应该有一个基本认识的，现在就与我来一探究竟吧～

结构化与非结构化

基础概念

mysql是结构化数据库，存储的是结构化的数据
mongodb是非结构化数据库，存储的是非结构化的数据

	结构化	非结构化
数据	二维表结构来逻辑表达和实现的数据，严格地遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理	非结构化数据,包括所有格式的办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等
场景	典型的结构化数据包括：信用卡号码、日期、财务金额、电话号码、地址、产品名称等	聊天、即时消息、电话录音、协作软件等。

数据库体现

设计

1.由于sql数据库存储的都是结构化数据，将来修改表会麻烦很多，所以一开始要设计好
2.nosql数据库。它不需要结构化的数据设计。这样它的容错性就很强，也不存在太严格的设计，所以以后的扩展和修改都比较容易。

关系

1.sql数据库的表之间存在一对多，多对多，一对一等关系
2.nosql不存在关系这个概念，如果你想实现关系，比如说1对1，一对多,多对多，你需要用程序来实现，而不是用数据库本身来实现

存储

1.sql数据库的数据定义严格，在一个表中只能存放一种表数据，也就是说，你的每一行的数据都要遵循这个表的的定义。这个表里的每行的数据都遵循这个表内定义好的数据类型，不能够存放一些所谓非定义的数据，否则出错。
2.nosql数据库是每一行的数据可以不遵循统一的定义

索引结构

索引的用处，很简单就是加快数据查询的速度，在mysql与mongodb中都有索引的存在，且他们的底层实现都是B-Tree，为什么使用B+树，原因我这篇博文有总结 索引B+树的原因 此处简略来学习一下B+树特点。
b+树每次查的是数据所在的数据页，然后根据稀疏索引和指针获取对应的数据。
b+树相对于b树的特定的特点：
1.有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。
2.所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。
3.所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。
b+树针对于b树的优势：
1.io次数少
2.查询性能稳定（平衡树）
3.范围查询方便
索引种类
1.聚集索引：包含一行记录的所有信息
2.辅助索引：索引列和一个查找对应行记录的书签（一般为主键）

存储引擎

存储引擎要做的事情无外乎是将磁盘上的数据读到内存并返回给应用，或者将应用修改的数据由内存写到磁盘上

mongodb(WiredTiger)

缓存

1.WiredTiget缓存：存储未压缩的数据，并提供类似内存的性能（因此在一定内存数据量下mongodb查询会更快）
2.文件系统缓存：操作系统的文件系统缓存存储压缩数据。当在WiredTiger缓存中找不到数据时，WiredTiger将在文件系统缓存中查找数据。

吞吐量：

WiredTiger使用“写入时复制” - 当文档更新时，WiredTiger将制作文档的新副本并确定最新版本以返回给读者。此方法允许多个客户端同时修改集合中的不同文档，从而实现更高的并发性和吞吐量。当应用程序使用具有多个内核的主机（越多越好）并且多个线程正在写入不同的文档时，实现最佳写入性能

文档级并发

WiredTiger使用文档级并发控制进行写操作。因此，多个客户端可以同时修改集合的不同文档。
对于大多数读写操作，WiredTiger使用乐观并发控制。WiredTiger仅在全局，数据库和集合级别使用意图锁。当存储引擎检测到两个操作之间的冲突时，会发生写入冲突，导致MongoDB透明地重试该操作。
一些全局操作（通常是涉及多个数据库的短期操作）仍然需要全局“实例范围”锁定。其他一些操作（例如删除集合）仍需要独占数据库锁。

journal日志

WiredTiger使用预写日志的机制，在数据更新时，先将数据更新写入到日志文件，然后在创建Checkpoint操作开始时，将日志文件中记录的操作，刷新到数据文件，就是说，通过预写日志和Checkpoint，将数据更新持久化到数据文件中，实现数据的一致性。WiredTiger 日志文件会持久化记录从上一次Checkpoint操作之后发生的所有数据更新，在MongoDB系统崩溃时，通过日志文件能够还原从上次Checkpoint操作之后发生的数据更新。

mysql（InnoDB）

存储

1.数据存储方式：
所有的数据都被逻辑的存储在表空间中，表空间–段--区–页--行
数据页结构：
每一页按照行存储数据，链表结构，物理上每次自左向右找空余内存，由nextrecord控制
2.表存储方式：
.frm文件：表结构
.ibd文件：索引及表数据

锁

种类
使用的都是悲观锁
1.行锁
共享锁（读）：允许事务对一条行数据进行读取；
互斥锁（写）：允许事务对一条行数据进行删除或更新；
2.表锁–》主要目的：是否有人请求锁定表中某一行数据，不阻塞全表扫描外任何请求
意向共享锁：事务想要在获得表中某些记录的共享锁，需要在表上先加意向共享锁
意向互斥锁：事务想要在获得表中某些记录的互斥锁，需要在表上先加意向互斥锁
—》如果没有意向锁，当已经有人使用行锁对表中的某一行进行修改时，如果另外一个请求要对全表进行修改，那么就需要对所有的行是否被锁定进行扫描，在这种情况下，效率是非常低的；不过，在引入意向锁之后，当有人使用行锁对表中的某一行进行修改之前，会先为表添加意向互斥锁（IX），再为行记录添加互斥锁（X），在这时如果有人尝试对全表进行修改就不需要判断表中的每一行数据是否被加锁了，只需要通过等待意向互斥锁被释放就可以了。
3.锁的算法
record lock(记录锁)：加了索引，索引在where后可通过索引建立的b+树找到行记录并添加索引（未匹配索引就加全表锁）
gap lock(间隙锁):对索引记录中一段连续区域加的锁
next-key lock：锁定当前值和前面的范围，SELECT * FROM users WHERE age = 30 FOR UPDATE;，InnoDB 不仅会在范围 (21, 30] 上加 Next-Key 锁，还会在这条记录后面的范围 (30, 40] 加间隙锁，所以插入 (21, 40] 范围内的记录都会被锁定。

隔离级别

读不提交：造成脏读（读取了可能会被回滚的数据）
读提交：造成两次读到不一样的数据
可重复度（一般情况）：造成幻读（在一个事务中，同一个范围内的记录被读取时，其他事务向这个范围添加了新的记录。）
串行化：并发效率低

参考文档：
结构化数据库与分结构化数据库大比拼
b+树
mysql数据存储结构
Innodb引擎简介
WiredTiger引擎介绍