**自董的部落格
相比傳統的行式儲存引擎，列式儲存引擎具有更高的壓縮比，更少的io操作而備受青睞（注：列式儲存不是萬能高效的，很多場景下行式儲存仍更加高效），尤其是在資料列（column）數很多，但每次操作僅針對若干列的情景，列式儲存引擎的價效比更高。
在網際網路大資料應用場景下，大部分情況下，資料量很大且資料字段數目很多，但每次查詢資料只針對其中的少數幾行，這時候列式儲存是極佳的選擇，目前在開源實現中，最有名的列式儲存引擎是parquet和orc，在最近一年內，它們都晉公升為apache頂級專案，可見它們的重要性。本文嘗試比較這兩種儲存引擎。
apache parquet
apache parquet 最初的設計動機是儲存巢狀式資料，比如protocolbuffer，thrift，json等，將這類資料儲存成列式格式，以方便對其高效壓縮和編碼，且使用更少的io操作取出需要的資料，這也是parquet相比於orc的優勢，它能夠透明地將protobuf和thrift型別的資料進行列式儲存，在protobuf和thrift被廣泛使用的今天，與parquet進行整合，是一件非容易和自然的事情。 除了上述優勢外，相比於orc, parquet沒有太多其他可圈可點的地方，比如它不支援update操作（資料寫成後不可修改），不支援acid等。
apache orc
orc（optimizedrc file）儲存源自於rc（recordcolumnar file）這種儲存格式，rc是一種列式儲存引擎，對schema演化（修改schema需要重新生成資料）支援較差，而orc是對rc改進，但它仍對schema演化支援較差，主要是在壓縮編碼，查詢效能方面做了優化。rc/orc最初是在hive中得到使用，最後發展勢頭不錯，獨立成乙個單獨的專案。hive 1.x版本對事務和update操作的支援，便是基於orc實現的（其他儲存格式暫不支援）。orc發展到今天，已經具備一些非常高階的feature，比如支援update操作，支援acid，支援struct，array複雜型別。你可以使用複雜型別構建乙個類似於parquet的巢狀式資料架構，但當層數非常多時，寫起來非常麻煩和複雜，而parquet提供的schema表達方式更容易表示出多級巢狀的資料型別。
parquet與orc對比
總結
列式儲存處理
下面以gbase 8a分析型資料庫為例，描述列儲存對資料儲存與管理的作用。面對海量資料分析的 i o 瓶頸，gbase 8a 把錶資料按列的方式儲存，其優勢體現在以下幾個方面。不讀取無效資料 降低 i o 開銷，同時提高每次 i o 的效率，從而大大提高查詢效能。查詢語句只從磁碟上讀取所需要的列，其...
列式儲存簡介
關係表結構是被人們普遍接受的資料模型，通常一行資料由多個屬性組成，每個屬性是一列。但是磁碟是一維的，檔案只能順序寫，那麼先寫誰後寫誰呢？不同的寫檔案順序就對應了不同的儲存模型。傳統資料庫通常採用行式儲存，即先存一行資料，再存下一行資料。在大資料時代，乙個常見分析型場景是在資料倉儲中進行分析，如商店的...
列式儲存 一
最近做專案，客戶要求物件的屬性能夠動態新增，於是採用了列式儲存。1.傳統關係型資料庫的行式儲存方法為 資料庫表的字段表示物件屬性，一行資料完整的表示物件的所有屬性。如果要新增乙個屬性，如 聯絡郵箱 那麼就要重新設計表，增加一欄 email 相應的後台 也需要變動。2.關係型資料庫的行式儲存方法為 將...