兴起原因 Not only SQL

传统的关系性数据库

关系代数理论基础
RDBMS只能纵向扩展：通过一台服务器增加性能终究难以满足数据量增长。
严格的数据库模式
索引机制，查询优化引擎：适当量级查询效率高
事务一致性：ACID
数据完整性：主键、约束
标准化：sql标准
技术支持：商业数据库
可维护：管理员维护

关系型数据库主从模式

面对日益增长的数据量，多台服务器的写主读从，分离单台服务器压力，但效果有限，且：
集群部署配置复杂
主库压力带来延迟
扩容重新分区复杂

web2.0的需求

关系型数据库事务机制需要额外的开销，但是在Web2.0通常不要求严格的数据库事务
不需要严格的读写实时性
不包含复杂的sql查询：连接操作牺牲性能节约空间

扩充关系型数据库无法实现的特点

1.灵活的可扩展性
2.灵活的数据模型
3.与云计算紧密结合：根据负载动态伸缩集群节点

NoSQL数据库优势

1.海量数据管理需求
2.高并发需求：动态数据实时生成性能需求
3.可扩展、高可用：突发事务访问量急剧增大

NoSQL数据库劣势

缺乏底层理论基础
事务强一致性：不适用关键业务

数据模型

不同场景下需要不同的数据模型

四大类型

在这里插入图片描述

键值数据库

如Redis存储键值对，
适合内容缓存
简单的数据模型
频繁读写
非结构化信息同时也有一些缺点，在一些场景下是不适合的：条件查询效率低、键与键之间没有办法反应联系关系
Q:只能通过Key访问Value，没有办法建立索引，关系型数据库中建立索引为什么更高效？

列族数据库

如HBase
海量数据分布式存储管理
副本中存在短期不一致的情况
动态字段的应用程序
部分支持强事务一致性

文档数据库

key对应文档，数据内容和类型自我描述，性能好，高并发
JSON数据格式
相较于关系型数据库，文档数据库信息的统一，避免了多表连接，方便迁移与并发
适用于：半结构化数据；存储和索引管理面向文档的数据
缺乏统一的查询语法以及事务机制

图数据库

基于图论
高度相互关系的数据
灵活性高，支持复杂的图形算法

三大基石

CAP

Consistency：一致
Availability:时间
partition：分区不影响整体
三者最多取其二：
事务相关内容在同一台机器
等数据一致再读
不一致也要响应
BASE（Basically Availble Soft state ＆Eventual consistency）
BA：允许出现分区失败
S:一段时间不同步
E：弱一致性，最终达到一致
因果一致性
读己之所写一致性
单调读一致性：进程已经访问到某个数据，后续访问不会返回那个值之前的旧值
会话一致性
单调写一致性：同一个进程写操作顺序执行