要了解列式資料庫的本質，我覺得先從邏輯視角和物理視角來區分一些概念比較好，比如DBMS從邏輯視角來看， 可以分為

1）Relative Database Management System
2）Non-Relative Database Management System

而從物理（儲存的）視角來看，則可以分為：
1）Row Based Storage DBMS
2）Column Based Storage DBMS

當然， 無論無論是邏輯視角還是物理視角， 它們都是不衝突的， 比如我們可以將邏輯上的RDBMS和物理上的Row Based Storage DBMS相結合， 那就成為我們平常使用最多的一種資料庫產品型別，比如Mysql， Oracle等產品都屬於這個範疇， 而如果我們將邏輯上的RDBMS和物理上的Column Based Storage DBMS相結合， 那就成為我們今天要探索的一類資料庫產品，即基於列式的關係型資料庫。

 

上圖是摘錄自infobright的一份文件， 該圖形象的描述了物理上兩種不同的儲存方式與關係型表之間的關係。可以看到，在通常的基於行儲存的RDBMS中， 資料是按照行資料為基礎單元進行儲存的， 而在基於列式的DBMS中， 資料則是按照一列一列的資料為單元進行儲存， 那麼，

1）這兩種不同的儲存方式會造就什麼樣的差異那？
2）為什麼通常認為基於行儲存的RDBMS更適合OLTP型別的應用場景， 而基於列式的RDBMS則更適合OLAP型別的應用場景那？

不妨讓我們來簡單分析一下…

1 - 基於行儲存的RDBMS行為分析

因為資料在這種型別的RDBMS中是按照行儲存的，那麼資料在寫入的時候可以按照一行一行順序寫入，對於磁碟來講， 這種行為與其物理結構造就的行為是比較契合的。在OLTP型別的應用中， 這種行為是合適的， 雖然基於行的儲存在資料讀取的時候會存在一定的“缺陷”（很多時候， 並非每一行中每一列的值都需要讀取出來），但在OLTP型別的應用中， 通過索引啦之類的機制，可以基本搞定。

所以， 不嚴謹點兒講， “基於行儲存的RDBMS適合OLTP型別的應用場景”這句話還算恰當。

2 - 基於列式的RDBMS行為分析 在基於列式的RDBMS中， 資料現在是按照一列一列為單元進行儲存的，那麼要進行一行一行的資料寫入的時候， 可能就需要“跳躍式”的將每一行每一列的值寫入到不同的區塊，顯然，對於磁碟結構來說，這中儲存方式對資料的寫入是不夠友好的，效能指定好不到哪兒去（當然，是與基於行儲存的DBMS相比）。但是，反過來看， 對資料寫入的支援或許不好，那對資料的讀取那？很簡單就可以看出來，如果我每次都對一列，一列的資料感興趣，我完全可以快速的讀取每一列的所有值，那麼， 這種特性對讀取的列上所有的值進行統計分析就比較讚了。至於說“基於列式的RDBMS則更適合OLAP型別的應用場景”， 我們不妨以資料倉庫這種特定場景為基礎進行一簡單的“分析”（CRM之類也可以）。

對於資料倉庫來講， 大部分情況下，它會從各個資料來源彙總資料，然後進行分析和反饋， 所謂資料探勘，商業智慧（BI），決策支援之類，大都是資料倉庫的職責範圍吧！很顯然， 要完成這些， 在資料倉庫所從事的資料處理操作基本上就是資料的讀取佔大頭兒啦，只有讀取之後才能進行分析和統計嘛， 而統計大多也是針對同一指標的資料進行，哎呀， 想到沒， 基於列的儲存好像很適合哦！ Bingo，I Think u got it. 基於列式的資料庫很適合海量的資料查詢和統計，也很顯然比較適合DW這種部門和相應的應用來使用。

DW會將各個資料來源彙總過來的資料做抽取，清洗，轉換， 載入之類的工作，然後放入Star Schema或者Snowflake Schema建模的新儲存模型中，然後供後端的其它分層和應用使用，此後，大多數操作型別都將是資料讀取型別。

3 - 列式資料庫相關關鍵技術 1）Compression 每一列資料從邏輯上來講其值都歸屬於同一指標， 很多情況下， 值的離散範圍也有一定的規律，如果能幹根據這一規律選取合適的壓縮演算法，顯然能夠節省很大的儲存空間，甚至比原始資料都要小， 大多數列式資料庫都可以達到10:1 到40:1， 50:1不等的壓縮率。 列資料庫中主要的壓縮方法有以下幾類： 1) 消零或空格符法（Null Suppression） 2) 詞典編碼演算法 (Dictionary Encoding) 3) 行程編碼演算法 (Run-length Encoding) 4) 位向量演算法 （Bit-Vector Encoding） 5) Lempel-Ziv演算法 （Lempel-Ziv Encoding） 2）Late Materialization 這一技術主要式為了解決如何在沒有索引的情況下實現最大程度的資料過濾與減少不必要的IO和記憶體消耗 3）Block Iteration 4）Invisible join 5）column-wise query processing 對提高查詢效能十分關鍵