行數據庫VS列數據庫
一、介紹
目前大數據存儲有兩種方案可供選擇：行存儲和列存儲。業界對兩種存儲方案有很多爭持，集中焦點是:誰能夠更有效地處理海量數據，且兼顧安全、可靠、完整性。從目前發展情況看，關系數據庫已經不適應這種巨大的存儲量和計算要求，基本是淘汰出局。在已知的幾種大數據處理軟件中，Hadoop的HBase采用列存儲，MongoDB是文檔型的行存儲，Lexst是二進制型的行存儲。
顧名思義，這兩種數據庫架構在存貯數據時的方式是大相徑庭的。在行式數據庫中，每一行中的每一塊數據都是緊挨著另一塊數據存放在硬盤中。一般情況下，你可以認為每一行存貯的內容就是硬盤中的一組連續的字節，像SQL server,Oracle，mysql等傳統的是屬於行式數據庫範疇。如果是基於列的數據庫，所有的數據都是以列的形式存儲的，它從一開始就是面向大數據環境下數據倉庫的數據分析而產生。
行存儲數據排列
列存儲數據排列
行存儲的讀寫過程是一致的，都是從第一列開始，到最後一列結束。列存儲的讀取是列數據集中的一段或者全部數據，寫入時，一行記錄被拆分為多列，每一列數據追加到對應列的末尾處。
從上面表格可以看出，行存儲的寫入是一次完成。如果這種寫入建立在操作系統的文件系統上，可以保證寫入過程的成功或者失敗，數據的完整性因此可以確定。列存儲由於需要把一行記錄拆分成單列保存，寫入次數明顯比行存儲多，再加上磁頭需要在盤片上移動和定位花費的時間，實際時間消耗會更大。所以，行存儲在寫入上占有很大的優勢。
還有數據修改,這實際也是一次寫入過程。不同的是，數據修改是對磁盤上的記錄做刪除標記。行存儲是在指定位置寫入一次，列存儲是將磁盤定位到多個列上分別寫入，這個過程仍是行存儲的列數倍。所以，數據修改也是以行存儲占優。 數據讀取時，行存儲通常將一行數據完全讀出，如果只需要其中幾列數據的情況，就會存在冗余列，出於縮短處理時間的考量，消除冗余列的過程通常是在內存中進行的。列存儲每次讀取的數據是集合的一段或者全部，如果讀取多列時，就需要移動磁頭，再次定位到下一列的位置繼續讀取。 再談兩種存儲的數據分布。由於列存儲的每一列數據類型是同質的，不存在二義性問題。比如說某列數據類型為整型（int），那麽它的數據集合一定是整型數據。這種情況使數據解析變得十分容易。相比之下，行存儲則要復雜得多，因為在一行記錄中保存了多種類型的數據，數據解析需要在多種數據類型之間頻繁轉換，這個操作很消耗CPU，增加了解析的時間。所以，列存儲的解析過程更有利於分析大數據。
顯而易見，兩種存儲格式都有各自的優缺點：行存儲的寫入是一次性完成，消耗的時間比列存儲少，並且能夠保證數據的完整性，缺點是數據讀取過程中會產生冗余數據，如果只有少量數據，此影響可以忽略；數量大可能會影響到數據的處理效率。列存儲在寫入效率、保證數據完整性上都不如行存儲，它的優勢是在讀取過程，不會產生冗余數據，這對數據完整性要求不高的大數據處理領域，比如互聯網，猶為重要。
在選擇使用哪種數據庫時，問自己這樣一個問題，哪種工作負載是你的數據庫需要支持的最關鍵的工作負載。盡管可能你兩種操作都需要，但是當核心業務是在線交易性的OLTP應用時，一個行式的數據庫，再加上數十年積累的優化操作，可能是最好的選擇。如果你的企業並不需要快速處理OLTP業務，但需要可以快速處理海量靜態數據的分析，也就是OLAP時，那麽一個列式的數據庫將會成為你的不二選擇。
三、總結
兩種存儲格式各自的特性都決定了它們不可能是完美的解決方案。 如果首要考慮是數據的完整性和可靠性，那麽行存儲是不二選擇，列存儲只有在增加磁盤並改進軟件設計後才能接近這樣的目標。如果以保存數據為主，行存儲的寫入性能比列存儲高很多。在需要頻繁讀取單列集合數據的應用中，列存儲是最合適的。如果每次讀取多列，兩個方案可酌情選擇：采用行存儲時，設計中應考慮減少或避免冗余列；若采用列存儲方案，為保證讀寫入效率，每列數據盡可能分別保存到不同的磁盤上，多個線程並行讀寫各自的數據，這樣避免了磁盤競用的同時也提高了處理效率。 無論選擇哪種方案，將同內容數據聚湊在一起都是必須的，這是減少磁頭在磁盤上的移動，提高數據讀取時間的有效辦法。
其實這也驗證了我當前在公司所做的系統數據庫為什麽是基於HBase的。因為要對用戶的數據分類，對每一類數據做出對應的產品來提供服務。這個過程有在線上進行，也有在線下進行的，執行的頻率相當的高，用戶數量又十分龐大，雖然在數據的寫入上效率會低，但是更重要的是在數據類別的維度上對大數據進行分析，實時地呈現執行結果渲染頁面呈現。
行數據庫VS列數據庫