前言：
此篇文章沒有波濤洶湧的起伏，沒有繁多的**，只有悠然自得的文筆。
因此，分享此文給大家。
如果你是一位資料庫專家的話，這篇部落格可能幫不了你什麼。
如果你是一位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的所有資訊時，你又必須要讀取大量的列（頁面）來獲取所有的資料。
正因為此，才有了這些天有關列式資料庫的討論。
如果你還是沒有很好理解的話，我們下面會有更加詳細的介紹。
當然，事實並非如此。基於行的資料庫，例如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就結束了.現在，當你再讀到有關列式數庫的文章時，就可以理解其引起討論的原因了。
在下次的討論中，我們將進一步學習。
翻譯：周松文
諳憶github：
資料庫的方向 行vs列
前言 此篇文章沒有波濤洶湧的起伏，沒有繁多的 只有悠然自得的文筆。因此，分享此文給大家。如果你是一位資料庫專家的話，這篇部落格可能幫不了你什麼。如果你是一位it人士，但對資料庫技術只知其然的話，這篇部落格會很適合你。如果你是非it人士，又或者你是我的家人，謝謝你們的閱讀，但是顯然你應該去尋求更適合你...
行式資料庫 VS 列式資料庫
1 行式資料庫 2 列式資料庫 1 行式更適合oltp,查詢乙個記錄的所有列。列式更適合olap，非常適合於在資料倉儲領域發揮作用，比如資料分析 海量儲存和商業智慧型 涉及不經常更新的資料。由於設計上的不同，列式資料庫在並行查詢處理和壓縮上更有優勢。而且資料是以列為單元儲存，完全不用考慮資料建模或者...
怎樣把資料庫的行轉成列
有如下格式的表 company name exchange listing countries business country byd otc pk usa chn byd szse chn chn byd xter gem chn byd hkse hk chn 怎麼樣轉成一列，後面帶listi...