關係型資料庫到HBase的資料儲存方式變遷

如今bigtable型(列族)資料庫應用越來越廣，功能也很強大。但是很多人還是把它當做關係型資料庫在使用，用原來關係型資料庫的思維建表、儲存、查詢。本文以hbase舉例講述資料模式的變化。

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

[img]

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

[img]

上圖是6個索引字段，實際情況可能是上百個甚至更多，並且還需要根據多個索引欄位刷選。查詢效能越來越低，甚至無法滿足查詢要求。關係型資料裡的侷限也開始顯現，於是很多人開始接觸nosql。

列族資料庫很強大，很多人就想把資料從mysql遷到hbase，儲存的方式還是跟圖一或者圖二一樣，主鍵為rowkey。其他各個欄位的資料，儲存乙個列族下的不同列。但是想對索引字段查詢就沒有辦法，目前還沒有比較好的基於bigtable的二級索引方案，所以無法對索引欄位做查詢。

這時候其實可以轉換下思維，可以把資料倒過來，如下圖：

[img]

圖三把各個索引欄位的值作為rowkey，然後把記錄的主鍵和屬性值按照一定順序存在對應rowkey的value裡。上圖只有乙個列族，是最簡單的方式。 value裡的記錄可以設定成定長的byte，多個記錄集合通過移位快速查詢到。

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

接下來的變化是解決多索引字段查詢的問題。我們將主鍵欄位和屬性字段分開儲存，儲存在不同的列族下，多索引查詢只需要取出列族1下的資料求交，再去最小集合的列族2裡取得想要的值。儲存如圖四：

[img]

圖四以上圖資料舉例：查詢「浙江」and「手機」：

1、取出「浙江」、「手機」列族1下的資料，即、

2、對資料求交後得到滿足條件，在」手機」(最小集合)下的index為

3、取出「手機」列族二的資料，根據步驟2的index，取出結果

為什麼是不同列族，而不是乙個列族下的兩個列？

列族資料庫資料檔案是按照列族分的。在取資料時，都會把乙個列族的所有列資料都取出來，事實上我們並不需要把記錄明細取出來，所以把這部分資料放到了另乙個列族下。

[img]

後來我感覺這玩樣越來越像搜尋了。。。

這是乙個很典型的通過空間換時間的方案，通過大量資料冗餘來提高查詢效能。同時也帶來了問題，就是資料一致性的問題。所以這種方案的應用場景是對海量歷史資料做實時計算上。關於應用場景可以看我之前寫的一篇文章：實時計算應用場景

而處理實時更新的資料或者經常修改的資料還是難點問題，也歡迎討論或者加入我們團隊一起解決這些難題。

如今bigtable型列族資料庫應用越來越廣，功能也很強大。但是很多人還是把它當做關係型資料庫在使用，用原來關係型資料庫的思維建表儲存查詢。本文以hbase舉例講述資料模式的變化。傳統關係型資料庫 mysql，oracle 資料儲存方式主要如下上圖是個很典型的資料儲存方式，我把每條記錄分成...