image
前言
近几年NoSQL数据库兴起，各种新的产品层出不穷，在此学习下NoSQL的基本理论，并认识下常见的NoSQL数据库。
一 NoSQL数据库兴起的原因
随着大数据技术兴起和Web2.0时代的到来。传统关系型数据库已经无法满足当前的数据库需求了。
无法满足的需求主要有3点:
- 海量数据的存储与管理 （传统关系型数据库已经无法支撑）
- 大数据量下的并发性 （传统关系型数据库严格的事务机制导致了海量数据的操作会导致大范围的数据锁定，降低并发性）
- 高可用性，高扩展性（用户更关注是否功能可用。海量数据需要横向扩展数据库满足需求，纵向已经无法满足）
与之相比原本关系型数据库的优点已经不被许多公司所需要，主要也有3点：
- 严格的数据库事务（如微信，新浪微博等互联网公司，丢失一条消息等，ACID的实现与否并不是很重要）
- 严格的读写实时性（同理，一条消息服务器写入后，其他人是否立即看到并不太重要）
- 复杂的条件查询（为了节约硬件存储空间降低冗余，传统关系型数据库会将各种信息分表存储，但是现在硬件性能已经足够将信息全部存储。并不太需要复杂的多表查询操作）
为了满足大数据量下的业务需求，传统关系型数据库也发展出多种技术手段，但是最终事实证明NoSQL数据库才是最适合的选择。传统关系型数据库的解决方案经历了如下几个阶段：
- 主从复制，实现读写分离。设置一个主服务器，若干从服务器。主服务器负责写操作，并实时复制修改内容到从服务器上。从服务器负责读操作。（但是对于写请求的负担仍然无法解决）
- 分库，分流一部分请求。分库又分为横向分库和纵向分库，横向分库即将不同业务维度的数据库拆分开来，服务器根据业务场景，查询不同数据库。纵向分库即将数据行按照一定的规律分别存储到不同数据库内。如：根据hash，根据生产时间等。（但是导致了不同库之间不能直接查询，且仍然无法满足更大的数据要求）
- 分表，类似于分库。通过横向或者纵向切分表。
二 NoSQL数据库的四大类型
分别是 ：
- 键值数据库
- 列族数据库
- 文档数据库
- 图数据库
2.1 普遍的特性（优点）
- 数据结构灵活。（传统关系型数据库有严格的字段要求，且后续修改复杂）
- 可扩展性强（容易横向扩展，支持分布式，且扩展的复杂度不高，对比传统关系型数据库的扩展非常复杂）
- 支持高并发操作。
2.2 各自的特性
- 键值数据库。是键值对的存储数据库。
- 优点：适合大量写操作。
- 缺点：但是存储的数据没有结构化，复杂查询效率低。
- 应用：常用做内容缓存。
- 代表产品：Redis，Memcached
- 列族数据库，底层基于列族进行存储的数据库。（查找时，基于行键列族查找，可以看做键值数据库的变种）
- 优点：查询速度快，横向扩展性尤其好，适合分布式系统，屏蔽了分布式的复杂性。
- 缺点：功能简单，大都不支持事务一致性。（Hadoop的HBase是支持的）
- 应用：分布式的数据存储。
- 代表产品：Cassandra，HBase
- 文档数据库，基于键存储文档。（也可看做键值数据库的变种）
- 优点：半结构化，数据格式可以自解释，如：JSON,XML。因此数据结构非常灵活，且并发性高。
- 缺点：缺乏统一的查询语法
- 应用：存储文档型数据，半结构化数据。
- 代表产品：MongoDB，CouchDB
- 图数据库，基于图数据结构的数据库。
- 优点：支持复杂的图算法与关系图谱
- 缺点：只适合图和关系的应用领域，其他领域性能较差。
- 应用：复杂图结构，如社交网络，关系图谱。
- 代表产品：Neo4J，InfoGrid
三 NoSQL数据库的三大基石
3.1 CAP理论三个特性
- C：一致性（任何一个读操作总是能读取到之前完成的写操作结果）
- A：可用性（每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的）
- P：分区容忍性（出现网络分区，整个系统仍然可用）
经过证明，一个分布式系统不能同时满足三个特性，最多满足两个。
传统关系型数据库满足了CA，放弃了P。因此扩展困难。而现在大部分互联网系统都是分布式系统，不可能放弃P特性。
通俗的解释下为何只能同时满足两个特性：
假设同时满足C和A和P。P保证了系统存在不同的网络节点，那么为了保证C，系统会尝试与其他的节点同步数据信息，但是出现网络问题导致系统分区时（即节点无法互相通信），会导致同步无法立刻完成，这样就无法满足A了。
此时只需要去除一个特性即可：
- 去除P，保留CA。则没有了网络通信问题，在实现C数据一致性时，可以很快的完成，也保证了A。
- 去除A，保留CP。则不要求立刻完成，在实现C数据一致性时，即使出现了网络分区P，也可以慢慢等待。
- 去除C，保留AP。则不需要保证数据一致性了，即使网络出现分区，各个节点都能单独运行，保证了用户可用(反正系统已经不在乎各个节点数据的一致了)。
3.2 BASE理论
BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性。
- BA：基本可用。一部分分区出现问题，系统仍然可用,主要保证核心功能可用。（电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现）
- S：软状态。数据的一致性要求降低，可以一段时间不满足一致性。相对应的是硬状态。（分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。）
- E：最终一致性。弱一致性，后续操作无法立刻获取更新的信息。相对应的是强一致性。最终一致性是特殊的弱一致性，只保证了。
3.3 最终一致性
（明明BASE就包含了最终一致性，不知道书中为何又将它单独列为三大理论基础之一）
