CAP定理小议

1. CAP定理

分布式领域的CAP定理，即Consistency（一致性）、Availability（可用性)和Partition Tolerance（分区容错性）

任何分布式系统只可同时满足二点，没法三者兼顾。

Consistency

指执行了一次成功的写操作之后，未来的读操作一定可以读到这个写入的值。

Availability

系统总是可读可写的

Partition Tolerance

除了整个网络的故障外，其他的故障（集）都不能导致整个系统无法正确响应。

2. CAP选择

放弃Partition Tolerance

会影响系统的Scale，要向避免Partition问题有两种方法。一种做法是将所有的东西（与事务相关的）都放到一台机器上。或者放在像rack这类的atomically-failling单元上。但还是会存在部分数据错误。

总之，分区容错性是不能牺牲的，因此只能在一致性和可用性上进行取舍。

放弃Availability

与Partition Tolerance关系：

一旦遇到partition 事件，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务。在多个节点上控制这一点会相当复杂，而且恢复的节点需要处理逻辑，以便平滑地返回服务状态。

与Consistency的关系：

放弃Availability则相当于选择了Consistency。但是如果系统不可用时，一致性也难以保持。即使对写操作进行缓冲处理，但是存储缓冲数据的机器出现故障，客户端将丢失写入的数据，而且缓冲写也可能是非一致性的。

放弃Consistency

如果持续的consistency或许并不是我们所需要的，则接受最终一致性Eventually Consistency。由此客户端有时会读到与刚刚写入不同的数据，而有时，同一时间同一个key的多个请求可能返回不同的结果，数据更新不能在所有复制节点上都及时生效。出现上述问题，则需要进行修复操作（repair），这就是需要使用矢量时钟记录数据的版本历史并合并不同的数据更新。

3. 纠正方案

3.1 引入BASE，Basically Available, Soft-state, Eventually consistent

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

BASE模型是反ACID模型，不同于ACID模型，牺牲高一致性，获得可用性或可靠性，但也不是完全不同，BASE思想的主要实现有按功能划分数据库和sharding碎片。
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步，异步。
Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

3.2 引入Hadoop，避免数据更新，从而避免了增量带来的复杂性

此方案的关键是不可变数据，这样就避免了数据更新，那就不可能有那么多数据片变成不一致，那就意味着没有vector clocks, or read-repair，只有数据和数据上的查询功能，你就不必面对最终一致性。

4. NoSQL分析

NoSQL现在被理解为 Not Only SQL 的缩写，是对非关系型的数据库管理系统的统称。
NoSQL 与 RDBMS 存在许多不同点：
最重要的是NoSQL不使用SQL作为查询语言。
NoSQL 不需要固定的表模式(table schema)，也经常会避免使用SQL的JOIN操作，一般有可水平扩展的特征。
NoSQL产品会放宽一个或多个 ACID 属性（CAP定理）

4.1 HBase

按照CAP理论，HBase属于C+P类型的系统。HBase是强一致性的（仅支持单行事务）。每一行由单个区域服务器（region server）、行锁（row locks）和多版本并发控制(multiversion concurrency control)的组合来保证行的一致性。

4.2 Hive

按照CAP理论，HBase属于A+P类型的系统。

Hive与传统关系数据库比较有如下几个特点：
侧重于分析，而非实时在线交易
无事务机制
不像关系数据库那样可以随机进行 insert或update
传统关系数据库只能拓展最多20个服务器，而Hive可以拓展到上百个服务器

在Hive中可使用Join语法，这是一般NoSQL的弱项，因为根据CAP定律，Join阻碍了分区，但是在Hive中Join的实现有其特殊性，Hive的Join策略有三种，各有利弊：

Shuffle Join洗牌式：这是一种最慢的Join策略，用Map/reduce将Join的key洗牌，然后在reduce时再连接，适合任何大小的数据集。

Broadcast Join广播式：将所有服务器上的表数据加载到内存，Mapper通过一个大表扫描然后进行连接，优点很快，但是内存必须能容纳一个表的所有数据。

Sort-­ Merge-­ Bucket Join：对于任何数据大小都很快，缺点是数据需要首先排序或Bucket。Bucket 只是hive 的一种hash partition 的实现。

参考文献

【1】http://blog.csdn.net/cutesource/article/details/5621725

【2】http://www.jdon.com/37625

【3】http://kb.cnblogs.com/page/124567/

【4】http://www.zhihu.com/question/21677041