前言

最近學習了hbase，其中涉及的到知識就是hbase採用了列式存貯，而用慣了mysql的我當然一臉懵逼，於是有了本篇文章，本文不是論文，所有涉及的知識點他人都有講，我只是為了記錄一下，如果想要看論文性質的，推薦一篇為《Column-Stores vs. Row-Stores: How Different Are They Really?》，可以自行觀看，其中有大量的測試，分析，十分詳盡。

存貯資料的方式

第一個對比的就是存貯資料的方式。

現來說行式。比如mysql，我們通過觀察知道，他是一行一行的存貯的。為了說明這個問題，我們畫個圖，草圖。

從這個圖我們看出，每一行都有id,name,age,sex屬性，每一行的所有屬性連貫起來存貯起來。即使某一個行某一個欄位為空，也會佔用一個存貯位置。每一個畫綠線的部分裡面的資料都被串起來存貯了。比如在北方，蒜這種東西都是被繩子串起來來的，那你現在就可以想象每個繩子串起來的蒜都有id，name,age,sex這四頭蒜。

然後再來看列式存貯。畫個草圖，嗯，是的，很草很草的圖。

看上圖，這就是列式存貯，發現沒有，他是一列都是同一個屬性的，是的，看圖說話，我感覺已經很明白了哦。再來說到蒜，那麼你現在就可以想象每個繩子上的蒜都是同一種，比如這條繩子上的蒜全是id,另外一條繩子上的蒜都是name，以此類推。

是不是很明白的樣子。

查詢方面的對比

第二個對比的就是查詢方面。

先來說行式資料庫，通過上面我們知道資料是一行一行的存貯起來的，我們如果想要查詢，那麼就會一行行的掃描，從而得到我們的資料。還用上面的例子，假定我們只想要name這一行的資料，我們是不是查詢的時候也必須把其他的資料順便給查出來了，因為他們是一起的。那我們就知道了，即使我們只想要一行的資料，也得整行掃描，多的那些資料都是磁碟IO，不得不需要加上額外的不需要的資料。

然後再來說列式資料庫，通過上面我們也知道了列式資料庫式按照一列一列來存貯的。再來看上面的那個查詢問題，我們依舊只想要name這一列，這個時候我們就只需要把這一列查詢出來就行了，其他的沒有關係的我們也不關心，是不是瞬間就減少了資料量呀，這個優點尤其是在海量資料的時候尤其明顯，查詢速度秒殺行式資料庫。

接著我們再返回行式資料庫想一下，比如mysql在做查詢優化的時候，最常用的手段就是建立索引，可是我們想一想，資料量一旦大的時候，索引也會成倍的增長。

而列式資料庫則不然，他的每一列就是索引，減少了額外建立索引的內容。

當然了，如果我們的需求就是查詢所有欄位，那個這個時候列式資料庫的處理方式就是先把所有列查詢出來，然後再拼接起來，速度方面是比不上行式資料庫的。不過我們既然用到了列式資料庫，那麼我們的場景需求就是大量資料，一般在大資料領域，進行所有欄位的查詢的這個要求少之又少，所以這個缺點我們需要正式，但是我們也可以忽略。

壓縮比較

行式資料庫因為存貯資料是一行行的來存貯，而每一行資料的差異性太大，所以壓縮比很小。列式資料庫則不同，因為是按照一列列來存貯，每一列的資料的相同性極高，這就為壓縮埋下了很好的種子，壓縮比可以達到很大，可以達到5～20倍以上。

接下來看一下網上的一個圖來說明問題。

我認為這個壓縮比是這種列式存貯在面對海量資料存貯查詢的時候靈魂。因為擁有超高的壓縮比，在磁碟iO傳輸的時候，據統計可以達到行式的100倍以上。

當然了，擁有超高的壓縮比，另外一方面可以減少磁碟的使用率，不過在現在這個硬碟不值錢的年代，這個優點也不是啥大優點了，最重要的還是在磁碟IO的傳輸上。

應用場景比較

行式資料庫主要應用於傳統的業務場景中

列式資料庫則應該發揮他查詢速度方面的優勢，主要用於海量資料分析一類的方面。

總結

以上就是本文全部的內容了，如果讀者有補充，也歡迎在下方留言，與幾方便也與他方便，共同進步咯。