|
文章分類:Java編程
最近因?yàn)轫?xiàng)目原因，研究了Cassandra,Hbase等幾個(gè)NOSQL數(shù)據(jù)庫，最終決定采用HBase。在這里，我就向大家分享一下自己對HBase的理解。 在說HBase之前，我想再嘮叨幾句。做互聯(lián)網(wǎng)應(yīng)用的哥們兒應(yīng)該都清楚，互聯(lián)網(wǎng)應(yīng)用這東西，你沒辦法預(yù)測你的系統(tǒng)什么時(shí)候會被多少人訪問，你面臨的用戶到底有多少，說不定今天你的用戶還少，明天系統(tǒng)用戶就變多了，結(jié)果您的系統(tǒng)應(yīng)付不過來了了，不干了，這豈不是咱哥幾個(gè)的悲哀，說時(shí)髦點(diǎn)就叫“杯具啊”。 其實(shí)說白了，這些就是事先沒有認(rèn)清楚互聯(lián)網(wǎng)應(yīng)用什么才是最重要的。從系統(tǒng)架構(gòu)的角度來說，互聯(lián)網(wǎng)應(yīng)用更加看重系統(tǒng)性能以及伸縮性，而傳統(tǒng)企業(yè)級應(yīng)用都是比較看重?cái)?shù)據(jù)完整性和數(shù)據(jù)安全性。那么我們就來說說互聯(lián)網(wǎng)應(yīng)用伸縮性這事兒。
對于伸縮性這事兒，哥們兒我也寫了幾篇博文，想看的兄弟可以參考我以前的博文，對于web server,app server的伸縮性，我在這里先不說了，因?yàn)檫@部分的伸縮性相對來說比較容易一點(diǎn)，我主要來回顧一些一個(gè)慢慢變大的互聯(lián)網(wǎng)應(yīng)用如何應(yīng)對數(shù)據(jù)庫這一層的伸縮。 首先剛開始，人不多，壓力也不大,搞一臺數(shù)據(jù)庫服務(wù)器就搞定了，此時(shí)所有的東東都塞進(jìn)一個(gè)Server里，包括web server,app server,db server,但是隨著人越來越多，系統(tǒng)壓力越來越多，這個(gè)時(shí)候可能你把web server,app server和db server分離了，好歹這樣可以應(yīng)付一陣子，但是隨著用戶量的不斷增加，你會發(fā)現(xiàn)，數(shù)據(jù)庫這哥們不行了，速度老慢了，有時(shí)候還會宕掉，所以這個(gè)時(shí)候，你得給數(shù)據(jù)庫這哥們找?guī)讉€(gè)伴，這個(gè)時(shí)候Master-Salve就出現(xiàn)了，這個(gè)時(shí)候有一個(gè)Master Server專門負(fù)責(zé)接收寫操作，另外的幾個(gè)Salve Server專門進(jìn)行讀取，這樣Master這哥們終于不抱怨了，總算讀寫分離了，壓力總算輕點(diǎn)了,這個(gè)時(shí)候其實(shí)主要是對讀取操作進(jìn)行了水平擴(kuò)張，通過增加多個(gè)Salve來克服查詢時(shí)CPU瓶頸。一般這樣下來，你的系統(tǒng)可以應(yīng)付一定的壓力，但是隨著用戶數(shù)量的增多，壓力的不斷增加，你會發(fā)現(xiàn)Master server這哥們的寫壓力還是變的太大，沒辦法，這個(gè)時(shí)候怎么辦呢？你就得切分啊，俗話說“只有切分了，才會有伸縮性嘛”，所以啊，這個(gè)時(shí)候只能分庫了，這也是我們常說的數(shù)據(jù)庫“垂直切分”，比如將一些不關(guān)聯(lián)的數(shù)據(jù)存放到不同的庫中，分開部署，這樣終于可以帶走一部分的讀取和寫入壓力了，Master又可以輕松一點(diǎn)了，但是隨著數(shù)據(jù)的不斷增多，你的數(shù)據(jù)庫表中的數(shù)據(jù)又變的非常的大，這樣查詢效率非常低，這個(gè)時(shí)候就需要進(jìn)行“水平分區(qū)”了，比如通過將User表中的數(shù)據(jù)按照10W來劃分，這樣每張表不會超過10W了。 綜上所述，一般一個(gè)流行的web站點(diǎn)都會經(jīng)歷一個(gè)從單臺DB，到主從復(fù)制，到垂直分區(qū)再到水平分區(qū)的痛苦的過程。其實(shí)數(shù)據(jù)庫切分這事兒，看起來原理貌似很簡單，如果真正做起來，我想凡是sharding過數(shù)據(jù)庫的哥們兒都深受其苦啊。對于數(shù)據(jù)庫伸縮的文章，哥們兒可以看看后面的參考資料介紹。 好了，從上面的那一堆廢話中，我們也發(fā)現(xiàn)數(shù)據(jù)庫存儲水平擴(kuò)張scale out是多么痛苦的一件事情，不過幸好技術(shù)在進(jìn)步，業(yè)界的其它弟兄也在努力，09年這一年出現(xiàn)了非常多的NOSQL數(shù)據(jù)庫，更準(zhǔn)確的應(yīng)該說是No relation數(shù)據(jù)庫，這些數(shù)據(jù)庫多數(shù)都會對非結(jié)構(gòu)化的數(shù)據(jù)提供透明的水平擴(kuò)張能力，大大減輕了哥們兒設(shè)計(jì)時(shí)候的壓力。下面我就拿Hbase這分布式列存儲系統(tǒng)來說說。
在說Hase是個(gè)啥家伙之前，首先我們來看看兩個(gè)概念，面向行存儲和面向列存儲。面向行存儲，我相信大伙兒應(yīng)該都清楚，我們熟悉的RDBMS就是此種類型的，面向行存儲的數(shù)據(jù)庫主要適合于事務(wù)性要求嚴(yán)格場合，或者說面向行存儲的存儲系統(tǒng)適合OLTP，但是根據(jù)CAP理論，傳統(tǒng)的RDBMS，為了實(shí)現(xiàn)強(qiáng)一致性，通過嚴(yán)格的ACID事務(wù)來進(jìn)行同步，這就造成了系統(tǒng)的可用性和伸縮性方面大大折扣，而目前的很多NOSQL產(chǎn)品，包括Hbase，它們都是一種最終一致性的系統(tǒng)，它們?yōu)榱烁叩目捎眯誀奚艘徊糠值囊恢滦?。好像，我上面說了面向列存儲，那么到底什么是面向列存儲呢？Hbase,Casandra,Bigtable都屬于面向列存儲的分布式存儲系統(tǒng)?？吹竭@里，如果您不明白Hbase是個(gè)啥東東，不要緊，我再總結(jié)一下下： Hbase是一個(gè)面向列存儲的分布式存儲系統(tǒng)，它的優(yōu)點(diǎn)在于可以實(shí)現(xiàn)高性能的并發(fā)讀寫操作，同時(shí)Hbase還會對數(shù)據(jù)進(jìn)行透明的切分，這樣就使得存儲本身具有了水平伸縮性。 HBase,Cassandra的數(shù)據(jù)模型非常類似，他們的思想都是來源于Google的Bigtable，因此這三者的數(shù)據(jù)模型非常類似，唯一不同的就是Cassandra具有Super cloumn family的概念，而Hbase目前我沒發(fā)現(xiàn)。好了，廢話少說，我們來看看Hbase的數(shù)據(jù)模型到底是個(gè)啥東東。 在Hbase里面有以下兩個(gè)主要的概念，Row key,Column Family，我們首先來看看Column family,Column family中文又名“列族”，Column family是在系統(tǒng)啟動之前預(yù)先定義好的，每一個(gè)Column Family都可以根據(jù)“限定符”有多個(gè)column.下面我們來舉個(gè)例子就會非常的清晰了。 假如系統(tǒng)中有一個(gè)User表，如果按照傳統(tǒng)的RDBMS的話，User表中的列是固定的，比如schema 定義了name,age,sex等屬性，User的屬性是不能動態(tài)增加的。但是如果采用列存儲系統(tǒng)，比如Hbase，那么我們可以定義User表，然后定義info 列族，User的數(shù)據(jù)可以分為：info:name = zhangsan,info:age=30,info:sex=male等，如果后來你又想增加另外的屬性，這樣很方便只需要info:newProperty就可以了。 也許前面的這個(gè)例子還不夠清晰，我們再舉個(gè)例子來解釋一下，熟悉SNS的朋友，應(yīng)該都知道有好友Feed，一般設(shè)計(jì)Feed，我們都是按照“某人在某時(shí)做了標(biāo)題為某某的事情”，但是同時(shí)一般我們也會預(yù)留一下關(guān)鍵字，比如有時(shí)候feed也許需要url，feed需要image屬性等，這樣來說，feed本身的屬性是不確定的，因此如果采用傳統(tǒng)的關(guān)系數(shù)據(jù)庫將非常麻煩，況且關(guān)系數(shù)據(jù)庫會造成一些為null的單元浪費(fèi)，而列存儲就不會出現(xiàn)這個(gè)問題，在Hbase里，如果每一個(gè)column 單元沒有值，那么是占用空間的。下面我們通過兩張圖來形象的表示這種關(guān)系： 上圖是傳統(tǒng)的RDBMS設(shè)計(jì)的Feed表，我們可以看出feed有多少列是固定的，不能增加，并且為null的列浪費(fèi)了空間。但是我們再看看下圖，下圖為Hbase，Cassandra,Bigtable的數(shù)據(jù)模型圖，從下圖可以看出，Feed表的列可以動態(tài)的增加，并且為空的列是不存儲的，這就大大節(jié)約了空間，關(guān)鍵是Feed這東西隨著系統(tǒng)的運(yùn)行，各種各樣的Feed會出現(xiàn)，我們事先沒辦法預(yù)測有多少種Feed，那么我們也就沒有辦法確定Feed表有多少列，因此Hbase,Cassandra,Bigtable的基于列存儲的數(shù)據(jù)模型就非常適合此場景。說到這里，采用Hbase的這種方式，還有一個(gè)非常重要的好處就是Feed會自動切分，當(dāng)Feed表中的數(shù)據(jù)超過某一個(gè)閥值以后，Hbase會自動為我們切分?jǐn)?shù)據(jù)，這樣的話，查詢就具有了伸縮性，而再加上Hbase的弱事務(wù)性的特性，對Hbase的寫入操作也將變得非?？?。 上面說了Column family，那么我之前說的Row key是啥東東，其實(shí)你可以理解row key為RDBMS中的某一個(gè)行的主鍵，但是因?yàn)?/span>Hbase不支持條件查詢以及Order by等查詢，因此Row key的設(shè)計(jì)就要根據(jù)你系統(tǒng)的查詢需求來設(shè)計(jì)了額。我還拿剛才那個(gè)Feed的列子來說，我們一般是查詢某個(gè)人最新的一些Feed，因此我們Feed的Row key可以有以下三個(gè)部分構(gòu)成<userId><timestamp><feedId>，這樣以來當(dāng)我們要查詢某個(gè)人的最進(jìn)的Feed就可以指定Start Rowkey為<userId><0><0>，End Rowkey為<userId><Long.MAX_VALUE><Long.MAX_VALUE>來查詢了，同時(shí)因?yàn)?/span>Hbase中的記錄是按照rowkey來排序的，這樣就使得查詢變得非?？?。
1 列的可以動態(tài)增加，并且列為空就不存儲數(shù)據(jù),節(jié)省存儲空間. 2 Hbase自動切分?jǐn)?shù)據(jù)，使得數(shù)據(jù)存儲自動具有水平scalability. 3 Hbase可以提供高并發(fā)讀寫操作的支持 Hbase的缺點(diǎn)： 1 不能支持條件查詢，只支持按照Row key來查詢. 2 暫時(shí)不能支持Master server的故障切換,當(dāng)Master宕機(jī)后,整個(gè)存儲系統(tǒng)就會掛掉. 關(guān)于數(shù)據(jù)庫伸縮性的一點(diǎn)資料： http://www./archives/2009/02/12/database-sharding-at-netlog-with-mysql-and-php/ http://adam.blog./past/2009/7/6/sql_databases_dont_scale/ 暫時(shí)先分享這么多,以后在項(xiàng)目運(yùn)用中,遇到問題再分享給大家. |
|
|
