一 Hbase是個啥東東?
在說Hase是個啥傢伙之前,首先我們來看看兩個概念,面向行儲存和面向列儲存。面向行儲存,我相信大伙兒應該都清楚,我們熟悉的RDBMS就是此種類型的,面向行儲存的資料庫主要適合於事務性要求嚴格場合,或者說面向行儲存的儲存系統適合OLTP,但是根據CAP理論,傳統的RDBMS,為了實現強一致性,通過嚴格的ACID事務來進行同步,這就造成了系統的可用性和伸縮性方面大大折扣,而目前的很多NoSQL產品,包括Hbase,它們都是一種最終一致性的系統,它們為了高的可用性犧牲了一部分的一致性。好像,我上面說了面向列儲存,那麼到底什麼是面向列儲存呢?Hbase,Casandra,Bigtable都屬於面向列儲存的分布式儲存系統。看到這裡,如果您不明白Hbase是個啥東東,不要緊,我再總結一下下:
Hbase是一個面向列儲存的分布式儲存系統,它的優點在於可以實現高效能的並發讀寫操作,同時Hbase還會對資料進行透明的切分,這樣就使得儲存本身具有了水平伸縮性。
二 Hbase資料模型
HBase,Cassandra的資料模型非常類似,他們的思想都是來源於Google的Bigtable,因此這三者的資料模型非常類似,唯一不同的就是Cassandra具有Super cloumn family的概念,而Hbase目前我沒發現。好了,廢話少說,我們來看看Hbase的資料模型到底是個啥東東。
在Hbase裡面有以下兩個主要的概念,Row key,Column Family,我們首先來看看Column family,Column family中文又名“列族”,Column family是在系統啟動之前預先定義好的,每一個Column Family都可以根據“限定符”有多個column.下面我們來舉個例子就會非常的清晰了。
假如系統中有一個User表,如果按照傳統的RDBMS的話,User表中的列是固定的,比如schema 定義了name,age,sex等屬性,User的屬性是不能動態增加的。但是如果採用列儲存系統,比如Hbase,那麼我們可以定義User表,然後定義info 列族,User的資料可以分為:info:name = zhangsan,info:age=30,info:sex=male等,如果後來你又想增加另外的屬性,這樣很方便只需要info:newProperty就可以了。
也許前面的這個例子還不夠清晰,我們再舉個例子來解釋一下,熟悉SNS的朋友,應該都知道有好友Feed,一般設計Feed,我們都是按照“某人在某時做了標題為某某的事情”,但是同時一般我們也會預留一下關鍵字,比如有時候feed也許需要url,feed需要image屬性等,這樣來說,feed本身的屬性是不確定的,因此如果採用傳統的關聯式資料庫將非常麻煩,況且關聯式資料庫會造成一些為null的單元浪費,而列儲存就不會出現這個問題,在Hbase裡,如果每一個column 單元沒有值,那麼是佔用空間的。下面我們通過兩張圖來形象的表示這種關係:
是傳統的RDBMS設計的Feed表,我們可以看出feed有多少列是固定的,不能增加,並且為null的列浪費了空間。但是我們再看看,為Hbase,Cassandra,Bigtable的資料模型圖表,從可以看出,Feed表的列可以動態增加,並且為空白的列是不儲存的,這就大大節約了空間,關鍵是Feed這東西隨著系統的運行,各種各樣的Feed會出現,我們事先沒辦法預測有多少種Feed,那麼我們也就沒有辦法確定Feed表有多少列,因此Hbase,Cassandra,Bigtable的基於列儲存的資料模型就非常適合此情境。說到這裡,採用Hbase的這種方式,還有一個非常重要的好處就是Feed會自動切分,當Feed表中的資料超過某一個閥值以後,Hbase會自動為我們切分資料,這樣的話,查詢就具有了
伸縮性,而再加上Hbase的弱事務性的特性,對Hbase的寫入操作也將變得非常快。
上面說了Column family,那麼我之前說的Row key是啥東東,其實你可以理解row key為RDBMS中的某一個行的主鍵,但是因為Hbase不支援條件查詢以及Order by等查詢,因此Row key的設計就要根據你系統的查詢需求來設計了額。我還拿剛才那個Feed的列子來說,我們一般是查詢某個人最新的一些Feed,因此我們Feed的Row key可以有以下三個部分構成<userId><timestamp><feedId>,這樣以來當我們要查詢某個人的最進的Feed就可以指定Start Rowkey為<userId><0><0>,End Rowkey為<userId><Long.MAX_VALUE><Long.MAX_VALUE>來查詢了,同時因為Hbase中的記錄是按照rowkey來排序的,這樣就使得查詢變得非常快。
三 Hbase的優缺點
1 列的可以動態增加,並且列為空白就不儲存資料,節省儲存空間.
2 Hbase自動切分資料,使得資料存放區自動具有水平scalability.
3 Hbase可以提供高
並發讀寫操作的支援
Hbase的缺點:
1 不能支援條件查詢,只支援按照Row key來查詢.
2 暫時不能支援Master server的故障切換,當Master宕機後,整個儲存系統就會掛掉.
關於資料庫
伸縮性的一點資料:
http://www.jurriaanpersyn.com/archives/2009/02/12/database-sharding-at-netlog-with-mysql-and-php/
http://adam.blog.heroku.com/past/2009/7/6/sql_databases_dont_scale/