[轉載]Hbase和RDBMS的區別

轉載：http://www.jdon.com/jivejdon/thread/38244

最近因爲項目原因，研究了Cassandra,Hbase等幾個NoSQL數據庫，最終決定採用HBase。在這裏，我就向大家分享一下自己對HBase的理解。

在說HBase之前，我想再嘮叨幾句。做互聯網應用的哥們兒應該都清楚，互聯網應用這東西，你沒辦法預測你的系統什麼時候會被多少人訪問，你面臨的用戶到底有多少，說不定今天你的用戶還少，明天系統用戶就變多了，結果您的系統應付不過來了了，不幹了，這豈不是咱哥幾個的悲哀，說時髦點就叫“杯具啊”。

其實說白了，這些就是事先沒有認清楚互聯網應用什麼纔是最重要的。從系統架構的角度來說，互聯網應用更加看重系統性能以及伸縮性，而傳統企業級應用都是比較看重數據完整性和數據安全性。那麼我們就來說說互聯網應用伸縮性這事兒.對於伸縮性這事兒，哥們兒我也寫了幾篇博文，想看的兄弟可以參考我以前的博文，對於web server,app server的伸縮性，我在這裏先不說了，因爲這部分的伸縮性相對來說比較容易一點，我主要來回顧一些一個慢慢變大的互聯網應用如何應對數據庫這一層的伸縮。

首先剛開始，人不多，壓力也不大,搞一臺數據庫服務器就搞定了，此時所有的東東都塞進一個Server裏，包括web server,app server,db server,但是隨着人越來越多，系統壓力越來越多，這個時候可能你把web server,app server和db server分離了，好歹這樣可以應付一陣子，但是隨着用戶量的不斷增加，你會發現，數據庫這哥們不行了，速度老慢了，有時候還會宕掉，所以這個時候，你得給數據庫這哥們找幾個伴，這個時候Master-Salve就出現了，這個時候有一個Master Server專門負責接收寫操作，另外的幾個Salve Server專門進行讀取，這樣Master這哥們終於不抱怨了，總算讀寫分離了，壓力總算輕點了,這個時候其實主要是對讀取操作進行了水平擴張，通過增加多個Salve來克服查詢時CPU瓶頸。一般這樣下來，你的系統可以應付一定的壓力，但是隨着用戶數量的增多，壓力的不斷增加，你會發現Master server這哥們的寫壓力還是變的太大，沒辦法，這個時候怎麼辦呢？你就得切分啊，俗話說“只有切分了，纔會有伸縮性嘛”，所以啊，這個時候只能分庫了，這也是我們常說的數據庫“垂直切分”，比如將一些不關聯的數據存放到不同的庫中，分開部署，這樣終於可以帶走一部分的讀取和寫入壓力了，Master又可以輕鬆一點了，但是隨着數據的不斷增多，你的數據庫表中的數據又變的非常的大，這樣查詢效率非常低，這個時候就需要進行“水平分區”了，比如通過將User表中的數據按照10W來劃分，這樣每張表不會超過10W了。

綜上所述，一般一個流行的web站點都會經歷一個從單臺DB，到主從複製，到垂直分區再到水平分區的痛苦的過程。其實數據庫切分這事兒，看起來原理貌似很簡單，如果真正做起來，我想凡是sharding過數據庫的哥們兒都深受其苦啊。對於數據庫伸縮的文章，哥們兒可以看看後面的參考資料介紹。

好了，從上面的那一堆廢話中，我們也發現數據庫存儲水平擴張scale out是多麼痛苦的一件事情，不過幸好技術在進步，業界的其它弟兄也在努力，09年這一年出現了非常多的NoSQL數據庫，更準確的應該說是No relation數據庫，這些數據庫多數都會對非結構化的數據提供透明的水平擴張能力，大大減輕了哥們兒設計時候的壓力。下面我就拿Hbase這分佈式列存儲系統來說說。

一 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/


暫時先分享這麼多,以後在項目運用中,遇到問題再分享給大家.