2006年google技術人員Fay Chang發佈了一篇文章《Bigtable: A Distributed Storage System for Structured Data》。該文章向世人介紹了一種分散式的資料庫，這種資料庫可以在局部幾台伺服器崩潰的情況下繼續提供高性能的服務。 2007年P ...
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有高容錯性的特點，被設計用來部署在低廉的硬體上；而且它提供高吞吐量以訪問應用程式的數據，適合那些有著超大數據集的應用程式。基於Hadoop意味著HBase與生俱來的超強的擴展性和吞吐量。
HBase採用的是Key/Value的存儲方式，這意味著，即使隨著數據量增大，也幾乎不會導致查詢的性能下降。HBase又是一個列式資料庫（對比於傳統的行式資料庫而言），當你的表欄位很多的時候，你甚至可以把其中幾個欄位放在集群的一部分機器上，而另外幾個欄位放到另外一部分機器上，充分分散了負載壓力。然而，如此複雜的存儲結構和分散式的存儲方式帶來的代價就是：哪怕只是存儲少量數據，它也不會很快。所以我常常跟人說：
“HBase並不快，只是當數據量很大的時候它慢的不明顯”
凡事都不可能只有優點而沒有缺點。數據分析是HBase的弱項，因為對於HBase乃至整個NoSQL生態圈來說，基本上都是不支持表關聯的。當你想實現group by 或者order by的時候，你會發現，你需要寫很多的代碼來實現MapReduce。
因此，請不要盲目地使用HBase。
當你的情況大體上符合以下任意一種的時候：
- 主要需求是數據分析，比如做報表。
- 單表數據量不超過千萬。
請不要使用HBase，使用Mysql或者Oracle之類的產品可以讓你的腦細胞免受折磨。
當你的情況是：
- 單表數據量超千萬，而且併發還挺高。
- 數據分析需求較弱，或者不需要那麼靈活或者實時。
請使用HBase，它不會讓你失望的。
