以MongoDB为例与关系型数据库比较

声明：本文属于探讨性话题，肯定存在很多疏漏和错误，不要盲目相信，大家发现什么错误或者有什么想法请求务必告知

在比较之前，先介绍一个重要的概念：数据库事务

作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。

一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理

由此再简要说明一下ACID

• Atomic：原子性，无论包含多少操作，事务是一个不可分割的整体
• Consistency：一致性，每个事务必须保证数据之间存在的各种关系和约束
• Isolation：隔离性，事务之间的操作是相互独立的，互相之间没有交叉。（影响数据库性能的关键）
• Duration：持久性，事务完成后对于系统的影响是永恒的，不会随时间而改变

有了数据库事务的概念后，我们再来看MongoDB（同时代表大部分NoSql，下文不再重述）和MySql（代表大部分关系型数据库，下文不再重述）的区别，分为三部分。

1 存储结构

MongoDB主要以键值对的形式存储，随时可以以任意形式插入，且document可以嵌套，所以在数据的存取和查询上相当灵活、高效。但同时由于形式不严谨，对于有一定逻辑的操作，不容易实现。
相比较之下，mysql虽然不那么灵活，但结构严谨，能实现较为复杂的关系和业务。

2 数据库事务

数据库事务原本就是关系型数据库中发展出来的概念，所以MySQL肯定全部满足。而MongoDB是不支持事务的（这也是其灵活的关键），但对于事务中的ACID值得讨论。

• 原子性：mongodb对于document的基本操作是满足原子性的，对于较为复杂的集合操作（同时又很多操作）也提供了很多函数确保原子性。
• 一致性：MongoDB是很难满足数据的一致性的（虽然有Read Concern和Write Concern），尤其对于分布式数据库，根据CAP理论，MongoDB在损失了一致性的同时，有一定的分区容错性。这种情况对于并发性不是很高，逻辑不是很严谨的系统是合适的，如果有某些业务需要保证较高的一致性，MongoDB可以借用锁实现。
• 隔离性：由于隔离性的实现代价较高，对于性能的影响较大，并且MongoDB保证了原子性，所以对于大部分情况，是不保证隔离性的，即事务之间有交叉，但原子操作之间是没有的。
• 持久性：满足，基本上对于所有的数据库都是满足持久性的吧，除了内存数据库。

还有很重要的一点是数据的完整性。包括实体完整性，引用完整性，用户自定义完整性。MongoDB是可以实现实体完整性的，引用完整性可以用DBRef实现。用户自定义完整性，既然是自定义肯定就有很多实现和方法，MongoDB自带的用户自定义完整性肯定是没有MySQL丰富和方便的。

3 性能及应用场景

由以上可以得到各自的显著特点：
MongoDB：存取灵活，弱结构，键值对（JSON）形式适合很多应用场景。
MySQL：结构严谨，逻辑严密，有完整的数学理论支持。

应用场景：
MongoDB：
1. 弱结构很适合第三方信息的抓取，不需要为各种来源设计表结构，直接存储，极大的减少了数据库设计维护的工作量。
2. 存取灵活适合于一些随时存取，结构化要求又不高的业务场景，比如日志文件、数据分析处理等
3. 键值对是接近很多有匹配关系业务的真实应用场景，如物流（订单、点到点）、游戏（玩家对应的装备）、社交（用户之间的关系和动态）等，都能直接匹配，高效存取。

MySQL：
1. 需要严密的数据结构的人事管理、大型企业网站。
2. 对于事务一致性和隔离性有高要求的金融、电商、军事等高并发的网站。

综合来看MongoDB没有事务机制，不能很好地满足许多复杂业务，更多的是当做一种工具，去实现某些局部、零散的需求，提高效率，而MySQL有完善的理论，可以应对绝大部分业务场景，更适合去服务各种实际应用和业务。

继续完善补充中