数据库 —— 关系型数据库与非关系型数据库

关系型数据库与非关系型数据库对比总结

关系型数据库	只支持基础类型的存储	提供对事务的处理	查询速度慢，支持sql	不易于扩展，缺少灵活性	ACID
非关系型数据库	支持KV、文档图片的存储等等	不提供对事务的处理	查询速度快，不支持sql	易于扩展，使用灵活	CAP理论，不保证遵循ACID

查询速度：Nosql数据库将数据存储于缓存之中，而且不需要经过SQL层的解析，关系型数据库将数据存储在硬盘中，自然查询速度远不及Nosql数据库。

扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。Nosql基于键值对，数据之间没有耦合性，所以非常容易水平扩展。

持久存储：Nosql不使用于持久存储，海量数据的持久存储，还是需要关系型数据库

关系型数据库 —— ACID

A	Atomic	原子性	一个事务的所有系列操作步骤被看成是一个动作，所有的步骤要么全部完成要么一个也不会完成，如果事务过程中任何一点失败，将要被改变的数据库记录就不会被真正被改变。
C	Consistency	一致性	事务进行过后和执行前，整体系统都是稳定的，比如对于入账出账操作是不会有总资金的变化的。
I	Isolation	隔离性	指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。
D	Durability	持久性	指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。

非关系型数据库 —— CAP

CAP理论：一个分布式系统不可能同时满足C(一致性)、A(可用性)、P(分区容错性)三个基本需求，并且最多只能满足其中的两项。对于一个分布式系统来说，分区容错是基本需求，否则不能称之为分布式系统，因此需要在C和A之间寻求平衡。

C	Consistency	一致性	一致性是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。与ACID的C完全不同
A	Availability	可用性	可用性是指服务一直可用，而且是正常响应时间。
P	Partition tolerance	分区容错性	分区容错性是指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

• CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

常见非关系型数据库对比 —— MongoDB vs CouchDB

特征比较	CouchDB	MongoDB
数据模型	遵循面向文档的模型，数据以JSON格式呈现。	遵循面向文档的模型，但数据以BSON格式呈现。
对象存储	在CouchDB中，数据库包含文档。	在MongoDB中，数据库包含集合，而集合包含文档。
查询方法	CouchDB遵循Map/Reduce查询方法(JavaScript+其他)	MongoDB遵循Map/Reduce(JavaScript)创建集合+基于对象的查询语言。
并发	遵循MVCC(多版本并发控制)	就地更新
性能一致性	在CouchDB中比MongoDB更安全	在MongoDB中数据库包含集合，而集合包含文档。

MongoDB与CouchDB的一大区别就是CouchDB是一个MVCC 的 系统，而MongoDB进行写操作时都是即时完成写操作，写操作成功则数据就写成功了

MongoDB与传统的数据库系统类似，支持动态查询，即使在没有建立索引的行上，也能进行任意的查询。而CouchDB不同，CouchDB不支持动态查询，你必须为你的每一个查询模式建立相应的view ，并在此view的基础上进行查询

CouchDB是一个”crash-only”的系统，你可以在任何时候停掉CouchDB并能保证数据的一致性。而MongoDB在不正常的停掉后需要运repairDatabase()命令来修复数据文件，在1.7.5版本后支持单机可靠的–dur命令。

如果你在构建一个 Lotus Notes型的应用，我们推荐使用CouchDB，主要是由于它的MVCC机制。另外如果我们需要master-master的架构，需要基于地理位置的数据分布，或者在数据结点可能不在线的情况下，我们推荐使用CouchDB。

如果你需要高性能的存储服务，那我们推荐MongoDB，比如用于存储大型网站的用户个人信息，比如用于构建在其它存储层之上的Cache层。

如果你的需求中有大量update操作，那么使用MongoDB。那种经常变化的数据，比如浏览量，访问数之类的数据存储。

MVCC —— 多版本并发控制

Multi-Version Concurrency Control

如果有人从数据库中读数据的同时，有另外的人写入数据，有可能读数据的人会看到不一致的数据。在MVCC中，每个连接到数据库的读者，在某个瞬间看到的是数据库的一个快照。当一个 MVCC 数据库需要更一个一条数据记录的时候，它不会直接用新数据覆盖旧数据，而是将旧数据标记为过时（obsolete）并在别处增加新版本的数据。

数据库中存储了每一行的两个(1)额外的隐藏字段，这两个隐藏字段分别记录了行的创建的时间和删除的时间。存储的是系统版本号，而不是存储事件实际发生的时间。

JSON vs BSON

　bson主要会实现以下三点目标

1.更快的遍历速度
　　对json格式来说，太大的json结构会导致数据遍历非常慢。在json中，要跳过一个文档进行数据读取，需要对此文档进行扫描才行，需要进行麻烦的数据结构匹配，比如括号的匹配。
　　而bson对json的一大改进就是，它会将json的每一个元素的长度存在元素的头部，这样你只需要读取到元素长度就能直接seek到指定的点上进行读取了。
 

2.操作更简易
　　对json来说，数据存储是无类型的，比如你要修改基本一个值，从9到10，由于从一个字符变成了两个，所以可能其后面的所有内容都需要往后移一位才可以。
　　而使用bson，你可以指定这个列为数字列，那么无论数字从9长到10还是100，我们都只是在存储数字的那一位上进行修改，不会导致数据总长变大。
　　当然，在mongoDB中，如果数字从整形增大到长整型，还是会导致数据总长变大的。
 

3.增加了额外的数据类型
　　json是一个很方便的数据交换格式，但是其类型比较有限。
　　bson在其基础上增加了“byte array”数据类型。这使得二进制的存储不再需要先base64转换后再存成json，大大减少了计算开销和数据大小

　　json是像字符串一样存储的，bson是按结构存储的（像数组 或者说struct）