本文根據(jù)朱閱岸老師在〖Gdevops 2017全球敏捷運維峰會廣州站〗現(xiàn)場演講內(nèi)容整理而成。

在公眾號對話框回復“數(shù)據(jù)庫技術”，可獲取完整PPT

講師介紹

朱閱岸，中國人民大學博士，騰訊基礎架構部高級工程師。研究方向主要為數(shù)據(jù)庫系統(tǒng)理論與實現(xiàn)、新硬件平臺下的數(shù)據(jù)庫系統(tǒng)以及TP+AP型混合系統(tǒng)。

本次分享大綱：

現(xiàn)代處理器及新型存儲的發(fā)展

現(xiàn)代處理器下的數(shù)據(jù)庫技術

面向新型存儲的數(shù)據(jù)庫系統(tǒng)

總結

大家應該都看過《星際穿越》，里面有很多震撼人心的場景，我個人印象較為深刻的還是老教授鼓勵庫珀去探索太空、尋找人類宜居星球時念的那首詩：“Do? not? go? gentle? into? that? good?? night…Though wise men at their end know dark is right…”，意思就是不要溫柔地走進那個良夜。對于技術人來說，數(shù)據(jù)庫系統(tǒng)底層硬件面臨著革新，我們也應該去探索新技術，以更好地適配這些底層硬件，而不是停留在原地，因此我拿這句詩作為本次分享的開始。

現(xiàn)代處理器及新型存儲的發(fā)展

1、現(xiàn)代處理器

先給大家介紹一下現(xiàn)代處理器及新型存儲的發(fā)展。大概從2005年開始，CPU的生產(chǎn)商就不再追求CPU的頻率而轉(zhuǎn)向多核技術研究，這里一個很重要的原因就是能耗和制造工藝上的問題，使得他們不能再單純地追求提升頻率。

在當前普通的服務器上，配備幾十個處理核心的處理器已相當常見，眾核的概念也開始流行起來。那什么是眾核？眾核，是在英文上有一個專門的詞，叫做many-core，跟單核是對應的，主要是指集成了成百上千個處理核心的處理器。多核處理器大家可能很熟悉了，但大家有沒注意到memory-wall效應這個現(xiàn)象呢？

以前CPU訪問一個內(nèi)存，大概只要一個時間周期的時間，現(xiàn)在需要上百個時間周期，訪問內(nèi)存成了一個比較昂貴的操作，特別是在如今大內(nèi)存和內(nèi)存計算這個環(huán)境下，memory-wall的效應更加嚴重，所以怎么樣去克服，使得程序具有局部性，成為了最重要的一件事情，即如何克服memory wall的問題。

2、新型存儲設備

大家是否聽過非易失性內(nèi)存？英特爾剛剛推出的3D XPoint技術，就屬于這類范疇的技術，即內(nèi)存掉電了以后，數(shù)據(jù)不會丟失。它兼具磁盤和內(nèi)存的特性，結合了兩者的優(yōu)點，也就是具有磁盤的持久存儲特性和內(nèi)存的快速訪問，主要特點是非低失、低延時、大容量，以及讀寫不對稱。

大家可以想象一下，有了這種硬件以后，我們系統(tǒng)設計者需要考慮的東西就不再是所謂的I/O的問題了，而是可以專注地把注意力放在高性能計算上，通俗地講就是關注系統(tǒng)的擴展性問題。

• 原理介紹

剛才所說的新型存儲——非易失性內(nèi)存主要有以下四種實現(xiàn)，其中最為成熟、最具市場前景的就是這個稱之為相變存儲的技術。

相變存儲器：材料可以在結晶狀態(tài)與非結晶狀態(tài)轉(zhuǎn)變

自旋磁矩：改變兩層磁性材料磁矩方向

鐵電材料：材料所形成的電荷高低，二元狀態(tài)

憶阻器：是一種有記憶功能的非線性電阻

根據(jù)國外工程師的逆向工程，英特爾的3D XPoint（傲騰），采用的就是這種技術。它的技術特點是利用相變材料，具有結晶和非結晶兩種狀態(tài)，這兩種狀態(tài)對應著低電阻和高電阻，對應著1和0。相比存儲器的單元結構主要有以下部件組成：雙層的導熱片，然后加熱絕緣體，以及相變材質(zhì)。通過加熱器，對這個相變材質(zhì)進行加熱，它就會呈現(xiàn)結晶和非結晶兩種狀態(tài)。其它的技術實現(xiàn)，有興趣可私下討論，這里就不多講了。

• 相關參數(shù)

主要還是PCM的技術，是目前最為重要的一種技術。我們來看一下它的參數(shù)，這里主要是一些相關文獻上摘取的數(shù)據(jù)，其中我們比較關注的是讀寫延遲、帶寬、壽命，以及密度（容量）。

從表格中可以看到，PCM和Flash相比，它的讀寫延遲要低兩個數(shù)量級，而它的壽命要高兩個數(shù)量級，并且容量的大小和Flash差不多，而跟內(nèi)存相比，它的讀延遲已經(jīng)是很接近了，但這個寫延遲和帶寬上還有差距，所以目前而言，PCM代替內(nèi)存是不可能的事情，而在一段時間內(nèi)這兩種存儲是會共同存在于計算機體系結構中。

另外一個有意思的現(xiàn)象就是PCM的密度，它的容量要比內(nèi)存大2到4倍，而且在空閑功耗，即系統(tǒng)空閑的時候，這個功耗是內(nèi)存的1%。因為內(nèi)存要不斷地去刷新，維護內(nèi)存單元里面的數(shù)據(jù)，所以這是一個很耀眼的特性，特別是對于數(shù)據(jù)中心而言。

• DBMS的設計

我們都知道系統(tǒng)的底層硬件決定著上層軟件的設計，現(xiàn)在數(shù)據(jù)庫系統(tǒng)最主要的矛盾是飛速發(fā)展的硬件與始于上世紀70年代的數(shù)據(jù)庫系統(tǒng)的陳舊設計思想。眾所周知，磁盤I/O是那個時期系統(tǒng)性能的主要瓶頸，而該系統(tǒng)的設計者主要考慮的是自己怎樣把這個系統(tǒng)設計得更好，以規(guī)避這個磁盤I/O的問題。在我們的數(shù)據(jù)庫系統(tǒng)里面，同樣隨處可見這種設計思想。針對這種磁盤時代而提出的算法思想，在大并發(fā)下將會呈現(xiàn)相當嚴重的性能問題。

這個研究是在2010年卡內(nèi)基梅隆大學的數(shù)據(jù)庫研究小組，對幾個開源數(shù)據(jù)庫的性能測試結果。可以看到，在多核處理器下這些數(shù)據(jù)庫系統(tǒng)的性能、擴展性都不能夠令人滿意。這篇論文拉開了數(shù)據(jù)庫系統(tǒng)多核優(yōu)化的序幕，特別是開源軟件，例如MySQL、PG在該時期就開始重視多核擴展性的問題，他們意識到原來在多核環(huán)境下，系統(tǒng)會有如此表現(xiàn)。

• 時間都去哪兒了呢？

那么，數(shù)據(jù)庫系統(tǒng)的事務執(zhí)行時間都耗費到哪去了？下面是麻省理工大學的研究結論——數(shù)據(jù)庫系統(tǒng)大部分的時間都耗費在緩存池管理、日志子系統(tǒng)上，只有12%左右的時間是耗費在真正有用的工作上。

這些模塊當中存在著大量的臨界區(qū)，這個臨界區(qū)設計得相當粗糙，下面我們可通過分析一個代碼片段來進行解析。在系統(tǒng)的設計上，經(jīng)常是一把大鎖，不假思索地加上去保護臨界區(qū)，幾百行的代碼。正如剛才看到的，在這種情況下，當系統(tǒng)并發(fā)度起來時，數(shù)據(jù)庫系統(tǒng)的性能是相當差的。

現(xiàn)代處理器下的數(shù)據(jù)庫技術

James Gray大家是否聽過呢？在現(xiàn)在數(shù)據(jù)庫系統(tǒng)里，跟事務相關的技術基本都是James Gray提出來的。但可惜的是，在2007年，他駕著一艘帆船出海，然后消失了。美國出動了海軍陸戰(zhàn)隊都沒有找到他。作為一個神奇人物，他憑借著對數(shù)據(jù)庫事務的突出貢獻獲得圖靈獎。

為了克服剛才所謂的內(nèi)存墻技術，James Gray曾說過這么一句話：RAM Locality Is King，就是說數(shù)據(jù)和程序行為的局部性才是克服CPU和內(nèi)存的速度不匹配的終極武器。

• RAM-Locality設計原則

數(shù)據(jù)庫里面主要采用以下幾種技術優(yōu)化性能，一種是列存儲技術。列存儲技術，主要用在OLAP，像MySQL、PG等OLTP型數(shù)據(jù)庫都是用行存儲技術。為什么要用列存儲技術呢？是因為進行數(shù)據(jù)分析的時候，經(jīng)常會出現(xiàn)寬表或有幾百個字段的表，但通常只需要訪問表中的某一些字段，比如要訪問銷售字段，對銷售字段進行累加，做一個聚集操作。采用列存儲，可以更好地優(yōu)化高速緩存的使用率，減少cache miss，克服內(nèi)存墻問題。

另外就是設計高速緩存友好的數(shù)據(jù)結構或算法。像現(xiàn)在的數(shù)據(jù)庫采用一次一元組的查詢處理方式對程序局部性很不友好。

什么叫一次一元組呢？數(shù)據(jù)庫系統(tǒng)的查詢語句，都是翻譯成操作樹。在樹的節(jié)點之間，操作符通過get_next函數(shù)驅(qū)動子節(jié)點獲取一條元組，遞歸調(diào)用下去，葉子節(jié)點將數(shù)據(jù)返回。函數(shù)的頻繁調(diào)用會產(chǎn)生嚴重的cache miss問題，所以現(xiàn)在新型的OLAP系統(tǒng)都是采用向量化查詢執(zhí)行引擎，上層操作符不再是一條一條數(shù)據(jù)地處理了，而是一批一批數(shù)據(jù)處理，減少函數(shù)調(diào)用的開銷和上下文的切換以最大化數(shù)據(jù)和程序指令的局部性。此外，hash join也針對cache大小將hash table進行劃分以增強數(shù)據(jù)與指令的數(shù)據(jù)性減少cache miss。

• 一個例子

這是針對Cache友好而設計算法的例子。在PG 9.5之前，系統(tǒng)判斷事務活躍性或獲取系統(tǒng)快照時，要用到事務的起始時間、事務ID等。這些字段都放在PGPROC這個結構體里，這個結構體有25個成員，但做可見性判斷時，只需要用到幾個成員就夠了。因此采用這種設計系統(tǒng)會把其它無關字段讀入，污染其它cache line，造成嚴重的cache miss以及Cache浪費問題。所以后面他們就把用于可見性判斷等經(jīng)常訪問的字段放在另一個結構體里面叫做PGXACT。打了這個補丁之后，在大并發(fā)下這個性能收益是相當客觀的，性能數(shù)據(jù)如圖中右上紅色數(shù)據(jù)所示。

因此，針對Memory ?Wall這個問題，設計cache友好的數(shù)據(jù)結構與算法是一個很奏效的方法。

• 避免熱點與簡化臨界區(qū)

針對多核的問題，我們還要避免熱點的問題，簡化臨界區(qū)。就像我們經(jīng)常看到的，并發(fā)一大，系統(tǒng)性能就掉了下來。

這是微軟的內(nèi)存數(shù)據(jù)庫Hekaton的一個實驗結果。截取了事務在提交時的一個時間戳。這個全局的原子操作都會導致這個性能的問題。但針對MySQL、PG這兩種數(shù)據(jù)庫，性能問題還遠遠輪不到像類似于這種原子操作來引發(fā)。

這就是我剛才所提到的問題，我們的磁盤數(shù)據(jù)庫的設計原則是優(yōu)化磁盤IO。事務在提交時，不需要刷臟，以避免隨機IO。我們有一個專門的術語，叫做No force，也就是說事務提交時，不用去刷臟頁，但系統(tǒng)會把日志先刷下去。它這種集中式的設計，很容易導致性能的問題。針對更新密集型的工作負載，這個模塊的性能問題更加突出。

傳統(tǒng)的先寫日志的算法（Write-ahead Logging），PG也好、MySQL也好，一般分為三個步驟，首先獲取一把大鎖，保護shared? Log? Buffer的這個數(shù)據(jù)結構；然后把日志記錄拷貝到相應的日志緩沖區(qū)；最后釋放這把鎖。這是最傳統(tǒng)的做法。

我們現(xiàn)在也跟社區(qū)里面去探討了是否可以廢棄集中式設計，采用分布式日志的問題。就是不采用一個日志管理器，轉(zhuǎn)而使用多個Log Buffer同時把日志序列號改成邏輯時間戳。

在PG9.4版本以前，就采用剛才那么一個粗放的形式，加一把大鎖，然后臨界區(qū)里面進行搗鼓，例如長度計算、拷貝日志、一些邊界檢查等。這個臨界區(qū)的代碼大概有300行左右。但后來他們發(fā)現(xiàn)這個模塊的性能問題實在太嚴重了。

解決的方法是把日志文件抽象成線性長度，寫入日志時把位置預留出來。位置確定以后就把鎖放掉，因為系統(tǒng)知道往哪里去寫入數(shù)據(jù)，根本就不需要把日志拷過去再放鎖。并且事務之間可以并行地去拷貝日志。優(yōu)化以后，性能提升了大概20%到30%左右，PG社區(qū)里面有相應的測試報告。

他二哥注：更多分布式日志可閱讀另一篇文章《用分布式日志優(yōu)化單機數(shù)據(jù)庫系統(tǒng)將成未來標配？》

• 鎖管理器（鎖申請）

另外一種是數(shù)據(jù)庫里邏輯鎖的問題。數(shù)據(jù)庫里面的加鎖，是通過一個哈希表實現(xiàn)的，表里面的維護有很多鎖的信息。這個鎖其實就是一個標記，例如要加一個行鎖，就把這個鎖的Table ID、Row ID拿過來作為key，然后哈希到這個鎖表里。同時標記這個鎖屬于哪種類型，是共享鎖還是排他鎖等。

但在大并發(fā)或沖突比較嚴重的情況下，這個鎖表是會引發(fā)問題的。因為它是一個共享的數(shù)據(jù)結構，很多事務都要跟鎖表打交道，頻繁地加鎖以及釋放鎖引發(fā)熱點問題。

PG 9.2采用了繼承鎖技術，把共享表級鎖緩存在本地，然后在事務之間傳遞，不用把共享表鎖歸還給鎖管理器，減少跟共享的數(shù)據(jù)結構的交互，提高系統(tǒng)的并發(fā)性。

面向新型存儲的數(shù)據(jù)庫系統(tǒng)

接下來我們來探討一下面向新型存儲的數(shù)據(jù)庫系統(tǒng)。底層的存儲變了，數(shù)據(jù)庫系統(tǒng)架構各方面肯定都要去改變。

這里我做了一下總結，NVRAM具有的六個主要特性：一種是可字節(jié)尋址，它的行為模式就相當于內(nèi)存，可以字節(jié)尋址，而不再像磁盤采用Block尋址了，然后是閑時低功耗、使用壽命長、非易失性、存儲容量大、快速地隨機讀寫。

目前而言，NVRAM接入DBMS主要有三種方式，最左邊的是我們傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)架構，維護兩個Buffer，一個是Log Buffer，另外一個是Data? Buffer。Log? Buffer是事務日志集中寫入的內(nèi)存區(qū)域；DATA? Buffer用于緩存數(shù)據(jù)頁，事務訪問數(shù)據(jù)時首先在這個buffer里面尋找所需的數(shù)據(jù)。MySQL里面的Buffer Pull就是指這個DATA? Buffer。

第一種接入方式就是我們可以直接把它作為磁盤的替代直接拿過來，數(shù)據(jù)庫系統(tǒng)軟件不需要改動。這種方式當然是可以獲得收益，因為底層I/O速度變快了，但沒有發(fā)揮它最大的收益，軟件的復雜度還是在那里，不多不少。

第二種是作為日志的存儲，現(xiàn)在大家使用的機器內(nèi)存都很大了，我們的I/O基本上發(fā)生在一個地方，就是寫日志。為了不丟數(shù)據(jù)，日志是必須落盤的。把NVRAM作為日志存儲的設備，可以用比較小的代價獲得比較好的收益，第二種接入方式就是把它作為日志存儲，而設計相應的算法與優(yōu)化臨界區(qū)。

第三種方式，是全系統(tǒng)接入的，系統(tǒng)經(jīng)過全面的改造，把數(shù)據(jù)放在NVRAM。這個可以跟第二種接入方式對比一下，系統(tǒng)不再維護Log? Buffer這個數(shù)據(jù)結構，完全被廢棄掉。

• write-behind logging

CMU在VLDB 2017剛剛發(fā)表的研究稱之為，write-behind logging，就是NVRAM全系統(tǒng)接入的一種方式。他們的idea是，write-ahead Logging是磁盤時代的算法，現(xiàn)在我不用先寫日志了。先寫日志的問題就是數(shù)據(jù)庫系統(tǒng)宕掉以后，可能需要很長時間地去恢復。它為了避免隨機IO不將數(shù)據(jù)刷盤，轉(zhuǎn)而順序?qū)懗鋈罩尽Ｏ到y(tǒng)恢復時要先拿到一個檢查點，然后從檢查點開始去掃描日志，把日志記錄拿出來，一條條地重放。數(shù)據(jù)量大的時候，這是相當耗時的一個工作。

他們針對NVRAM提出一個新算法稱之為write-behind Logging，就是事務提交的時候，直接把臟頁寫入NVRAM（因為NVRAM的隨機IO也是相當快的）。臟頁刷盤以后，再去寫日志。

他們所設計的日志記錄是這樣子，不用再去構造什么After-image，直接就寫上事務提交的時間區(qū)間(Cp,Cd)就行了。小于CP這個時間點的事務都已經(jīng)提交了，而落在這個時間區(qū)間（Cp，Cd）里面的事務，就是還沒有提交的。在事務恢復的時候，系統(tǒng)知道這個時間區(qū)間的事務沒有提交，對其它事務不可見。系統(tǒng)沒有必要去進行Redo操作了，因為數(shù)據(jù)都已經(jīng)持久化。系統(tǒng)崩潰恢復時，需要一趟掃描日志，建立崩潰時候的時間區(qū)間（檢點可以減少需要掃描的日志量）。建立這個時間窗口相當于undo操作。

• TPC-C benchmark

他們對采用不用算法的系統(tǒng)的恢復時間做了一個比較，可以看到write-behind Logging的恢復時間，大概可以達到即時恢復的效果。系統(tǒng)起來，馬上就可以對外提供服務，但這個協(xié)議是專門針對非易失性內(nèi)存而設計的，在這個磁盤SSD上，性能比較差。在這個NVM上，WBL的性能有30%左右的提升。

總結

應用需求、行業(yè)數(shù)據(jù)以及計算機硬件是拉動這個數(shù)據(jù)庫系統(tǒng)發(fā)展的三駕馬車；

在這個多核與內(nèi)存計算的時代下，系統(tǒng)設計人員更應該將精力放在系統(tǒng)的擴展性上，更應該注重數(shù)據(jù)訪問的局部性，克服所謂的內(nèi)存墻問題；

此外，NVM的出現(xiàn)可能會顛覆系統(tǒng)架構。它的出現(xiàn)使得系統(tǒng)設計人員可以將注意力完全地從I/O上移除，專注系統(tǒng)擴展性設計。

狄更斯說：“這是最壞的時代，同時也是最好的時代”，這個時代給了我們挑戰(zhàn)，同時也為數(shù)據(jù)庫系統(tǒng)從業(yè)人員帶來了機遇！

Q&A

【問題1】：請教老師，我們是做金融行業(yè)的，想問一下目前有哪些場景這一塊會用得比較多？剛剛聽了分享，感覺這一塊硬件上的性能還是相對比較好的。

答：現(xiàn)在這個應用的場景，簡單來說可以提升IO性能，例如用來存儲日志，可以快速提升系統(tǒng)性能。還有就是在大數(shù)據(jù)分析的場景，用來提升系統(tǒng)的IO能力。??

【問題2】：現(xiàn)在有哪些廠家有提供剛剛講的這一塊？具體有哪些廠商？

答：騰訊現(xiàn)在有在做這一塊的優(yōu)化，英特爾年初推出了相應的硬件，這個硬件我們也拿到了，也在做相關的優(yōu)化。跟著社區(qū)，我們也在做一些交流來提升系統(tǒng)的擴展性的問題。

追問：騰訊在數(shù)據(jù)庫這邊有支持和服務？

答：現(xiàn)在我們還沒有放到云上去，目前在內(nèi)部做一些相應的開發(fā)。很快就會在云上推出相關產(chǎn)品。

追問：剛才講了很多是PG的，騰訊應該也做了一些優(yōu)化，那這方面會不會有一些開源？

答：有，這都是開源的。??

追問：哪里可以拿到？

答：PG或者MySQL社區(qū)里面，這些優(yōu)化都是會提交到社區(qū)里面的。

???

【問題3】：剛看到老師PPT里有對TPCC的測試，因為現(xiàn)在TPCC基本上快被淘汰了，有沒有去做過TPCE和TPCDS相關的測試呢？

答：這個你可能有點誤會，因為這兩個場景是不同的，我們數(shù)據(jù)庫里面有很多benchmark，比如TPCC、TPCH、TPCDS，他們是針對不同的場景，有些是針對OLAP，有些是針對OLTP。像大家比較熟悉的sysbench，其實是針對OLTP去做的，剛才你說的那個就是OLAP的應用場景。

追問：H和DS是對OLAP性能測試嗎？C是對TP的。

答：對，他們的應用場景不同。TPCC是衡量一個事務型數(shù)據(jù)庫，到底能達到一個什么樣性能的標準，這個比較具有說服力。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的透过新硬件环境下的存储技术，看未来数据库系统崛起（附PPT）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。