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宕機後,整個儲存系統就會掛掉.

四.補充

1.資料型別，HBase只有簡單的字元型別，所有的型別都是交由使用者自己處理，它只儲存字串。而關係資料庫有豐富的型別和儲存方式。
2.資料操作：HBase只有很簡單的插入、查詢、刪除、清空等操作，表和表之間是分離的，沒有複雜的表和表之間的關係，而傳統資料庫通常有各式各樣的函式和連線操作。
3.儲存模式：HBase是基於列儲存的，每個列族都由幾個檔案儲存，不同的列族的檔案時分離的。而傳統的關係型資料庫是基於表格結構和行模式儲存的
4.資料維護，HBase的更新操作不應該叫更新，它實際上是插入了新的資料，而傳統資料庫是替換修改
5.可伸縮性，Hbase這類分散式資料庫就是為了這個目的而開發出來的，所以它能夠輕鬆增加或減少硬體的數量，並且對錯誤的相容性比較高。而傳統資料庫通常需要增加中間層才能實現類似的功能

下面是用詳細實際操作截圖比較區別
1.nosql資料庫能否刪除列
2.nosql資料庫如何刪除一條記錄
3.nosql資料庫列族和lieder區別是什麼？
4.nosql操作與傳統資料庫的操作區別在什麼地方？

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

1.傳統資料庫增加刪除介紹
圖1
下面我們以mysql為例：

插入資料

mysql>INSERT INTO blog_user (user_Name,user_Password,user_emial)VALUES (‘aboutyun’,’aboutyun’, ‘[email protected]’);

刪除資料：

mysql> delete from blog_user where user_name=”aboutyun”;

2.Nosql資料庫增加刪除介紹

圖2
以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：

hbase(main):015:0> put’blog_user’,’www.aboutyun.com’,’userInfo:user_Password’,’aboutyun’

再次查詢結果：

hbase(main):016:0> scan ‘blog_user’
ROW COLUMN+CELL
www.aboutyun.com column=userInfo:user_Name, timestamp=1400663775901, value=aboutyun
www.aboutyun.com column=userInfo:user_Password, timestamp=1400665203430, value=aboutyun
1 row(s) in 0.0390 seconds

到這裡，我們看到兩行記錄，傳統資料塊認為這是兩行資料，對於nosql，這是一條記錄。

刪除列資料

刪除資料分為刪除列和刪除記錄
1.刪除列
這裡面的刪除，沒有刪除

delete 'blog_user','www.aboutyun.com','userInfo:user_Password'

從上面我們看出列被刪除了
2.刪除記錄：

deleteall 'blog_user','www.aboutyun.com'

這是刪除之前顯示結果，這裡已經是

刪除後結果

總結
對於傳統資料庫，增加列對於一個專案來講，改變是非常大的。但是對於nosql，插入列和刪除列，跟傳統資料庫裡面的增加記錄和刪除記錄類似
參考網址 Hbase與傳統資料庫的區別

Table中Family和Qualifier的關係與區別

就像用MySQL一樣，我們要做的是表設計，MySQL中的表，行，列的在HBase已經有所區別了，在HBase中主要是Table和Family和Qualifier，這三個概念。Table可以直接理解為表，而Family和Qualifier其實都可以理解為列，一個Family下面可以有多個Qualifier，所以可以簡單的理解為，HBase中的列是二級列，也就是說Family是第一級列，Qualifier是第二級列。兩個是父子關係。

談談Table中Family和Qualifier的設定
對於傳統關係型資料庫中的一張table，在業務轉換到hbase上建模時，從效能的角度應該如何設定family和qualifier呢？
最極端的，可以每一列都設定成一個family，也可以只有一個family，但所有列都是其中的一個qualifier，那麼有什麼區別呢？
family越多，那麼獲取每一個cell資料的優勢越明顯，因為io和網路都減少了，而如果只有一個family，那麼每一次讀都會讀取當前rowkey的所有資料，網路和io上會有一些損失。
當然如果要獲取的是固定的幾列資料，那麼把這幾列寫到一個family中比分別設定family要更好，因為只需一次請求就能拿回所有資料。
以上是從讀的方面來考慮的，那麼寫呢？可以參考一下這篇文章：
http://hbase.apache.org/book/number.of.cfs.html
首先，不同的family是在同一個region下面。而每一個family都會分配一個memstore，所以更多的family會消耗更多的記憶體。
其次,目前版本的hbase，在flush和compaction都是以region為單位的，也就是說當一個family達到flush條件時，該region的所有family所屬的memstore都會flush一次，即使memstore中只有很少的資料也會觸發flush而生成小檔案。這樣就增加了compaction發生的機率，而compaction也是以region為單位的，這樣就很容易發生compaction風暴從而降低系統的整體吞吐量。
第三，由於hfile是以family為單位的，因此對於多個family來說，資料被分散到了更多的hfile中，減小了split發生的機率。這是把雙刃劍。更少的split會導致該region的體積比較大，由於balance是以region的數目而不是大小為單位來進行的，因此可能會導致balance失效。而從好的方面來說，更少的split會讓系統提供更加穩定的線上服務。
上述第三點的好處對於線上應用來說是明顯的，而壞處我們可以通過在請求的低谷時間進行人工的split和balance來避免掉。
因此對於寫比較多的系統，如果是離線應該，我們儘量只用一個family好了，但如果是線上應用，那還是應該根據應用的情況合理地分配family。