而且假設面對大數據庫，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）。