導讀：在講《Apache Druid 底層儲存設計》時就說過要講一講列式儲存。現在來了，通過本文你可以瞭解到行儲存模式、列儲存模式、它們的優缺點以及列儲存模式的優化等知識。

今日格言：不要侷限於單向思維，多對比了解更多不同維度的東西。

從資料儲存講起

我們最先接觸的資料庫系統，大部分都是行儲存系統。大學的時候學資料庫，老師讓我們將資料庫想象成一張表格，每條資料記錄就是一行資料，每行資料包含若干列。所以我們對大部分資料儲存的思維也就是一個複雜一點的表格管理系統。我們在一行一行地寫入資料，然後按查詢條件查詢過濾出我們想要的行記錄。

大部分傳統的關係型資料庫，都是面向行來組織資料的。如 Mysql，Postgresql。近幾年，也越來越多傳統資料庫加入了列儲存的能力。雖然列儲存的技術在十幾年前就已經出現，卻從來沒有像現在這樣成為一種流行的儲存組織方式。

行儲存和列儲存，是資料庫底層組織資料的方式。（和文件型、K-V 型，時序型等概念不在一個層次）

行儲存

行儲存系統以行的方式來組織資料。假設現在有以下 blog 資料(大學時老師佈置系統課題作業總是讓我們做一個部落格系統，大概因為他們最先接觸的網際網路就是 BBS 吧)：

[
  {
    "title": "Oriented Column Store",
    "author": "Alex",
    "publish_time": 1508423456,
    "like_num": 1024
  },{
    "title": "Apache Druid",
    "author": "Bob",
    "publish_time": 1504423069,
    "like_num": 10
  },{
    "title": "Algorithm",
    "author": "Casey",
    "publish_time": 1512523069,
    "like_num": 16
  }
]
 

行儲存將會以下列方式將資料儲存在磁碟上。我們可以思考一下，這樣的方式利於什麼樣的儲存？（此處停頓 5 秒思考一下）它利於資料一行一行的寫入，寫入一條資料記錄時，只需要將資料追加到已有資料記錄後面即可。

行模式儲存適合 OLTP(Online Transaction Processing)系統。因為資料基於行儲存，所以資料的寫入會更快。對按記錄查詢資料也更簡單。

大部分同學會問，我們的做的系統不就是在為了這個嗎？所以我為什麼還需要列式儲存，而列式儲存又是什麼？

讓我們想象一種場景，現在不是想查詢 Bob 的部落格，我想統計 Bob 發表的部落格數，或是整個系統今天的部落格點贊數。如果是行儲存系統，資料庫將怎樣操作？（停頓思考 10 秒）

如圖，想統計所有點贊數，首先需要將所有行資料讀入記憶體，然後對 like_num 列做 sum 操作，從而得到結果。我們假設磁碟一次可以讀取圖中 3 個方框的資料(實際需要按 byte 來讀取)，那麼這個聚合計算需要 N(N=資料量)次磁碟訪問。

這種經常需要通過大量資料集來聚合統計資料的需求其實是 OLAP 系統的常見行為。基於這個需求我們也可以明白為什麼這幾年列式儲存開始流行。因為資料，大資料，資料分析，也就是 OLAP(Online Analytical Processing)線上分析系統的需求增多了，資料寫入的事務和按記錄查詢資料都不是它的關注點，它關注的是資料過濾，統計。

列儲存

同樣是上面的示例資料，我們來看列式儲存是怎樣組織資料的。

[
  {
    "title": "Oriented Column Store",
    "author": "Alex",
    "publish_time": 1508423456,
    "like_num": 1024
  },{
    "title": "Apache Druid",
    "author": "Bob",
    "publish_time": 1504423069,
    "like_num": 10
  },{
    "title": "Algorithm",
    "author": "Casey",
    "publish_time": 1512523069,
    "like_num": 16
  }
]

如圖所示，列式儲存將每一列的資料組織在一起。可以思考一下這樣利於什麼呢？（停頓 5 秒）

是的，利於對於列的操作，如上面我們說到的統計所有 like_num 之和。其過程將如下：

依然假設磁碟一次可以讀取 3 個方框的資料(實際按 byte 讀取)。可以看出按列儲存組織資料的方式，只需要 1 次磁碟操作就可以完成。

在程式的世界裡，我們學會了，任何的選擇和傾向都是有代價的。空間換時間，時間換空間，一致性可用性相互平衡等。選擇列式儲存必然也有不利的一面。首先就表現在資料寫入上。

當一條新資料到來，需要將每一列儲存到對應的位置。這樣就需要多次寫磁碟操作。（當然真實的資料庫不會出現圖中”擠一擠“、”挪一挪“的情況，資料庫會將不同列資料組織在不同的地方；對於多次寫操作的問題，大部分儲存系統會通過緩衝來降低這種情況帶來的不足）

對比

Row-Store	Column-Store
因為按一行一行寫和讀取資料，因此讀取資料時往往需要讀取那些不必要的列	可以只讀取必要的列
易於按記錄讀寫資料	對一個一個記錄的資料寫入和讀取都較慢
適合 OLTP 系統	適合 OLAP 系統
不利於大資料集的聚合統計操作	利於大資料集的資料聚合操作
不利於壓縮資料	利於壓縮資料

列儲存優勢

基於列模式的儲存，天然就會具備以下幾個優點：

• 自動索引

  因為基於列儲存，所以每一列本身就相當於索引。所以在做一些需要索引的操作時，就不需要額外的資料結構來為此列建立合適的索引。

• 利於資料壓縮

  利於壓縮有兩個原因。一來你會發現大部分列資料基數其實是重複的，拿上面的資料來說，因為同一個 author 會發表多篇部落格，所以 author 列出現的所有值的基數肯定是小於部落格數量的，因此在 author 列的儲存上其實是不需要儲存部落格數量這麼大的資料量的；二來相同的列資料型別一致，這樣利於資料結構填充的優化和壓縮，而且對於數字列這種資料型別可以採取更多有利的演算法去壓縮儲存。

最後

目前列儲存模式在很多分析型資料庫中都很常見。而且因為大資料分析型需求的增多，越來越多傳統的行儲存資料庫也加入了列儲存的模式，比如 Oracle 和 Sql Server 都有了列儲存的特性。

之前講的 Apache Druid 底層資料儲存就是基於列模式。有興趣的可以回顧一下。另外 HBase 是一個比較有代表性的列儲存模式資料庫。有時間可以來聊一聊 HBase 底層是如何儲存資料的。也可以講一講數字列的壓縮方式（大家也可以先思考一下可以如何壓縮數字列）。

系列文章：

時間序列資料庫(TSDB)初識與選擇
十分鐘瞭解 Apache Druid
Apache Druid 底層儲存設計
Apache Druid 的叢集設計與工作流程

參考文章：

https://towardsdatascience.com/the-beauty-of-column-oriented-data-2945c0c9f560
https://dataschool.com/data-modeling-101/row-vs-column-oriented-databases/

想了解更多資料儲存相關知識，請關注我的公眾號。

相關推薦