Hbase與傳統關係型數據庫對比

時間 2019-11-18

原文原文鏈接

在說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來查詢.

mysql

2 暫時不能支持Master server的故障切換,當Master宕機後,整個存儲系統就會掛掉.web

四.補充sql

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', 'aboutyun@sina.com');

刪除數據：

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

複製代碼