我的廢話1: 任何一項新技術(shù)并非救命稻草，一抹一擦立馬藥到病除的百寶箱，并非使用Spring或者NOSQL的產(chǎn)品就神乎其神+五光十色，如果那樣基本是扯淡。同類 型產(chǎn)品中不管那種技術(shù)最終要達(dá)到的目的是一樣的，通過新的技術(shù)手段你往往可能避諱了當(dāng)前你所需要面對

我的廢話1:
?? 任何一項新技術(shù)并非救命稻草，一抹一擦立馬藥到病除的百寶箱，并非使用Spring或者NOSQL的產(chǎn)品就神乎其神+五光十色，如果那樣基本是扯淡。同類 型產(chǎn)品中不管那種技術(shù)最終要達(dá)到的目的是一樣的，通過新的技術(shù)手段你往往可能避諱了當(dāng)前你所需要面對的問題，但過后新的問題又來了。也許回過頭來看看還不 如在原來的基礎(chǔ)上多動動腦筋 想想辦法 做些改良可以得到更高的回報。??
?

?? 傳統(tǒng)數(shù)據(jù)庫是以數(shù)據(jù)塊來存儲數(shù)據(jù)，簡單來說，你的表字段越多，占用的數(shù)據(jù)空間就越多，那么查詢有可能就要跨數(shù)據(jù)塊，將會導(dǎo)致查詢的速度變慢。在大型系統(tǒng)中一張表上百個字段，并且表中的數(shù)據(jù)上億條這是完全是有可能的。因此會帶來數(shù)據(jù)庫查詢的瓶頸。我們都知道一個常識數(shù)據(jù)庫中表記錄的多少對查詢的性能有非常大的影響，此時你很有可能想到分表、分庫的做法來分載數(shù)據(jù)庫運(yùn)算的壓力，那么又會帶來新的問題，例如：分布式事務(wù)、全局唯一ID的生成、跨數(shù)據(jù)庫查詢 等，依舊會讓你面對棘手的問題。如果打破這種按照行存儲的模式，采用一種基于列存儲的模式，對于大規(guī)模數(shù)據(jù)場景這樣情況有可能發(fā)生一些好轉(zhuǎn)。由于查詢中的選擇規(guī)則是通過列來定義的，因此整個數(shù)據(jù)庫是自動索引化的。按列存儲每個字段的數(shù)據(jù)聚集存儲， 可以動態(tài)增加，并且列為空就不存儲數(shù)據(jù)，節(jié)省存儲空間。 每個字段的數(shù)據(jù)按照聚集存儲，能大大減少讀取的數(shù)據(jù)量，查詢時指哪打哪，來的更直接。無需考慮分庫、分表 Hbase將對存儲的數(shù)據(jù)自動切分?jǐn)?shù)據(jù)，并支持高并發(fā)讀寫操作，使得海量數(shù)據(jù)存儲自動具有更強(qiáng)的擴(kuò)展性。

?? Java中的HashMap是Key/Value的結(jié)構(gòu)，你也可以把HBase的數(shù)據(jù)結(jié)構(gòu)看做是一個Key/Value的體系,話說HBase的區(qū)域由表名和行界定的。在HBase區(qū)域每一個"列族"都由一個名為HStore的對象管理。每個HStore由一個或多個MapFiles(Hadoop中的一個文件類型)組成。MapFiles的概念類似于Google的SSTable。 在Hbase里面有以下兩個主要的概念，Row key 和 Column Family，其次是Cell qualifier和Timestamp tuple，Column family我們通常稱之為“列族”，訪問控制、磁盤和內(nèi)存的使用統(tǒng)計都是在列族層面進(jìn)行的。列族Column family是之前預(yù)先定義好的數(shù)據(jù)模型，每一個Column Family都可以根據(jù)“限定符”有多個column。在HBase每個cell存儲單元對同一份數(shù)據(jù)有多個版本，根據(jù)唯一的時間戳來區(qū)分每個版本之間的差異，最新的數(shù)據(jù)版本排在最前面 。

口水：Hbase將table水平劃分成N個Region，region按column family劃分成Store，每個store包括內(nèi)存中的memstore和持久化到disk上的HFile。

上述可能我表達(dá)的還不夠到位，下面來看一個實踐中的場景，將原來是存放在MySQL中Blog中的數(shù)據(jù)遷移到HBase中的過程：
MySQL中現(xiàn)有的表結(jié)構(gòu)：

遷移HBase中的表結(jié)構(gòu)：

原來系統(tǒng)中有2張表blogtable和comment表，采用HBase后只有一張blogtable表，如果按照傳統(tǒng)的RDBMS的話，blogtable表中的列是固定的，比如schema 定義了Author,Title,URL,text等屬性，上線后表字段是不能動態(tài)增加的。但是如果采用列存儲系統(tǒng)，比如Hbase，那么我們可以定義blogtable表，然后定義info 列族，User的數(shù)據(jù)可以分為：info:title? ,info:author ,info:url 等，如果后來你又想增加另外的屬性，這樣很方便只需要 info:xxx 就可以了。
對于Row key你可以理解row key為傳統(tǒng)RDBMS中的某一個行的主鍵，Hbase是不支持條件查詢以及Order by等查詢，因此Row key的設(shè)計就要根據(jù)你系統(tǒng)的查詢需求來設(shè)計了額。 Hbase中的記錄是按照rowkey來排序的，這樣就使得查詢變得非?？?。

具體操作過程如下：
============================創(chuàng)建blogtable表=========================
create 'blogtable', 'info','text','comment_title','comment_author','comment_text'
?
============================插入概要信息=========================
put 'blogtable', '1', 'info:title', 'this is doc title'
put 'blogtable', '1', 'info:author', 'javabloger'
put 'blogtable', '1', 'info:url', 'http://www.javabloger.com/index.php'

put 'blogtable', '2', 'info:title', 'this is doc title2'
put 'blogtable', '2', 'info:author', 'H.E.'
put 'blogtable', '2', 'info:url', 'http://www.javabloger.com/index.html'

============================插入正文信息=========================
put 'blogtable', '1', 'text:', 'what is this doc context ?'
put 'blogtable', '2', 'text:', 'what is this doc context2?'

==========================插入評論信息===============================
put 'blogtable', '1', 'comment_title:', 'this is doc comment_title '
put 'blogtable', '1', 'comment_author:', 'javabloger'
put 'blogtable', '1', 'comment_text:', 'this is nice doc'

put 'blogtable', '2', 'comment_title:', 'this is blog comment_title '
put 'blogtable', '2', 'comment_author:', 'H.E.'
put 'blogtable', '2', 'comment_text:', 'this is nice blog'

HBase的數(shù)據(jù)查詢\讀取，可以通過單個row key訪問，row key的range和全表掃描,大致如下：
注意：HBase不能支持where條件、Order by 查詢，只支持按照Row key來查詢，但是可以通過HBase提供的API進(jìn)行條件過濾。
例如：http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/ColumnPrefixFilter.html

scan 'blogtable' ,{COLUMNS => ['text:','info:title'] }? —> 列出 文章的內(nèi)容和標(biāo)題

scan 'blogtable' , {COLUMNS => 'info:url' , STARTROW => '2'}??? —> 根據(jù)范圍列出 文章的內(nèi)容和標(biāo)題

get 'blogtable','1'??? —> 列出 文章id 等于1的數(shù)據(jù)

get 'blogtable','1', {COLUMN => 'info'}??? —> 列出 文章id 等于1 的 info 的頭(Head)內(nèi)容

get 'blogtable','1', {COLUMN => 'text'}?? —> 列出 文章id 等于1 的 text? 的具體(Body)內(nèi)容

get 'blogtable','1', {COLUMN => ['text','info:author']}? —> 列出 文章id 等于1 的內(nèi)容和作者(Body/Author)內(nèi)容

我的廢話2:
?? 有人會問Java Web服務(wù)器中是Tomcat快還是GlassFish快？小型數(shù)據(jù)庫中是MySQL效率高還是MS-SQL效率高？我看是關(guān)鍵用在什么場景和怎么使用這 個產(chǎn)品(技術(shù))，所以我漸漸的認(rèn)為是需要對產(chǎn)品、技術(shù)本身深入的了解，而并非一項新的技術(shù)就是絕佳的選擇。試問：Tomcat的默認(rèn)的運(yùn)行參數(shù)能和我們線 上正在使用的GlassFish性能相提并論嗎？我不相信GlassFishv2和GlassFishv3在默認(rèn)的配置參數(shù)下有顯著的差別。我們需要對產(chǎn) 品本身做到深入的了解才能發(fā)揮他最高的性能，而并非感觀聽從廠家的廣告和自己的感性認(rèn)識 迷信哪個產(chǎn)品的優(yōu)越性。

我的廢話3:
? 對于NOSQL這樣的新技術(shù)，的的確確是可以解決過去我們所需要面對的問題，但也并非適合每個應(yīng)用場景，所以在使用新產(chǎn)品的同時需要切合當(dāng)前的產(chǎn)品需要， 是需求在引導(dǎo)新技術(shù)的投入，而并非為了趕時髦去使用他。你的產(chǎn)品是否過硬不是你使用了什么新技術(shù)，用戶關(guān)心的是速度和穩(wěn)定性，不會關(guān)心你是否使用了 NOSQL。相反Google有著超大的數(shù)據(jù)量，能給全世界用戶帶來了驚人的速度和準(zhǔn)確性，大家才會回過頭來好奇Google到底是怎么做到的。所以根據(jù) 自己的需要千萬別太勉強(qiáng)自己使用了某項新技術(shù)。

我的廢話4:
? 總之一句話，用什么不是最關(guān)鍵，最關(guān)鍵是怎么去使用！

?
相關(guān)文章:
Lily-建立在HBase上的分布式搜索
MySQL向Hive/HBase的遷移工具
HBase入門5(集群) -壓力分載與失效轉(zhuǎn)發(fā)
Hive入門3–Hive與HBase的整合
HBase入門篇4
HBase入門篇3
HBase入門篇2-Java操作HBase例子
HBase入門篇
基于Hbase存儲的分布式消息(IM)系統(tǒng)-JABase

–end–

原文地址：Hbase入門6 -白話MySQL(RDBMS)與HBase之間, 感謝原作者分享。