hbase和關系型數據庫的區別 - 全文

HBase相對于關系數據庫能解決的問題是什么？

關于HBase與關系數據的區別問題其實就是關系數據庫與HBase各自的優缺點。

關系數據庫的缺憾：

1）擴展困難

2）維護復雜

HBase就是解決可伸縮行的問題。通過簡單增加節點來獲取線性擴展性。不支持SQL。

圖解Nosql（hbase）與傳統數據庫的區別

對于大多數做技術的人員，都知道我們傳統數據庫是什么樣子的，那么如下圖所示，我們操作的對象是行。也就是增刪改查，都是以為對象

1. 傳統數據庫增加刪除介紹

下面我們以mysql為例：

插入數據

mysql》INSERT INTO blog_user （`user_Name`，`user_Password`，`user_emial`）VALUES （‘aboutyun’，‘aboutyun’， ‘aboutyun@sina.com’）;

刪除數據：

mysql》 delete from blog_user where user_name=“aboutyun”;

2. Nosql數據庫增加刪除介紹

以hbase為例：

創建表：

create ‘blog_user’，‘userInfo’

插入數據

這里是關鍵點，也是很多人不容易理解的地方

hbase（main）：012:0》 put‘blog_user’，‘www.aboutyun.com’，‘userInfo:user_Name’，‘aboutyun’

0 row（s） in 1.7530 seconds

上面我們看到了

1所示是什么，我們在傳統數據塊里面根本沒有，這是nosql所特有的，是一個rowkey，是系統自帶的，也是nosql中一條記錄的唯一標識。但是這個唯一標識，有跟我們的傳統數據庫是有所差別的。如圖1所示，“記錄1”便是rowkey.

2所示是我們插入的列user_Name，這也是最難以理解的地方，列竟然可以插入。并且其’value‘為3即‘aboutyun’

我們插入了列，下面我們來查看一下效果：?

下面來解釋一下上面的含義：

我們會看到

1為rowkey，插入數據’www.aboutyun.com‘，

2為列族下面列的名字user_Name

3我們并沒有在設計的添加這個列族，所以這個是系統自帶的，這個是記錄的操作時間，以時間戳的形式放到hbase里面。

4是我們插入的user_Name的值

下面我們在插入password：

1. hbase（main）：015:0》 put‘blog_user’，‘www.aboutyun.com’，‘userInfo:user_Password’，‘aboutyun’

再次查詢結果：

1. hbase（main）：016:0》 scan ‘blog_user’

2. ROW COLUMN+CELL

3. www.aboutyun.com column=userInfo:user_Name， timestamp=1400663775901， value=aboutyun

4. www.aboutyun.com column=userInfo:user_Password， timestamp=1400665203430， value=aboutyun

5. 1 row（s） in 0.0390 seconds

到這里，我們看到兩行記錄，傳統數據塊認為這是兩行數據，對于nosql，這是一條記錄。

刪除列數據

刪除數據分為刪除列和刪除記錄

1.刪除列

這里面的刪除，沒有刪除

delete ‘blog_user’，‘www.aboutyun.com’，‘userInfo:user_Password’

從上面我們看出列被刪除了

2.刪除記錄：

1. deleteall ‘blog_user’，‘www.aboutyun.com’

2. 這是刪除之前顯示結果，這里已經是

刪除后結果

結論：

對于傳統數據庫，增加列對于一個項目來講，改變是非常大的。但是對于nosql，插入列和刪除列，跟傳統數據庫里面的增加記錄和刪除記錄類似

HBase有哪些基本的特征？

HBase是類似于google的bigtable的開源實現，擁有以下特征：

1）在HDFS之上

2）基于列存儲的分布式數據庫

3）用于實時地讀、寫大規模數據集

其他HBase的特性：

1）沒有真正的索引，行順序存儲，也沒有所謂的索引膨脹問題。

2）自動分區，表增長時，自動分區到新的節點上。

3）線性擴展和區域會自動重新平衡，運行RegionServer，達到負載均衡的目的。

4）容錯和普通商用的硬件支持。這點同hadoop類似。

HBase與RDBMS的區別？

1）表的設計：HBase的表可以很高，很寬，可伸縮性很強。而且表的模式是物理存儲的直接反映。

2）拓撲： HBase能水平分區并在上千個節點上自動復制。

3）應用形式：開發者必須承擔更多的責任來正確地利用HBase的檢索和存儲方式。

4） RDBMS 遵循固定的模式，如“codd 12 規則”，強調事務的“強一致性”、參照完整性、SQL支持、數據的邏輯與物理形式相對獨立。等等。適用于中小規模的數據，但對于數據的規模和并發讀寫方面進行大規模擴展時，RDBMS會性能大大降低，分布式更為困難，因為其需要放棄很多RDBMS的易用的特性。

HBase適用于上億、上千億級的數據，如果是只有上千、上百萬級別是數據，傳統的RDBMS是更好的選擇。

HBase需要更多硬件，如果硬件較少，如5個，干不成什么好事。

如果從RDBMS移植到HBase，需要消除RDBMS的很多額外特性，如列數據類型、第二索引、事務、高級查詢等。