2012 年NOSQL学习笔记之二

2012年NOSQL学习笔记之二

六、ACID是什么？

ACID是如下单词的首字母。

原子性Atomicity、

一致性Consistency、

隔离性Isolation、

持久性Durability

ACID是传统的关系型数据库的特点。

C就是一致性（Consistency），这个特点是关系型数据库的灵魂（其他三个AID都是为其服务的），这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。



这个一致性很好理解，就是公司财务往银行账户存了钱，老板、客户、银行用户不同人员，应该看到钱是一样的。

七、NOSQL技术因为解决什么问题而产生的？

在网页应用中，尤其是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B同一个时刻点看到同一用户C的内容是不一致的，但是这个行为是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是那么重要了。



相反的，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博，facebook这类SNS的应用，对并发读写能力要求极高，关系型数据库已经无法应付（在读方面，传统上为了克服关系型数据库缺陷，提高性能，都是增加一级memcache来静态化网页，而在SNS中，变化太快，memcache已经无能为力），因此，必须用新的一种数据结构化存储来来代替关系数据库。



关系数据库的另一个特点就是其具有固定的表结构，因此，其扩展性极差，而在SNS中，系统的升级，功能的增加，往往意味着数据结构巨大改动，这一点关系型数据库也难以应付，需要新的结构化数据存储。

八、为什么要用NOSQL数据库？

随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance -对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。

2、Huge Storage -对海量数据的高效率存储和访问的需求

对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，***，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability && High Availability-对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web
server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？



　　在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍。

九、传统的关系型数据库有什么不足和缺陷？

对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1.数据库事务一致性需求

　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2.数据库的写实时性和读实时性需求

　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。

3.对复杂的SQL查询，特别是多表关联查询的需求

　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

　　因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。

十、为什么传统的关系型数据库就不能解决Web2.0出现的问题，理论依据是什么？

数据库里面有一个很重要CAP理论。

CAP

C: Consistency一致性
A: Availability可用性(指的是快速获取数据)
P: Tolerance of network Partition分区容忍性(分布式)

10年前，Eric Brewer教授指出了著名的CAP理论，后来Seth
Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好CAP理论。

传统数据库遵循ACID，在CAP的C和A上有很严格的要求，所以P很难达到。比如说，在大规模数据条件下，扩展性和性能要求就受到了很大的约束。

此外数据库还有一个很重要的BASE理论。

BASE

说起来很有趣，BASE的英文意义是碱，而ACID是酸。真的是水火不容啊。



Basically Availble --基本可用
Soft-state --软状态/柔性事务

"Soft state" 可以理解为"无连接"的,而
"Hard state"是"面向连接"的

Eventual Consistency --最终一致性

最终一致性，也是是 ACID的最终目的。

BASE模型正好和ACID模型相反，完全不同于ACID模型，BASE模型是以牺牲高一致性，来获得可用性或可靠性的。

Basically Available的含义是基本可用。支持分区失败(e.g. sharding碎片划分数据库)。

Soft state软状态。软状态的含义是状态可以有一段时间不同步，有一段时间是异步的。

Eventually consistent的含义是最终数据的效果是一致的就可以了，而不代表时时都是一致的。



BASE思想的主要实现有

1.按功能划分数据库

2.sharding碎片



BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。