HBase學習筆記(一) 基礎入門

2022-07-31 07:18:09 字數 3073 閱讀 3149

hbase的原型是google的bigtable**,受到了該**思想的啟發,目前作為hadoop的子專案來開發維護,用於支援結構化的資料儲存。

hbase是乙個高可靠性、高效能、面向列、可伸縮的分布式儲存系統,利用hbase技術可在廉價pc server上搭建起大規模結構化儲存集群。

hbase的目標是儲存並處理大型的資料,更具體來說是僅需使用普通的硬體配置,就能夠處理由成千上萬的行和列所組成的大型資料。【非大勿用】

hbase是google bigtable的開源實現,但是也有很多不同之處。比如:google bigtable利用gfs作為其檔案儲存系統,hbase利用hadoop hdfs作為其檔案儲存系統;google執行mapreduce來處理bigtable中的海量資料,hbase同樣利用hadoop mapreduce來處理hbase中的海量資料;google bigtable利用chubby作為協同服務,hbase利用zookeeper作為對應。

上面的話太官方,挨個看都認識,連起來不理解。簡單粗暴的總結:就是一款nosql資料庫,面向列儲存,用於儲存處理海量資料。

核心在於它是乙個存資料的地方,可是在此之前學習過了hdfs和mysql,那hbase為什麼還會出現呢?後邊細說~

先說一下mysql,我們都知道mysql是乙個關係型資料庫,平時開發使用的非常頻繁。乙個**或者系統最核心的表就是使用者表,而當使用者表的資料達到幾千萬甚至幾億級別的時候,對單條資料的檢索將會耗費數秒甚至分鐘級別。實際的清空可能更加複雜不堪。

看下邊一張表:

有這麼一張使用者表,假如我要根據id=1查詢出來這條資料對應的使用者姓名,很簡單,會給我們返回zhangsan。但是,當我們查的時候,想一下,查名字的時候age和email會不會被查出來?答案是肯定的,mysql的資料儲存是以行為單位的,面向行儲存。那問題就出現了,我只需要找出zhangsan的名字,卻需要查詢一整行的資料,如果列非常多,那麼查詢效率可想而知了。

查詢的操作速度會受到以下兩個因素的制約:

如果一張表的列過多,會影響查詢效率,我們稱這樣表為寬表。怎麼優化呢,拆開來,豎直拆分:

這樣的情況下,我們要查詢username的時候只需要查詢user_basic表,沒有多餘的字段,查詢效率就會很快。

如果一張表的行過多,會影響查詢效率,我們將這樣的表稱之為高表,可以採用水平拆表的方式提高效率:

這種水平拆分應用比較多的 場景就是日誌表,日誌資訊每天產生很多,可以按月進行水平拆分,這樣就實現了高表變矮

這時候,想到了json格式的字串,這是一種以字串的形式表示的物件,而且屬性字段可以動態拓展,於是有了下邊這種做法,兩種做法加以對比:

ok,這樣儲存資料它不挺好的嘛,hbase出來幹嘛??mysql有一點,資料達到一定的閾值,無論怎麼優化,它都無法達到高效能的發揮。而大資料領域的資料,動輒pb級,這種儲存應用明顯是不能很好的滿足需求的。針對上邊的問題,hbase都有很好的解決方案~~

先不說為什麼用,接著上邊說到的幾個問題:高表寬表,資料列動態擴充套件,把提到的幾個解決辦法:水平垂直切分,列擴充套件方法,雜糅在一起。

有這麼一張表,怕它又寬又高,又會動態擴充套件列,那麼在設計之初,就把這個表給他拆開,為了列的動態拓展,直接儲存json格式:

這樣就解決了寬表問題,高表怎麼辦呢?

乙個表的兩部分,各存一部分行:

解決了高表,寬表,動態擴充套件列的問題~~完美plus~

如果還要進一步提高效能怎麼辦?mysql->redis !!! 快取啊!

查詢出來的資料放入到快取中,下一次查詢直接從快取中拿資料。插入資料怎麼辦呢?也可以這樣理解,我把要插入的資料放進快取中,再也不用管了,直接由資料庫從快取拿資料插入到資料庫。此時程式不需要等待資料插入成功,提高了並行工作的效率。

可是這樣做有了很大的風險,伺服器宕機的話,快取中的資料沒來得及插入到資料庫中,那不就丟資料了嘛。參考redis的持久化策略,可以給插入資料這個操作新增乙個操作日誌,用於持久化插入操作,宕機重啟後從日誌恢復。

這樣設計架構就變成了這個樣子:

上邊這種解決方式,實際上就是hbase實現的大致思路,詳細的內容會在後邊慢慢說。

簡單粗暴總結:hbase就是乙個面向列儲存的非關係型資料庫。兩者的區別主要是:

hbase是的儲存時基於hdfs的,hdfs有著高容錯性的特點,被設計用來部署在低廉的硬體上,而且它提供高吞吐量以訪問應用程式的資料,時候那些有著超大資料集的應用程式。基於hadoop意味著hbase與生俱來的超強的擴充套件性和吞吐量。

hbase採用的時key/value的儲存方式,這意味著,及時隨著資料量的增大,也幾乎不會導致查詢效能的下降。hbase又是乙個面向列儲存的資料庫,當表的字段很多時,可以把其中幾個字段獨立出來放在一部分機器上,而另外幾個字段放到另一部分機器上,充分分散了負載的壓力。如此複雜的儲存結構和分布式的儲存方式,帶來的代價就是:即便是儲存很少的資料,也不會很快。

hbase並不是足夠快,而是資料量很大的時候它慢的不明顯。

什麼時候使用hbase呢,主要是以下兩種情況:

HBase 學習一(基礎入門)

hbase 是乙個分布式的 面向列的開源資料庫,該技術 於 fay chang 所撰寫的 google bigtable 乙個結構化資料的分布式儲存系統 就像 bigtable 利用了 google 檔案系統 file system 所提供的分布式資料儲存一樣,hbase 在 hadoop 之上提供...

HBase學習筆記(一) 《HBase簡介》

hbase簡介 1 hbase表的結構 hbase以表 table 的形式儲存資料 row key 行鍵 與nosql資料庫們一樣,row key是用來檢索記錄的主鍵。row key行鍵 row key 可以是任意字串 最大長度是 64kb,實際應用中長度一般為 10 100bytes 在hbase...

Python學習筆記(一)基礎入門

給大家推薦mooc上北理工嵩天老師講的python課。1.用縮進來區分模組,所以嚴格注意空格和tab。2.一般用新行作為語句結束。但是可用 分為多行顯示 有,可以不需要連線符 4.python可以在同一行中使用多條語句,語句之間使用分號 分割 5.print 預設輸出是換行的,如果要實現不換行需要在...