简介
关系型数据库管理系统（RDBMS）用来操作建立在关系模型基础上的数据库，主要代表有：Microsoft SQL Server，Oracle，MySQL（开源）。
非关系型数据库（NoSQL），主要代表有：MongoDB，Redis。
ACID vs BASE
| ACID | BASE |
|---|---|
| 原子性(Atomicity) | 基本可用(Basically Available) |
| 一致性(Consistency) | 软状态/柔性事务(Soft state) |
| 隔离性(Isolation) | 最终一致性 (Eventual consistency) |
| 持久性 (Durable) |
ACID
ACID是关系型数据库强一致性（Strong consistency）的四个要求。
(1) 原子性（Atomicity）：事务里的所有操作要么全都执行完成，要么全都不执行。只要有一个操作失败，整个事务就失败，事务会回滚至它们最初的状态。
(2) 一致性（Consistency）：数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
(3) 隔离性（Isolation）：事务的执行不被其他事务干扰。如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。
(4) 持久性（Durable）：一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现系统故障也不会丢失。
（注：事务（Transaction）是用户定义的一个操作序列。）
BASE
BASE是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性，但是可以根据应用的特点采用适当的方式来达到最终一致性（Eventual consistency）。
(1) 基本可用（Basically Available）：分布式系统在出现故障的时候，允许损失部分可用性，即保证核心功能或者当前最重要功能可用。
(2) 软状态/柔性事务（Soft-state）：状态可以有一段时间的不同步。
(3) 最终一致性（Eventual consistency）：当所有服务逻辑执行完成后，系统最后将回到一个一致的状态。
ACID和BASE并没有一个严格的界限，它们取决于组织和系统决定在哪里和如何架构这个系统的场景。它们可能允许在某些关键领域采取严格的ACID事务，其他领域标准稍微放松一些。
区别
1. 事务控制模型不同
RDBMS采用ACID模型，而很多NoSQL系统基本采用BASE模型。虽然有些NoSQL系统支持ACID，但只适用于单个条目。NoSQL不采用ACID的主要原因是其可扩展性方面的限制，如果文档横跨几个服务器，事务控制将会很难实施。
总的来说，RDBMS关注一致性，而NoSQL系统则关注可用性。BASE系统显著的特点是要保证在短时间内，即使有不同步的风险，也要允许新数据能够被存储。BASE系统倾向于简单和迅速，因为它们不必编写处理锁定和释放资源的代码，它们的任务是保证流程运转并稍后处理出错的部分。
2. 数据结构不同
第一，关系型数据库通常是以表格形式（行列）存储数据，而NoSQL系统有多种存储方式，包括列存储（Cassandra）、key/value存储（Redis）、文档存储（MongoDB）以及图存储（Neo4j）等。
第二，若要在关系型数据库中存储数据，必须先定义好模式（schemas），也就是用一种预定义的结构向数据库说明：要有哪些表格，表中有哪些列，每一列都存放何种类型的数据。相比之下，NoSQL数据库的数据存储就比较随意了。键值数据库可以把任何数据存放在一个”键”的名下。文档数据库实际上也如此，它对所存储的文档结构没有限制。
3. 可扩展性不同
第一，在关系型数据库里，增删字段是一件非常麻烦的事情。比如如果想删除某列，如果此列和其他数据关联，那么就无法轻易删除。NoSQL因为数据之间无关系，因此非常容易扩展。一旦发现了新东西，只要把它们加入数据库中就好。
第二，从架构的层面上讲，RDBMS是垂直扩展，当RDBMS数据库负载增加时，需要用更大更好的服务器来扩展数据库（因为RDBMS需要支持join，union等操作，一般不支持分布式集群）。而NoSQL数据库是横向扩展，可以自动对数据进行分片，并将分片存储在分布式系统（distributed system）上，这样，就可以通过增加更多的服务器来进行扩展。
4. 数据读写速度不同
当关系型数据库的数据量达到一定规模时，由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等并发问题，导致其读写速度下滑非常严重。而NoSQL数据库得益于它的数据库结构非常简单，且具有良好的集成缓存能力，读写性能非常好。
5. 成熟度不同
关系型数据库使用SQL语言，各种数据库之间的区别非常小。而NoSQL数据库没有统一的标准，其产品包括各种不同存储类型的数据库。
6. 成本不同
第一，关系型数据库软件价格昂贵，而NoSQL数据库基本都是开源软件，不需要花费大量成本购买使用，相比关系型数据库价格便宜。
第二，由于ACID模型非常复杂，维持高端的RDBMS系统是很昂贵的，需要训练有素的人管理数据库。而NoSQL数据库部署简单，通常使用廉价的服务器，管理也较少。
以下再摘录一份MongoDB官网上的资料：https://www.mongodb.com/nosql-explained
NoSQL vs. SQL Summary
|
|
SQL Databases |
NoSQL Databases |
|
Types |
One type (SQL database) with minor variations |
Many different types including key-value stores, document databases, wide-column stores, and graph databases |
|
Development History |
Developed in 1970s to deal with first wave of data storage applications |
Developed in late 2000s to deal with limitations of SQL databases, especially scalability, multi-structured data, geo-distribution and agile development sprints |
|
Examples |
MySQL, Postgres, Microsoft SQL Server, Oracle Database |
MongoDB, Cassandra, HBase, Neo4j |
|
Data Storage Model |
Individual records (e.g., 'employees') are stored as rows in tables, with each column storing a specific piece of data about that record (e.g., 'manager,' 'date hired,' etc.), much like a spreadsheet. Related data is stored in separate tables, and then joined together when more complex queries are executed. For example, 'offices' might be stored in one table, and 'employees' in another. When a user wants to find the work address of an employee, the database engine joins the 'employee' and 'office' tables together to get all the information necessary. |
Varies based on database type. For example, key-value stores function similarly to SQL databases, but have only two columns ('key' and 'value'), with more complex information sometimes stored as BLOBs within the 'value' columns. Document databases do away with the table-and-row model altogether, storing all relevant data together in single 'document' in JSON, XML, or another format, which can nest values hierarchically. |
|
Schemas |
Structure and data types are fixed in advance. To store information about a new data item, the entire database must be altered, during which time the database must be taken offline. |
Typically dynamic, with some enforcing data validation rules. Applications can add new fields on the fly, and unlike SQL table rows, dissimilar data can be stored together as necessary. For some databases (e.g., wide-column stores), it is somewhat more challenging to add new fields dynamically. |
|
Scaling |
Vertically, meaning a single server must be made increasingly powerful in order to deal with increased demand. It is possible to spread SQL databases over many servers, but significant additional engineering is generally required, and core relational features such as JOINs, referential integrity and transactions are typically lost. |
Horizontally, meaning that to add capacity, a database administrator can simply add more commodity servers or cloud instances. The database automatically spreads data across servers as necessary. |
|
Development Model |
Mix of open-source (e.g., Postgres, MySQL) and closed source (e.g., Oracle Database) |
Open-source |
|
Supports multi-record ACID transactions |
Yes |
Mostly no. MongoDB 4.0 and beyond support multi-document ACID transactions. Learn more |
|
Data Manipulation |
Specific language using Select, Insert, and Update statements, e.g. SELECT fields FROM table WHERE… |
Through object-oriented APIs |
|
Consistency |
Can be configured for strong consistency |
Depends on product. Some provide strong consistency (e.g., MongoDB, with tunable consistency for reads) whereas others offer eventual consistency (e.g., Cassandra). |
结论