而且假设面对大数据库，pt级别的数据，这样的浪费更是严重的，那么我们该使用是什么数据库？hbase数个不错的选择，那么我们对于hbase还存在下列问题：
2.HBase通过row和column确定一份数据，这份数据的值可能有多个版本号，为什么会存在多个版本号？
3.查询的时候会显示那个版本号？
4.它们的存储类型是什么？
5.tableName是什么类型？
6.RowKey 和 ColumnName是什么类型？
7.Timestamp 是什么类型？
8.value 是什么类型？
带着以上几个问题去读以下内容：
引言
团队中使用HBase的项目多了起来，对于业务人员而言，通常并不须要从头搭建、维护一套HBase的集群环境。对于其架构细节也不一定要深刻理解（交由HBase集群维护团队负责），迫切须要的是高速理解基本技术来解决业务问题。近期在XX项目轮岗过程中，尝试着从业务人员视角去看HBase，将一些过程记录下来，期望对高速了解HBase、掌握相关技术来开展工作的业务人员有点帮助。我认为作为一个初次接触HBase的业务开发測试人员，他须要迫切掌握的至少包括下面几点：
深入理解HTable。掌握怎样结合业务设计高性能的HTable
掌握与HBase的交互。反正是离不开数据的增删改查，通过HBase Shell命令及Java Api都是须要的
掌握怎样用MapReduce分析HBase里的数据。HBase里的数据总要分析的，用MapReduce是当中一种方式
掌握怎样測试HBase MapReduce，总不能光写无论正确性吧。debug是须要的吧。看看怎样在本机单測debug吧
本系列将环绕以上几点展开，篇幅较长。假设是HBase刚開始学习的人建议边读边练。对于HBase比較熟练的，能够选读下。比方关注下HBase的MapReduce及其測试方法。
从一个演示样例说起
传统的关系型数据库想必大家都不陌生，我们将以一个简单的样例来说明使用RDBMS和HBase各自的解决方案及优缺点。
以博文为例，RDBMS的表设计例如以下：
为了方便理解。我们以一些数据演示样例下
上面的样例。我们用HBase能够按下面方式设计
相同为了方便理解，我们以一些数据演示样例下，同一时候用红色标出了一些关键概念。后面会解释
HTable一些基本概念
Row key
行主键，
HBase不支持条件查询和Order by等查询，读取记录仅仅能按Row key（及其range）或全表扫描，因此Row key须要依据业务来设计以利用其存储排序特性（Table按Row key字典序排序如1,10,100,11,2）提高性能。
Column Family（列族）
在表创建时声明。每一个Column
Family为一个存储单元。在上例中设计了一个HBase表blog，该表有两个列族：article和author。
Column（列）
HBase的每一个列都属于一个列族。以列族名为前缀，如列article:title和article:content属于article列族，author:name和author:nickname属于author列族。
Column不用创建表时定义即能够动态新增。同一Column
Family的Columns会群聚在一个存储单元上，并依Column key排序，因此设计时应将具有同样I/O特性的Column设计在一个Column Family上以提高性能。
同一时候这里须要注意的是：这个列是能够添加和删除的，这和我们的传统数据库非常大的差别。
所以他适合非结构化数据。
Timestamp
HBase通过row和column确定一份数据。这份数据的值可能有多个版本号，不同版本号的值依照时间倒序排序，即最新的数据排在最前面，查询时默认返回最新版本号。如上例中row
key=1的author:nickname值有两个版本号，分别为1317180070811相应的“一叶渡江”和1317180718830相应的“yedu”（相应到实际业务能够理解为在某时刻改动了nickname为yedu，但旧值仍然存在）。
Timestamp默觉得系统当前时间（精确到毫秒）。也能够在写入数据时指定该值。
Value
每一个值通过4个键唯一索引。tableName+RowKey+ColumnKey+Timestamp=>value。比如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’
1317180718830’}索引到的唯一值是“yedu”。
存储类型
TableName
是字符串
RowKey
和 ColumnName 是二进制值（Java 类型 byte[]）
Timestamp
是一个 64 位整数（Java 类型 long）
value
是一个字节数组（Java类型 byte[]）。
存储结构
能够简单的将HTable的存储结构理解为
即HTable按Row
key自己主动排序。每一个Row包括随意数量个Columns，Columns之间按Column key自己主动排序，每一个Column包括随意数量个Values。理解该存储结构将有助于查询结果的迭代。
话说什么情况须要HBase
半结构化或非结构化数据
对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase。以上面的样例为例，当业务发展须要存储author的email，phone，address信息时RDBMS须要停机维护。而HBase支持动态添加.
记录很稀疏
RDBMS的行有多少列是固定的。为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
多版本号数据
如上文提到的依据Row
key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase就很方便了。比方上例中的author的Address是会变动的，业务上一般仅仅须要最新的值，但有时可能须要查询到历史值。
超大数据量
当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，server成本倍增。
随着压力添加。Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了。须要借助中间层。随着数据量的进一步添加，一个表的记录越来越大，查询就变得非常慢，于是又得搞分表，比方按ID取模分成多个表以降低单个表的记录数。经历过这些事的人都知道过程是多么的折腾。採用HBase就简单了，仅仅须要加机器就可以，HBase会自己主动水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。