關係型數據庫與HBase的數據儲存方式差異

       如今Bigtable型(列族)數據庫應用愈來愈廣，功能也很是強大。

但是很是多人仍是把它當作關係型數據庫在使用，用原來關係型數據庫的思惟建表、存儲、查詢。

本文以hbase舉例講述數據模式的變化。

傳統關係型數據庫(mysql，oracle)數據存儲方式主要例如如下：

圖一

       上圖是個很是典型的數據儲存方式。我把每條記錄分紅3部分:主鍵、記錄屬性、索引字段。咱們會對索引字段創建索引，達到二級索引的效果。

但是隨着業務的發展。查詢條件愈來愈複雜，需要不少其它的索引字段，且很是多值都不存在，例如如下圖：

圖二

       上圖是6個索引字段。實際狀況多是上百個甚至不少其它，並且還需要依據多個索引字段刷選。

查詢性能愈來愈低，甚至沒法知足查詢要求。關係型數據裏的侷限也開始顯現。因而很是多人開始接觸NoSQL。

       列族數據庫很是強大。很是多人就想把數據從mysql遷到hbase，存儲的方式仍是跟圖一或者圖二同樣，主鍵爲rowkey。其它各個字段的數據。存儲一個列族下的不一樣列。

但是想對索引字段查詢就沒有辦法，眼下尚未比較好的基於bigtable的二級索引方案，因此沒法對索引字段作查詢。

      這時候事實上可以轉換下思惟。可以把數據倒過來，例如如下圖：

圖三

        把各個索引字段的值做爲rowkey，而後把記錄的主鍵和屬性值依照必定順序存在相應rowkey的value裏。上圖僅僅有一個列族。是最簡單的方式。 Value裏的記錄可以設置成定長的byte[]，多個記錄集合經過移位高速查詢到。

        但是上面僅僅適合單個索引字段的查詢。假設要同一時候對多個索引字段查詢，圖三的方式需要求取出所有value值，比方查詢「浙江」and「手機」。需要取出兩個value，再解析出各自的主鍵求交。假設每條記錄的屬性有上百個，對性能影響很是大。

       接下來的變化是解決多索引字段查詢的問題。咱們將主鍵字段和屬性字段分開存儲，儲存在不一樣的列族下，多索引查詢僅僅需要取出列族1下的數據，再去最小集合的列族2裏取得想要的值。儲存如圖四：

圖四

爲何是不一樣列族，而不是一個列族下的兩個列？

        列族數據庫數據文件是依照列族分的。

在取數據時，都會把一個列族的所有列數據都取出來。其實咱們並不需要把記錄明細取出來。因此把這部分數據放到了還有一個列族下。

       接下來是對列族2擴展。列族2儲存不少其它的列，用來作各類刷選、計算處理。例如如下圖：

圖五

       後來我感受這玩樣愈來愈像搜索了。。。