我的廢話1:
任何一項新技術並非救命稻草，一抹一擦立馬藥到病除的百寶箱，並非使用Spring或者NOSQL的產品就神乎其神+五光十色，如果那樣基本是扯淡。同類 型產品中不管那種技術最終要達到的目的是一樣的，通過新的技術手段你往往可能避諱了當前你所需要面對的問題，但過後新的問題又來了。也許回過頭來看看還不 如在原來的基礎上多動動腦筋 想想辦法 做些改良可以得到更高的回報。
傳統數據庫是以數據塊來存儲數據，簡單來說，你的表字段越多，佔用的數據空間就越多，那麼查詢有可能就要跨數據塊，將會導致查詢的速度變慢。在大型系統中一張表上百個字段，並且表中的數據上億條這是完全是有可能的。因此會帶來數據庫查詢的瓶頸。我們都知道一個常識數據庫中表記錄的多少對查詢的性能有非常大的影響，此時你很有可能想到分表、分庫的做法來分載數據庫運算的壓力，那麼又會帶來新的問題，例如：分佈式事務、全局唯一ID的生成、跨數據庫查詢 等，依舊會讓你面對棘手的問題。如果打破這種按照行存儲的模式，採用一種基於列存儲的模式，對於大規模數據場景這樣情況有可能發生一些好轉。由於查詢中的選擇規則是通過列來定義的，因此整個數據庫是自動索引化的。按列存儲每個字段的數據聚集存儲， 可以動態增加，並且列爲空就不存儲數據，節省存儲空間。 每個字段的數據按照聚集存儲，能大大減少讀取的數據量，查詢時指哪打哪，來的更直接。無需考慮分庫、分表 Hbase將對存儲的數據自動切分數據，並支持高併發讀寫操作，使得海量數據存儲自動具有更強的擴展性。
Java中的HashMap是Key/Value的結構，你也可以把HBase的數據結構看做是一個Key/Value的體系,話說HBase的區域由表名和行界定的。在HBase區域每一個"列族"都由一個名爲HStore的對象管理。每個HStore由一個或多個MapFiles(Hadoop中的一個文件類型)組成。MapFiles的概念類似於Google的SSTable。 在Hbase裏面有以下兩個主要的概念，Row key 和 Column Family，其次是Cell qualifier和Timestamp tuple，Column family我們通常稱之爲“列族”，訪問控制、磁盤和內存的使用統計都是在列族層面進行的。列族Column family是之前預先定義好的數據模型，每一個Column Family都可以根據“限定符”有多個column。在HBase每個cell存儲單元對同一份數據有多個版本，根據唯一的時間戳來區分每個版本之間的差異，最新的數據版本排在最前面 。
口水：Hbase將table水平劃分成N個Region，region按column family劃分成Store，每個store包括內存中的memstore和持久化到disk上的HFile。
上述可能我表達的還不夠到位，下面來看一個實踐中的場景，將原來是存放在MySQL中Blog中的數據遷移到HBase中的過程：
MySQL中現有的表結構：
遷移HBase中的表結構：
原來系統中有2張表blogtable和comment表，採用HBase後只有一張blogtable表，如果按照傳統的RDBMS的話，blogtable表中的列是固定的，比如schema 定義了Author,Title,URL,text等屬性，上線後表字段是不能動態增加的。但是如果採用列存儲系統，比如Hbase，那麼我們可以定義blogtable表，然後定義info 列族，User的數據可以分爲：info:title ,info:author ,info:url 等，如果後來你又想增加另外的屬性，這樣很方便只需要
info:xxx 就可以了。
對於Row key你可以理解row key爲傳統RDBMS中的某一個行的主鍵，Hbase是不支持條件查詢以及Order by等查詢，因此Row key的設計就要根據你係統的查詢需求來設計了額。 Hbase中的記錄是按照rowkey來排序的，這樣就使得查詢變得非常快。
具體操作過程如下：
============================創建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的數據查詢\讀取，可以通過單個row key訪問，row key的range和全表掃描,大致如下：
注意：HBase不能支持where條件、Order by 查詢，只支持按照Row key來查詢，但是可以通過HBase提供的API進行條件過濾。
例如：http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/ColumnPrefixFilter.html
scan 'blogtable' ,{COLUMNS => ['text:','info:title'] } —> 列出 文章的內容和標題
scan 'blogtable' , {COLUMNS => 'info:url' , STARTROW => '2'} —> 根據範圍列出 文章的內容和標題
get 'blogtable','1' —> 列出 文章id 等於1的數據
get 'blogtable','1', {COLUMN => 'info'} —> 列出 文章id 等於1 的 info 的頭(Head)內容
get 'blogtable','1', {COLUMN => 'text'} —> 列出 文章id 等於1 的 text 的具體(Body)內容
get 'blogtable','1', {COLUMN => ['text','info:author']} —> 列出 文章id 等於1 的內容和作者(Body/Author)內容
我的廢話2:
有人會問Java Web服務器中是Tomcat快還是GlassFish快？小型數據庫中是MySQL效率高還是MS-SQL效率高？我看是關鍵用在什麼場景和怎麼使用這 個產品(技術)，所以我漸漸的認爲是需要對產品、技術本身深入的瞭解，而並非一項新的技術就是絕佳的選擇。試問：Tomcat的默認的運行參數能和我們線 上正在使用的GlassFish性能相提並論嗎？我不相信GlassFishv2和GlassFishv3在默認的配置參數下有顯著的差別。我們需要對產 品本身做到深入的瞭解才能發揮他最高的性能，而並非感觀聽從廠家的廣告和自己的感性認識
迷信哪個產品的優越性。
我的廢話3:
對於NOSQL這樣的新技術，的的確確是可以解決過去我們所需要面對的問題，但也並非適合每個應用場景，所以在使用新產品的同時需要切合當前的產品需要， 是需求在引導新技術的投入，而並非爲了趕時髦去使用他。你的產品是否過硬不是你使用了什麼新技術，用戶關心的是速度和穩定性，不會關心你是否使用了 NOSQL。相反Google有着超大的數據量，能給全世界用戶帶來了驚人的速度和準確性，大家纔會回過頭來好奇Google到底是怎麼做到的。所以根據 自己的需要千萬別太勉強自己使用了某項新技術。
我的廢話4:
總之一句話，用什麼不是最關鍵，最關鍵是怎麼去使用！