NoSQL数据库的特点：（1）灵活的可扩展性（2）灵活的数据模型（3）与云计算紧密融合
NoSQL兴起的原因
1、关系数据库已经无法满足Web2.0的需求，主要表现在：无法满足海量数据的管理需求、无法满足数据高并发的需求、无法满足高可扩展性和高可用性的需求
2、“One size fits all”模式很难适用于截然不同的业务场景，关系模型作为统一的数据模型既被用于数据分析，也被用于在线业务。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同一套模型来抽象是不合适的。
Hadoop针对数据分析；MongoDB、Redis等是针对在线业务，两者都抛弃了关系模型。
3、关系数据库的关键特性包括完善的事务机制和高效的查询机制。这两个关键特性对于Web2.0时代却成了鸡肋，主要表现在：
Web2.0网站系统通常不要求严格的数据库事务；Web2.0并不要求严格的读写实时性；Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能）
| 比较标准 | 关系数据库 | NoSQL | 备注 |
|---|---|---|---|
| 数据库原理 | 完全支持 | 部分支持 |
关系数据库有关系代数理论作为基础； NoSQL没有统一的理论基础 |
| 数据规模 | 大 | 超大 |
关系数据库很难实现横向扩展，纵向扩展的空间也比较有限，性能随着数据规模的增大而降低； NoSQL很容易通过添加更多设备来支持更大规模的数据 |
| 数据库模式 | 固定 | 灵活 |
关系数据库需要定义数据库模式，严格遵守数据定义和相关约束条件； NoSQL不存在数据库模式，可*、灵活地定义、存储各种不同类型的数据 |
| 查询效率 | 快 | 简单查询高效，但复杂查询性能不尽人意 |
关系数据库借助索引机制实现快速查询； 很多NoSQL数据库没有面向复杂查询的索引，虽然可以使用MapReduce来加速查询，但复杂查询方面性能不如关系数据库 |
| 一致性 | 强一致性 | 弱一致性 |
关系数据库严格遵守事务ACID模型，保证事务强一致性； NoSQL大多只遵守BASE模型，保证最终一致性 |
| 数据完整性 | 容易实现 | 很难实现 |
关系数据库容易实现数据完整性，如通过主键或非空约束实现实体完整性，通过主键、外键实现参照完整性，通过约束或触发器实现用户自定义完整性； NoSQL却难以实现 |
| 扩展性 | 一般 | 好 |
关系数据库很难实现横向扩展，纵向扩展的空间也比较有限； NoSQL通过添加廉价设备实现扩展 |
| 可用性 | 好 | 很好 |
关系数据库在任何时候都以保证数据一致性为优先目标，其次是优化系统性能，随着数据规模增大，可用性较弱； 大多NoSQL都能提供较高的可用性 |
| 标准化 | 是 | 否 |
关系数据库已经标准化（SQL）； NoSQL没有行业标准，不同NoSQL数据库都有自己的查询语言，很难规范应用程序接口 |
| 技术支持 | 高 | 低 | |
| 可维护性 | 复杂 | 复杂 |
NoSQL的四大类型
键值数据库、列族数据库、文档数据库、图形数据库
NoSQL的三大基石
CAP
C（Consistency）一致性、A（Availability）可用性、P（Tolerance of Network Partition）分区容忍性
CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求，最多只能同时满足其中两个。
1.CA：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server和PostgreSQL），都采用了这种设计原则，因此，扩展性都比较差
2.CP：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务
3.AP：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系统返回不一致的数据，也可以采取最终一致性策略。
BASE
BASE（Basically Availble, Soft-state, Eventual consistency）
BASE的基本含义：
基本可用（Basically Availble）:指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现
软状态（Soft-state）:是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性
最终一致性（Eventual consistency）
最终一致性
因果一致性：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守一般的最终一致性规则
“读己之所写”一致性：可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值
单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值
会话一致性：它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话
单调写一致性：系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性，否则就非常难以编程了
