講師介紹

朱閱岸，中國人民大學博士，騰訊基礎架構部高階工程師。研究方向主要為資料庫系統理論與實現、新硬體平臺下的資料庫系統以及TP+AP型混合系統。

本次分享大綱：

1. 現代處理器及新型儲存的發展
2. 現代處理器下的資料庫技術
3. 面向新型儲存的資料庫系統
4. 總結

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

現代處理器及新型儲存的發展

1、現代處理器

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

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

以前CPU訪問一個記憶體，大概只要一個時間週期的時間，現在需要上百個時間週期，訪問記憶體成了一個比較昂貴的操作，特別是在如今大記憶體和記憶體計算這個環境下，memory-wall的效應更加嚴重，所以怎麼樣去克服，使得程式具有區域性性，成為了最重要的一件事情，即如何克服memory wall的問題。

2、新型儲存裝置

大家是否聽過非易失性記憶體？英特爾剛剛推出的3D XPoint技術，就屬於這類範疇的技術，即記憶體掉電了以後，資料不會丟失。它兼具磁碟和記憶體的特性，結合了兩者的優點，也就是具有磁碟的持久儲存特性和記憶體的快速訪問，主要特點是非低失、低延時、大容量，以及讀寫不對稱。

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

• 原理介紹

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

1. 相變儲存器：材料可以在結晶狀態與非結晶狀態轉變
2. 自旋磁矩：改變兩層磁性材料磁矩方向
3. 鐵電材料：材料所形成的電荷高低，二元狀態
4. 憶阻器：是一種有記憶功能的非線性電阻

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

• 相關引數

主要還是PCM的技術，是目前最為重要的一種技術。我們來看一下它的引數，這裡主要是一些相關文獻上摘取的資料，其中我們比較關注的是讀寫延遲、頻寬、壽命，以及密度（容量）。

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

另外一個有意思的現象就是PCM的密度，它的容量要比記憶體大2到4倍，而且在空閒功耗，即系統空閒的時候，這個功耗是記憶體的1%。因為記憶體要不斷地去重新整理，維護記憶體單元裡面的資料，所以這是一個很耀眼的特性，特別是對於資料中心而言。

• DBMS的設計

我們都知道系統的底層硬體決定著上層軟體的設計，現在資料庫系統最主要的矛盾是飛速發展的硬體與始於上世紀70年代的資料庫系統的陳舊設計思想。眾所周知，磁碟I/O是那個時期系統性能的主要瓶頸，而該系統的設計者主要考慮的是自己怎樣把這個系統設計得更好，以規避這個磁碟I/O的問題。在我們的資料庫系統裡面，同樣隨處可見這種設計思想。針對這種磁碟時代而提出的演算法思想，在大併發下將會呈現相當嚴重的效能問題。

這個研究是在2010年卡內基梅隆大學的資料庫研究小組，對幾個開源資料庫的效能測試結果。可以看到，在多核處理器下這些資料庫系統的效能、擴充套件性都不能夠令人滿意。這篇論文拉開了資料庫系統多核優化的序幕，特別是開源軟體，例如MySQL、PG在該時期就開始重視多核擴充套件性的問題，他們意識到原來在多核環境下，系統會有如此表現。

• 時間都去哪兒了呢？

那麼，資料庫系統的事務執行時間都耗費到哪去了？下面是麻省理工大學的研究結論——資料庫系統大部分的時間都耗費在快取池管理、日誌子系統上，只有12%左右的時間是耗費在真正有用的工作上。

這些模組當中存在著大量的臨界區，這個臨界區設計得相當粗糙，下面我們可通過分析一個程式碼片段來進行解析。在系統的設計上，經常是一把大鎖，不假思索地加上去保護臨界區，幾百行的程式碼。正如剛才看到的，在這種情況下，當系統併發度起來時，資料庫系統的效能是相當差的。

現代處理器下的資料庫技術

James Gray大家是否聽過呢？在現在資料庫系統裡，跟事務相關的技術基本都是James Gray提出來的。但可惜的是，在2007年，他駕著一艘帆船出海，然後消失了。美國出動了海軍陸戰隊都沒有找到他。作為一個神奇人物，他憑藉著對資料庫事務的突出貢獻獲得圖靈獎。

為了克服剛才所謂的記憶體牆技術，James Gray曾說過這麼一句話：RAM Locality Is King，就是說資料和程式行為的區域性性才是克服CPU和記憶體的速度不匹配的終極武器。

• RAM-Locality設計原則

資料庫裡面主要採用以下幾種技術優化效能，一種是列儲存技術。列儲存技術，主要用在OLAP，像MySQL、PG等OLTP型資料庫都是用行儲存技術。為什麼要用列儲存技術呢？是因為進行資料分析的時候，經常會出現寬表或有幾百個欄位的表，但通常只需要訪問表中的某一些欄位，比如要訪問銷售欄位，對銷售欄位進行累加，做一個聚集操作。採用列儲存，可以更好地優化快取記憶體的使用率，減少cache miss，克服記憶體牆問題。

另外就是設計快取記憶體友好的資料結構或演算法。像現在的資料庫採用一次一元組的查詢處理方式對程式區域性性很不友好。

什麼叫一次一元組呢？資料庫系統的查詢語句，都是翻譯成操作樹。在樹的節點之間，操作符通過get_next函式驅動子節點獲取一條元組，遞迴呼叫下去，葉子節點將資料返回。函式的頻繁呼叫會產生嚴重的cache miss問題，所以現在新型的OLAP系統都是採用向量化查詢執行引擎，上層操作符不再是一條一條資料地處理了，而是一批一批資料處理，減少函式呼叫的開銷和上下文的切換以最大化資料和程式指令的區域性性。此外，hash join也針對cache大小將hash table進行劃分以增強資料與指令的資料性減少cache miss。

•  一個例子

時，要用到事務的起始時間、事務ID等。這些欄位都放在PGPROC這個結構體裡，這個結構體有25個成員，但做可見性判斷時，只需要用到幾個成員就夠了。因此採用這種設計系統會把其它無關欄位讀入，汙染其它cache line，造成嚴重的cache miss以及Cache浪費問題。所以後面他們就把用於可見性判斷等經常訪問的欄位放在另一個結構體裡面叫做PGXACT。打了這個補丁之後，在大併發下這個效能收益是相當客觀的，效能資料如圖中右上紅色資料所示。

因此，針對Memory  Wall這個問題，設計cache友好的資料結構與演算法是一個很奏效的方法。

• 避免熱點與簡化臨界區

針對多核的問題，我們還要避免熱點的問題，簡化臨界區。就像我們經常看到的，併發一大，系統性能就掉了下來。

這是微軟的記憶體資料庫Hekaton的一個實驗結果。截取了事務在提交時的一個時間戳。這個全域性的原子操作都會導致這個效能的問題。但針對MySQL、PG這兩種資料庫，效能問題還遠遠輪不到像類似於這種原子操作來引發。

這就是我剛才所提到的問題，我們的磁碟資料庫的設計原則是優化磁碟IO。事務在提交時，不需要刷髒，以避免隨機IO。我們有一個專門的術語，叫做No force，也就是說事務提交時，不用去刷髒頁，但系統會把日誌先刷下去。它這種集中式的設計，很容易導致效能的問題。針對更新密集型的工作負載，這個模組的效能問題更加突出。

傳統的先寫日誌的演算法（Write-ahead Logging），PG也好、MySQL也好，一般分為三個步驟，首先獲取一把大鎖，保護shared  Log  Buffer的這個資料結構；然後把日誌記錄拷貝到相應的日誌緩衝區；最後釋放這把鎖。這是最傳統的做法。

我們現在也跟社群裡面去探討了是否可以廢棄集中式設計，採用分散式日誌的問題。就是不採用一個日誌管理器，轉而使用多個Log Buffer同時把日誌序列號改成邏輯時間戳。

在PG9.4版本以前，就採用剛才那麼一個粗放的形式，加一把大鎖，然後臨界區裡面進行搗鼓，例如長度計算、拷貝日誌、一些邊界檢查等。這個臨界區的程式碼大概有300行左右。但後來他們發現這個模組的效能問題實在太嚴重了。

解決的方法是把日誌檔案抽象成線性長度，寫入日誌時把位置預留出來。位置確定以後就把鎖放掉，因為系統知道往哪裡去寫入資料，根本就不需要把日誌拷過去再放鎖。並且事務之間可以並行地去拷貝日誌。優化以後，效能提升了大概20%到30%左右，PG社群裡面有相應的測試報告。

• 鎖管理器（鎖申請）

另外一種是資料庫裡邏輯鎖的問題。資料庫裡面的加鎖，是通過一個雜湊表實現的，表裡面的維護有很多鎖的資訊。這個鎖其實就是一個標記，例如要加一個行鎖，就把這個鎖的Table ID、Row ID拿過來作為key，然後雜湊到這個鎖表裡。同時標記這個鎖屬於哪種型別，是共享鎖還是排他鎖等。

但在大併發或衝突比較嚴重的情況下，這個鎖表是會引發問題的。因為它是一個共享的資料結構，很多事務都要跟鎖表打交道，頻繁地加鎖以及釋放鎖引發熱點問題。

PG 9.2採用了繼承鎖技術，把共享表級鎖快取在本地，然後在事務之間傳遞，不用把共享表鎖歸還給鎖管理器，減少跟共享的資料結構的互動，提高系統的併發性。

面向新型儲存的資料庫系統

接下來我們來探討一下面向新型儲存的資料庫系統。底層的儲存變了，資料庫系統架構各方面肯定都要去改變。

這裡我做了一下總結，NVRAM具有的六個主要特性：一種是可位元組定址，它的行為模式就相當於記憶體，可以位元組定址，而不再像磁碟採用Block定址了，然後是閒時低功耗、使用壽命長、非易失性、儲存容量大、快速地隨機讀寫。

目前而言，NVRAM接入DBMS主要有三種方式，最左邊的是我們傳統的資料庫系統架構，維護兩個Buffer，一個是Log Buffer，另外一個是Data  Buffer。Log  Buffer是事務日誌集中寫入的記憶體區域；DATA  Buffer用於快取資料頁，事務訪問資料時首先在這個buffer裡面尋找所需的資料。MySQL裡面的Buffer Pull就是指這個DATA  Buffer。

第一種接入方式就是我們可以直接把它作為磁碟的替代直接拿過來，資料庫系統軟體不需要改動。這種方式當然是可以獲得收益，因為底層I/O速度變快了，但沒有發揮它最大的收益，軟體的複雜度還是在那裡，不多不少。

第二種是作為日誌的儲存，現在大家使用的機器記憶體都很大了，我們的I/O基本上發生在一個地方，就是寫日誌。為了不丟資料，日誌是必須落盤的。把NVRAM作為日誌儲存的裝置，可以用比較小的代價獲得比較好的收益，第二種接入方式就是把它作為日誌儲存，而設計相應的演算法與優化臨界區。

第三種方式，是全系統接入的，系統經過全面的改造，把資料放在NVRAM。這個可以跟第二種接入方式對比一下，系統不再維護Log  Buffer這個資料結構，完全被廢棄掉。

• write-behind logging

CMU在VLDB 2017剛剛發表的研究稱之為，write-behind logging，就是NVRAM全系統接入的一種方式。他們的idea是，write-ahead Logging是磁碟時代的演算法，現在我不用先寫日誌了。先寫日誌的問題就是資料庫系統宕掉以後，可能需要很長時間地去恢復。它為了避免隨機IO不將資料刷盤，轉而順序寫出日誌。系統恢復時要先拿到一個檢查點，然後從檢查點開始去掃描日誌，把日誌記錄拿出來，一條條地重放。資料量大的時候，這是相當耗時的一個工作。

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

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

• TPC-C benchmark

他們對採用不用演算法的系統的恢復時間做了一個比較，可以看到write-behind Logging的恢復時間，大概可以達到即時恢復的效果。系統起來，馬上就可以對外提供服務，但這個協議是專門針對非易失性記憶體而設計的，在這個磁碟SSD上，效能比較差。在這個NVM上，WBL的效能有30%左右的提升。

總結

1. 應用需求、行業資料以及計算機硬體是拉動這個資料庫系統發展的三駕馬車；
2. 在這個多核與記憶體計算的時代下，系統設計人員更應該將精力放在系統的擴充套件性上，更應該注重資料訪問的區域性性，克服所謂的記憶體牆問題；
3. 此外，NVM的出現可能會顛覆系統架構。它的出現使得系統設計人員可以將注意力完全地從I/O上移除，專注系統擴充套件性設計。

狄更斯說：“這是最壞的時代，同時也是最好的時代”，這個時代給了我們挑戰，同時也為資料庫系統從業人員帶來了機遇！

Q&A

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

答：現在這個應用的場景，簡單來說可以提升IO效能，例如用來儲存日誌，可以快速提升系統性能。還有就是在大資料分析的場景，用來提升系統的IO能力。

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

答：騰訊現在有在做這一塊的優化，英特爾年初推出了相應的硬體，這個硬體我們也拿到了，也在做相關的優化。跟著社群，我們也在做一些交流來提升系統的擴充套件性的問題。

追問：騰訊在資料庫這邊有支援和服務？

答：現在我們還沒有放到雲上去，目前在內部做一些相應的開發。很快就會在雲上推出相關產品。

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

答：有，這都是開源的。

追問：哪裡可以拿到？

答：PG或者MySQL社群裡面，這些優化都是會提交到社群裡面的。

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

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

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

答：對，他們的應用場景不同。TPCC是衡量一個事務型資料庫，到底能達到一個什麼樣效能的標準，這個比較具有說服力。

原文來自微信公眾號：DBAplus社群