MySQL/Mongo
Mongo和MySQL有什么区别
| 数据库 | MongoDB | MySQL |
|---|---|---|
| 数据库模型 | 非关系型，k-v存储 | 关系型 |
| 存储方式 | 以类JSON的文档的格式存储，格式灵活，适合稀疏存储 | 基于表存储，格式固定 |
| 存储引擎 | Wired Tiger，cache用的是B tree，每个Btree节点为一个page，以page为单位按需从磁盘加载或写入磁盘。 | 不同引擎有不同的存储方式（InnoDB是.ibd+.frm，MyISAM是.myi+.myd+.frm） |
| 查询语句 | MongoDB Shell（类似JavaScript的函数），有功能强大的聚合框架aggregate（pipeline） | SQL语句 |
| 数据处理方式 | 基于内存，将热数据存放在物理内存中，从而达到高速读写（内存占用高） | InnoDB使用聚簇索引，将索引和数据存放在一起。MyISAM中索引和数据分开存储。 |
| 广泛度 | 较年轻，迭代快，NoSQL数据库中，比较完善且开源，使用人数在不断增长，排名一直在上升 | 成熟度高，开源数据库，市场份额不断增长 |
| 事务性 | 4.0以前依赖Wired Tiger实现加锁，4.0开始支持副本集的事务操作，4.2开始支持分布式事务操作 | 支持事务操作 |
| 隔离等级 | snapshot隔离等级（大概介于RR和serializable之间），每个事务attach到一个snapshot上，既可以避免幻读，又可以防止串行化带来的效率降低 | 支持RC和RR（默认RR，通过MVCC实现），使用Next-key Lock后实现避免幻读 |
| 占用空间 | 占用空间大 | 占用空间小（MyISAM还可以再压缩） |
| join操作 | $lookup、嵌套文档、多维数据类型 | 支持join |
| 索引支持 | 唯一索引（B+索引）、复合索引、TTL索引（生命周期，支持缓存）、地理空间索引、文本索引、2D索引 | 唯一索引（B+索引）、复合索引、Hash索引、地理空间索引（MyISAM）、文本索引 |
| 索引数据类型 | B tree | B+ tree |
| 分布式支持 | 支持 | 支持 |
| 海量数据支持 | 海量数据下读取性能好，拓展性强，可用性高 | 支持海量数据，但读取性能差 |
| 适合的场景 | 文档型、非结构化数据，海量存储，模糊处理 | 结构化数据，事务性强，事务一致性要求高 |
Mongo和MySQL应用场景
MongoDB的应用场景
1）表结构不明确且数据不断变大
MongoDB是非结构化文档数据库，扩展字段很容易且不会影响原有数据。内容管理或者博客平台等，例如圈子系统，存储用户评论之类的。
2）更高的写入负载
MongoDB侧重高数据写入的性能，而非事务安全，适合业务系统中有大量“低价值”数据的场景。本身存的就是json格式数据。例如做日志系统。
3）数据量很大或者将来会变得很大
Mysql单表数据量达到5-10G时会出现明细的性能降级，需要做数据的水平和垂直拆分、库的拆分完成扩展，MongoDB内建了sharding、很多数据分片的特性，容易水平扩展，比较好的适应大数据量增长的需求。
4）高可用性
自带高可用，自动主从切换（副本集）
不适用的场景 （
4.2开始已经解决了！！！！！
）
1）MongoDB不支持事务操作，需要用到事务的应用建议不用MongoDB。 （
4.0开始支持事务，4.2开始支持分布式事务
）
2）MongoDB目前不支持join操作，需要复杂查询的应用也不建议使用MongoDB。（
$lookup已经支持join操作
）
关系型数据库适合存储结构化数据，如用户的帐号、地址：
1）这些数据通常需要做结构化查询，比如join，这时候，关系型数据库就要胜出一筹
2）这些数据的规模、增长的速度通常是可以预期的
3）事务性、一致性
NoSQL适合存储非结构化数据，如文章、评论：
1）这些数据通常用于模糊处理，如全文搜索、机器学习
2）这些数据是海量的，而且增长的速度是难以预期的，
3）根据数据的特点，NoSQL数据库通常具有无限（至少接近）伸缩性
4）按key获取数据效率很高，但是对join或其他结构化查询的支持就比较差