目前大資料儲存有兩種方案可供選擇：行儲存和列儲存。業界對兩種儲存方案有很多爭持，集中焦點是:誰能夠更有效地處理海量資料，且兼顧安全、可靠、完整性。從目前發展情況看，關聯式資料庫已經不適應這種巨大的儲存量和計算要求，基本是淘汰出局。在已知的幾種大資料處理軟體中，hadoop的hbase採用列儲存，mongodb是文件型的行儲存，lexst是二進位制型的行儲存。在這裡，我不討論這些軟體的技術和優缺點，只圍繞機械磁碟的物理特質，分析行儲存和列儲存的儲存特點，以及由此產生的一些問題和解決辦法。
一.結構布局
行儲存資料排列
列儲存資料排列
**的灰色背景部分表示行列結構，白色背景部分表示資料的物理分布，兩種儲存的資料都是從上至下，從左向右的排列。行是列的組合，行儲存以一行記錄為單位，列儲存以列資料集合單位，或稱列族(column family)。行儲存的讀寫過程是一致的，都是從第一列開始，到最後一列結束。列儲存的讀取是列資料集中的一段或者全部資料，寫入時，一行記錄被拆分為多列，每一列資料追加到對應列的末尾處。
二. 對比
從上面**可以看出，行儲存的寫入是一次完成。如果這種寫入建立在作業系統的檔案系統上，可以保證寫入過程的成功或者失敗，資料的完整性因此可以確定。列儲存由於需要把一行記錄拆分成單列儲存，寫入次數明顯比行儲存多，再加上磁頭需要在碟片上移動和定位花費的時間，實際時間消耗會更大。所以，行儲存在寫入上占有很大的優勢。
還有資料修改,這實際也是一次寫入過程。不同的是，資料修改是對磁碟上的記錄做刪除標記。行儲存是在指定位置寫入一次，列儲存是將磁碟定位到多個列上分別寫入，這個過程仍是行儲存的列數倍。所以，資料修改也是以行儲存佔優。 資料讀取時，行儲存通常將一行資料完全讀出，如果只需要其中幾列資料的情況，就會存在冗餘列，出於縮短處理時間的考量，消除冗餘列的過程通常是在記憶體中進行的。列儲存每次讀取的資料是集合的一段或者全部，如果讀取多列時，就需要移動磁頭，再次定位到下一列的位置繼續讀取。 再談兩種儲存的資料分布。由於列儲存的每一列資料型別是同質的，不存在二義性問題。比如說某列資料型別為整型(int)，那麼它的資料集合一定是整型資料。這種情況使資料解析變得十分容易。相比之下，行儲存則要複雜得多，因為在一行記錄中儲存了多種型別的資料，資料解析需要在多種資料型別之間頻繁轉換，這個操作很消耗cpu，增加了解析的時間。所以，列儲存的解析過程更有利於分析大資料。
三. 優化
顯而易見，兩種儲存格式都有各自的優缺點：行儲存的寫入是一次性完成，消耗的時間比列儲存少，並且能夠保證資料的完整性，缺點是資料讀取過程中會產生冗餘資料，如果只有少量資料，此影響可以忽略;數量大可能會影響到資料的處理效率。列儲存在寫入效率、保證資料完整性上都不如行儲存，它的優勢是在讀取過程，不會產生冗餘資料，這對資料完整性要求不高的大資料處理領域，比如網際網路，猶為重要。
改進集中在兩方面：行儲存讀取過程中避免產生冗餘資料，列儲存提高讀寫效率。
如何改進它們的缺點，並保證優點呢？
行儲存的改進：減少冗餘資料首先是使用者在定義資料時避免冗餘列的產生;其次是優化資料儲存記錄結構，保證從磁碟讀出的資料進入記憶體後，能夠被快速分解，消除冗餘列。要知道，目前市場上即使最低端cpu和記憶體的速度也比機械磁碟快上100-1000倍。如果用上高階的硬體配置，這個處理過程還要更快。
列儲存的兩點改進：1.在計算機上安裝多塊硬碟，以多執行緒並行的方式讀寫它們。多塊硬碟並行工作可以減少磁碟讀寫競用，這種方式對提高處理效率優勢十分明顯。缺點是需要更多的硬碟，這會增加投入成本，在大規模資料處理應用中是不小的數目，運營商需要認真考慮這個問題。2.對寫過程中的資料完整性問題，可考慮在寫入過程中加入類似關聯式資料庫的「回滾」機制，當某一列發生寫入失敗時，此前寫入的資料全部失效，同時加入雜湊碼校驗，進一步保證資料完整性。
這兩種儲存方案還有乙個共同改進的地方：頻繁的小量的資料寫入對磁碟影響很大，更好的解決辦法是將資料在記憶體中暫時儲存並整理，達到一定數量後，一次性寫入磁碟，這樣消耗時間更少一些。目前機械磁碟的寫入速度在20m-50m/秒之間，能夠以批量的方式寫入磁碟，效果也是不錯的。
四. 總結
兩種儲存格式各自的特性都決定了它們不可能是完美的解決方案。 如果首要考慮是資料的完整性和可靠性，那麼行儲存是不二選擇，列儲存只有在增加磁碟並改進軟體設計後才能接近這樣的目標。如果以儲存資料為主，行儲存的寫入效能比列儲存高很多。在需要頻繁讀取單列集合資料的應用中，列儲存是最合適的。如果每次讀取多列，兩個方案可酌情選擇：採用行儲存時，設計中應考慮減少或避免冗餘列;若採用列儲存方案，為保證讀寫入效率，每列資料盡可能分別儲存到不同的磁碟上，多個執行緒並行讀寫各自的資料，這樣避免了磁碟競用的同時也提高了處理效率。 無論選擇哪種方案，將同內容資料聚湊在一起都是必須的，這是減少磁頭在磁碟上的移動，提高資料讀取時間的有效辦法。
袁萌，現就職於國際商用機器(ibm)中國****，主要從事大規模資料產品的設計/開發工作,儲存資料高可用性以及資料生命週期管理，積攢了大量的設計及工作經驗。專注於金融、電信、製造等大型資料中心儲存架構設計。對業界主流的雲儲存產品以及技術有著深刻的認識。
大資料訪問的選擇 行儲存還是列儲存？
上個月參加了乙個 雲儲存的技術討論會。這乙個月裡，陸續收到幾位同學討論 大資料儲存和處理的郵件。今天是週末，索性把這個月的交流內容整理寫下來，供各位參考。目前大資料儲存有兩種方案可供選擇 行儲存和列儲存。業界對兩種儲存方案有很多爭持，集中焦點是 誰能夠更有效地處理海量資料，且兼顧安全 可靠 完整性。...
大資料訪問的選擇 行儲存還是列儲存？
上個月參加了乙個雲儲存的技術討論會。這乙個月裡，陸續收到幾位同學討論大資料儲存和處理的郵件。今天是週末，索性把這個月的交流內容整理寫下來，供各位參考。目前大資料儲存有兩種方案可供選擇 行儲存和列儲存。業界對兩種儲存方案有很多爭持，集中焦點是 誰能夠更有效地處理海量資料，且兼顧安全 可靠 完整性。從目...
大資料訪問的選擇 行儲存還是列儲存？
目前大資料儲存有兩種方案可供選擇 行儲存和列儲存。業界對兩種儲存方案有很多爭持，集中焦點是 誰能夠更有效地處理海量資料，且兼顧安全 可靠 完整性。從目前發展情況看，關聯式資料庫已經不適應這種巨大的儲存量和計算要求，基本是淘汰出局。在已知的幾種大資料處理軟體中，hadoop的hbase採用列儲存，mo...