HBase的NOSQL

noSQl系统普遍采用的一些技术有：

1. 简单数据模型
2. 元数据和应用数据的分离
3. 弱一致性
4. 避免不必要的复杂性
5. 高吞吐量
6. 使用MapReduce每天可处理20PB储存在Bigtable中的数据
7. 高水平扩展能力和低端硬件集群
8. 避免了昂贵的对象-关系映射

noSQL 的缺点

1. 数据模型和查询语言没有经过数学验证
2. 不支持ACID特性
3. 功能简单
4. 如果在应用层实现ACID特性，那编写代码的程序员一定极其痛苦

ＮＯＳＱＬ的数据模型

从数据模型的角度看：

• 键值数据
• 列式数据
• 文档数据
• 图形数据

CAP理论

CAP的三个特征

C:强一致性（consisency）

系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读取到最新的值，这样的系统被认为具有强一致性。

A:可用性（availability）

每一个操作总是能够在一定的时间内返回结果，这里需要注意的是“一定时间内”和“返回结果”。

“一定时间内”是指，系统的结果必须在给定时间内返回，如果超时则被认为不可用。
“返回结果”同样非常重要。还是拿这个例子来说，假如购买者点击支付之后很快出现了结果，但是结果却是“java.lang.error…”之类的错误信息。这对于普通购买者来说相当于没有返回任何结果。因为他仍旧不知道系统处于什么状态，是支付成功还是失败，或者需要重新操作

P:分区容错性（Partition tolerance）

分区容错性可以理解为系统在存在网络分区的情况下仍然可以接受请求（满足一致性和可用性）。这里网络分区是指由于某种原因网络被分成若干个孤立的区域，而区域之间互不相通。还有一些人将分区容错性理解为系统对节点动态加入和离开的处理能力，因为节点的加入和离开可以认为是集群内部的网络分区。

CAP理论三个条件CAP

是在分布式环境中设计和部署系统时所要考虑的三个重要的系统需求。根据CAP 理论，数据共享系统只能满足这三个特性中的两个，而不能同时满足三个条件。因此系统设计者必须在这三个特性之间做出权衡。

由表8，可以看出，三种不同的组合对应着放弃了CAP 三个特性当中的一个：

• 放弃P：如果想避免分区容错性问题的发生，一种做法是将所有的数据（与事务相关的）都放到一台机器上。
• 放弃A：相对于放弃“分区容错性”来说，其反面就是放弃可用性。
• 放弃C：这里所说的放弃一致性，并不是完全放弃数据的一致性，而是放弃数据的强一致性，而保留数据的终一致性。
• 其他选择：引入BASE（Basically Available, Soft-state, Eventually consistent），该方法支持终一致性，其实是放弃C 的一个特例，我们将在后文进行介绍。