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

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

圖一

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

但是隨著業務的發展，查詢條件越來越複雜，需要更多的索引欄位，且很多值都不存在，如下圖：

圖二

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

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

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

圖三

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

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

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

圖四

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

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

       接下來是對列族2擴充套件，列族2儲存更多的列，用來做各種刷選、計算處理。如下圖：

圖五

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