2006年google技術人員Fay Chang發佈了一篇文章《Bigtable: A Distributed Storage System for Structured Data》。 該文章向世人介紹了一種分散式的資料庫， 這種資料庫可以在局部幾台伺服器崩潰的情況下繼續提供高性能的服務。
2007年Powerset 公司的工作人員基於此文研發了bigtable的java開源版本， 即HBase。 剛開始它只是Hadoop的一部分。
2008年HBase成為了Apache的頂級項目。 HBase幾乎實現了bigtable的所有特性。 它被稱為一個 開源的非關聯式分散式資料庫 。
2010年HBase的開發速度打破一直以來跟Hadoop版本一致的慣例， 因為HBase的版本發佈速度已經超越了Hadoop。 它的版本號一下從0.20.x 跳躍到了 0.89.x。
為什麼要用HBase
HBase的存儲是基於Hadoop的。 Hadoop 是這些年崛起的擁有著高性能， 高穩定， 可管理的大資料應用平臺。 Hadoop已經快要變為大資料的代名詞了， 基於Hadoop衍生出了大量優秀的開源專案。
Hadoop實現了一個分散式檔案系統HDFS。 HDFS有高容錯性的特點， 被設計用來部署在低廉的硬體上;而且它提供高輸送量以訪問應用程式的資料， 適合那些有著超大資料集的應用程式。
HBase採用的是Key/Value的存儲方式， 這意味著， 即使隨著資料量增大， 也幾乎不會導致查詢的性能下降。 HBase又是一個列式資料庫(對比于傳統的行式資料庫而言)， 當你的表字段很多的時候， 你甚至可以把其中幾個欄位放在集群的一部分機器上， 而另外幾個欄位放到另外一部分機器上， 充分分散了負載壓力。 然而， 如此複雜的存儲結構和分散式的存儲方式帶來的代價就是：哪怕只是存儲少量資料， 它也不會很快。 所以我常常跟人說：
“HBase並不快， 只是當資料量很大的時候它慢的不明顯”
凡事都不可能只有優點而沒有缺點。 資料分析是HBase的弱項， 因為對於HBase乃至整個NoSQL生態圈來說，
因此， 請不要盲目地使用HBase。
當你的情況大體上符合以下任意一種的時候：
主要需求是資料分析， 比如做報表。
單表資料量不超過千萬。
請不要使用HBase， 使用Mysql或者Oracle之類的產品可以讓你的腦細胞免受折磨。
當你的情況是：
單表資料量超千萬， 而且併發還挺高。
資料分析需求較弱， 或者不需要那麼靈活或者即時。
請使用HBase， 它不會讓你失望的。