1.1为什么要设计这么一套新的存储架构
现在互联网时代，不管生活中存在什么问题，我们都想通过互联网来快速的检索到答案，并且希望查到的结果是有用的。
在这个海量数据的时代，对于之前的关系型数据库可采取的措施就是把收集的数据删减后保存，比如保存近N天的数据，但是这样没办法存储几年甚至更长时间的数据，也就无法对用户历史的行为进行分析。
因此新的存储架构就产生了，hadoop擅长存储任意的、半结构化的甚至是非结构话的数据，它给用户提供了数据存储的无限空间，支持用户在前挡的时候存储和获取数据，对大文件存储、批量访问和流式访问做了优化。
1.2RDBMS的问题
RDBMS在存储保留用户、产品、订单订单信息的时候提供持久化的服务是很合适的。但是对于数据迅速增长的情况，RDBMS就不大够用了。
RDBMS提供了ACDI的特性，代表用户数据是强一致性，这样的如果你的用户量特别多，那么共享的数据库服务器的压力也会越来越大，增加服务器可以有一定作用，但是对中央数据库CPU和I/O负载还是有一定压力。
我们减轻压力的第一步增加并行读取的从服务器，将读写分离，因为DB写的请求远少于读的请求，用户大多数是浏览操作，但是如果用户量持续上升，这样也会收到性能限制。
接下来就需要增加缓存了，把都操作放在内存中缓存数据的系统里，但是这样的问题无法保证数据的一致性，因为DB不会主动去更新缓存中的数据，这样可以缓解读操作的压力，但是写操作还是没有解决。
如果负载在几个月内会增加一个数量级这时候我们用RDBMS的代价就比较昂贵了，MySQL这种数据库适合于特定场景业务，而且短期不会被取代，只是我们开发一个新产品，能预料到系统扩展速度很快，那我们在设计段就应该希望所有功能都可以用。
1.3NoSQL（Not-Only-SQL）
RDBMS很适合事务性操作，但不适合超大规模的数据分析处理，而且它出现等待和死锁的频率与事务和并发的增加并不是线性关系，Hbase可以满足这些需求。
NoSQL对系数矩阵、宽表、列式存储的支持使数据在存储的时候无需范式化，也可以避免查询时用开销很大的JOIN操作。使用智能的逐渐可以控制数据怎么去存储和存储到什么位置。可以使用行键的部分内容去进行检索，和字典序坐部分为头的索引效果相似，这样的设计是性能不会因为数据增长而下降。
1.4结构
表、行、列和单元格
最基本的单位是**列**。一列或多列形成一**行**，由唯一的**行键**（rowKey）来确定存储。反过来，一个**表**中有若干行，其中每列可能有多个版本，在每一个**单元格**中存储了不同的值。
所有的行键按照字典序进行排序存储
行键排序可得到想RDBMS的主键索引一样的特性，意味着行键总是唯一的，并且只出现一次，否则就是在更新同一行。
一行由若干列组成，这若干列又构成了一个列族，这有助于构建数据局部边界和其他一些特性。
自动分区
在HBase中扩展和负载均衡的基本单元是region，region的本质是以行键排序的连续存储区间，如果region过大，系统就动态拆分，反之即使合并，减少存储文件数量。
region拆分和服务相当于其他系统提供的**自动分区**。当一个服务器出现故障后，该服务器上的region可以快速回复，并获得细粒度的负载均衡，因为当服务于某个region的服务器当负载过大、发生错误或被停止导致不可用时，系统会将该region移到其他服务器。
实现
数据存储在**存储文件**中，成为HFile。文件内部由连续块组成，块的索引信息存储在文件尾部。当把HFile打开加载到内存的时候，索引信息会先加载到内存。每一个HFile都有一个快索引，通过以磁盘查找就可以实现查询。现在内存的块索引中进行二分查找，确定可能包含给定键的块，然后读取磁盘块找到实际要找的键。
每次更新数据的时候，都先将数据记录在提交日志中（HBase叫预写日志），然后才会把这些数据写入内存的memstore中。一旦内存中保存的写入数据累计超过了一个给定的大小，系统就把这些数据移出内存作为HFile文件写到磁盘中，数据移出内存之后系统会丢弃对应的提交日志，只保留为持久化的到磁盘的日志，系统将数据移出memstore写入磁盘的似乎和，不必阻塞系统的读写，通过滚动内存中的memstore就剋有实现。
HBase中有三给主要组件：客户端库、一台主服务器、多台region服务器。可以动态增加移除region服务器，适应不断变化的负载。主服务器主要负责用Apache Zookeeper 为region服务器分配region，Apache Zookeeper 是一个可靠的、高可用的、持久化的分布式协调系统。
HBase权威指南阅读——第一章