轉載地址：https://www.ibm.com/developerworks/community/blogs/IBMi/entry/database?lang=en

原文鏈接：http://ibmsystemsmag.blogs.com/you_and_i/db2/

數據庫的方向 - 行vs列

如果你是一位數據庫專家的話，這篇博客可能幫不了你什么。

如果你是一位IT人士，但對數據庫技術只知其然的話，這篇博客會很適合你。

如果你是非IT人士，又或者你是我的家人，謝謝你們的閱讀，但是顯然你應該去尋求更適合你的閱讀材料。

如此，可能會對此話題感興趣的朋友已經減少了。看來你應該是這樣一個人，你是非數據庫領域的IT專家，但是你深知數據庫的重要性，你可能非常想更多的了解一些當前IT界正在熱烈討論的數據庫熱門話題。

我可以很坦率的告訴大家，雖然我在IBM i的很多個部門工作過，但是我并不是一個DB2的開發人員。所以我會定期的去DB2團隊尋求一些聰明的數據庫專家給我一些比較高級的數據庫指導。尤其,我非常想知道，為什么近來如此多行業都在談論“列式存儲”數據庫的原因。所以，我找到了Mark Anderson。 眾所周知，Mark是一位杰出的工程師，現在是DB2 for i的首席架構師。下面，我將分享一下我學到的知識。

今天的主題也如同很多有關數據庫討論一樣主要集中于性能方面。即，新興的列式數據庫和傳統的行式數據庫在性能方面的比較。

顧名思義，這兩種數據庫架構在存貯數據時的方式是大相徑庭的。在行式數據庫中，每一行中的每一塊數據都是緊挨著另一塊數據存放在硬盤中。一般情況下，你可以認為每一行存貯的內容就是硬盤中的一組連續的字節。如果你記得DB 101（你已經學習了數據庫的介紹課程，對吧？）中介紹的數據庫中每一行都是用來記錄一些實體信息的。為了方便我們的討論，我們假設每一行都包含一個用戶的信息，每個用戶的所有屬性都整塊兒存儲在硬盤上。如下圖所示，虛擬表（或者數組）中的列用來存儲每個屬性。

在硬盤上，大量的頁面用來存儲所有的數據。我們假設數據庫中的每一行的信息都存儲在同一頁上。在這種情況下，每一頁都能保存一個用戶的所有信息。在上邊的例子中，Alice的所有信息都存儲在一個頁面中。如果需要獲取或更新Alice的信息，那么某一時刻在內存中僅需存儲關于Alice的單一頁面。

雖然我還沒有提到，但是你可以想象，如果是基于列的數據庫，所有的數據都是以列的形式存儲的。回到之前的例子，假設每一列的存儲對應一個頁面。如下圖所示，所有的ZIP code將會存儲到一個頁面中，而所有的“2013 Total Order”則會存儲在另一個頁面中。

（嘿，所有數據庫專家可能會就此停留，繼而對用戶的表設計提出意見，但抱歉，我并不是數據庫架構師，這僅僅只是一個教學用例。）

現在，我們言歸正傳。

所有的數據庫（實際上是所有的運算），當它所需要的數據駐留在內存中時其工作速度是最快的。當然正常情況下，數據不會在內存中，它們會被放到別的地方，當數據庫調用它們時，它們才會被放到內存中。所以，如果你使用的是行式數據庫，那么你對一行數據進行操作時，數據庫的性能會是最好的。在上面的例子中，僅一個頁面被放到了內存中。（這只是一個示例，事實上，操作系統會帶來不止一頁的數據，稍后詳細說明）

另一方面，如果你的數據庫是基于行的，但是你要想得到所有數據中，某一列上的數據來做一些操作，這就意味著你將花費時間去訪問每一行，可你用到的數據僅是一行中的小部分數據。若此時你使用了列式的數據庫，那就可以方便快捷的獲取數據，因為每一列的信息都是存儲在一起的。例如，所有的“2013 Total Order”信息都是存儲在同一列中的。

可關鍵在于你使用列式數據庫時，當你想要得到Alice的所有信息時，你又必須要讀取大量的列（頁面）來獲取所有的數據。

正因為此，才有了這些天有關列式數據庫的討論。

如果你還是沒有很好理解的話，我們下面會有更加詳細的介紹。

到目前為止，幾乎所有的數據庫都是基于行的數據庫，此類數據庫對大多數的傳統業務都是非常有效的。數據庫專家們將大部分的數據庫工作負載稱為OLTP–在線事務處理。OLTP工作負載是數據庫現有業務的關鍵業務。一般而言，這些應用程序在使用行數據庫時會有更好的表現，因為其工作負載趨向于單一實體的多個屬性（存儲在很多的列中）。由于這些應用程序都是基于行工作的，所以在使用時，從硬盤中獲取的頁面數量是最小的。

如果能對列中的數據進行有效的處理，某些工作負載會運行得更高效。在線分析處理（OLAP）工作負載常常需要收集列中的數據。例如，如果你想要知道標記為“2013 Total Order”列中的所有值，當你使用基于列的數據庫時，你可以將這一列放到內存中并統計所有值。但當使用的是基于行的數據庫時，就必須去訪問每一行而獲取對應的數據。

當然，事實并非如此?；谛械臄祿?#xff0c;例如DB2 for i，已經增加了一些方法，這些方法可以使得，諸如“sum a column”這樣簡單的操作，或者更復雜一些的OLAP分析也可以很高效的得到處理。例如，DB2 for i有兩種結構，分別是編碼向量索引（EVIs）和物化查詢表（MQTs），對于這樣的操作都有很好的效果。并且DB2 for i給用戶的數據是成批的（一次讀取很多行），而不是一次一個。除此之外，用戶自定義的方法也可以用來提高性能。IBM的存儲管理組件也是非常智能的，值得一提的是，它實現了單級存儲。正因為它如此的智能，所以在用戶提出請求前，已經將數據讀取到內存中。正因為在很多的OLTP工作負載中都要求順序地通過行，而DB2 for i在需要數據之前，已將行數據批量的讀取到內存中，可見這個功能是非常重要的。

另一方面，單純給列式存儲的表加索引，也不能使OLTP很高效。Mark曾經說過“這就像把很多的矮胖子放在一起”。行信息分散在很多存儲頁中。即使整個數據庫都存放在內存里，也需要消耗大量的CPU資源，來將一行中的所有列拼接起來。

下面總結這一課的關鍵內容。在選擇使用哪種數據庫時，問自己這樣一個問題，哪種工作負載是你的數據庫需要支持的最關鍵的工作負載。盡管可能你兩種操作都需要，但是當核心業務是OLTP時，一個行式的數據庫，再加上數十年積累的優化操作，可能是最好的選擇。如果你的企業并不需要快速處理OLTP業務，但需要可以快速處理OLAP時，那么一個列式的數據庫將會成為你的不二選擇。

如果你需要同時處理兩種業務，且要求它們都能高效處理時，可以去了解兩種種架構相關的混合技術。你可以選擇一種，又或者是使用兩種架構的結合來滿足你的需求。無論你選擇了何種類別，都要確保證這一解決方案是穩定的，這可是要用來切實為企業數據服務的。

到此，尊敬的讀者們， DB 102就結束了.現在，當你再讀到有關列式數庫的文章時，就可以理解其引起討論的原因了。

在下次的討論中，我們將進一步學習。

原文作者：Steve Will

翻譯：周松文

總結

以上是生活随笔為你收集整理的数据库的方向 - 行vs列(转自： IBM i 中国开发团队)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。