資料庫的方向 行vs列

2021-09-22 20:53:55 字數 2629 閱讀 8308

前言:

此篇文章沒有波濤洶湧的起伏,沒有繁多的**,只有悠然自得的文筆。

因此,分享此文給大家。

如果你是一位資料庫專家的話,這篇部落格可能幫不了你什麼。

如果你是一位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...