窺鏡下的OLTP以及我們的發現(一)

作者：Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, Michael Stonebraker

聯機事務處理 (OLTP) 數據庫包含一系列針對 20 世紀 70 年代的計算機技術而優化的功能 —— 磁盤 B 樹和堆文件、基于鎖的并發控制、多線程支持等等。現代處理器、存儲器和網絡的進步意味著，今天的計算機與 30 年前的計算機大為不同，以至于現在許多 OLTP 數據庫都可以放在主存儲器，并且大多數 OLTP 事務可以在幾毫秒甚至更短的時間內得到處理。然而，數據庫架構幾乎沒有發生變化。

基于這一觀察，我們研究了傳統數據庫系統一些有趣的變體，人們可以構建它們來利用最近的硬件趨勢，然后我們使用一個事務處理數據庫系統 (Shore) 來運行 TPC-C 基準程序的一個子集，并通過這個系統所涉及的主要組件的詳細指令級分解來推測它們的性能。我們沒有簡單地剖析 Shore ，而是逐步地修改它，以便在每次功能刪除或優化之后，我們都有一個（更快的）工作系統來完整運行我們的工作負載。總的來說，我們確定了可以解釋原始性能存在大約 20 倍差異的開銷和優化。我們還證明，現代（內存駐留）數據庫系統沒有單個的 “ 瓶頸 ” ，但日志記錄、鎖存、封鎖、 B 樹和緩沖區管理操作上花費了大量時間。

分類和主題詞

H.2.4 [ 數據庫管理 ] ：系統 —— 事務處理；并發。

通用術語

測量、性能、實驗。

關鍵詞

聯機事務處理、 OLTP 、主存儲器事務處理、數據庫管理系統架構。

1. 前言

現代通用在線事務處理 (OLTP) 數據庫系統包括一組標準功能：一系列用于表存儲的磁盤數據結構（包括堆文件和 B 樹），通過基于鎖的并發控制支持多個并發查詢，基于日志的恢復和高效的緩沖區管理器。人們開發這些功能來支持 20 世紀 70 和 80 年代的事務處理，那時的 OLTP 數據庫比主存儲器大很多倍，而運行這些數據庫的計算機成本高達數十萬到數百萬美元。

如今的情況則完全不同。首先，現代處理器運行速度非常快，以至于很多 OLTP 事務的計算時間以微秒計算。人們只需幾千美元就可以購買到主存儲器容量為數 GB 的系統。此外，組織機構擁有由眾多此類工作站組成的網絡集群并不罕見，其中的存儲器總容量以數百 GB 來計算，這足以將許多 OLTP 數據庫放在隨機存取存儲器中。

其次，因特網的興起和用于眾多領域的各種數據密集型應用程序導致人們對類似于數據庫的應用程序的興趣越來越大，而這些應用程序沒有全套的標準數據庫功能。如今，操作系統和網絡會議充滿了針對 “ 類似于數據庫 ” 的存儲系統的方案，這些存儲系統具有不同形式的一致性、可靠性、并發性、復制性和查詢能力 [DG04, CDG+06, GBH+00, SMK+01] 。

這種對類似于數據庫的服務的需求增長以及顯著的性能改善和硬件成本的下降表明，人們可以構建大量有趣的替代系統，這些替代系統具有與標準的 OLTP 引擎所提供的功能完全不同的功能集。

1.1 可供選擇的 DBMS 架構

顯然，當一個數據庫可以放在 RAM 時，針對主存儲器優化 OLTP 系統是一個好主意。但是眾多其他的數據庫變體是可能存在的；例如：

無日志數據庫。 無日志數據庫系統可能不需要恢復，或者可能從集群中的其他站點執行恢復（如在 Harp [LGG+91] 、 Harbor [LM06] 和 C-Store [SAB+05] 等系統中建議的那樣）。

單線程數據庫。 由于 OLTP 數據庫中的多線程在傳統上對于慢速磁盤寫入時的延遲隱藏十分重要，因此在內存數據庫系統中，它并不那么重要。在某些情況下，一個單線程實現可能就已經足夠了，尤其是在它能夠提供優良性能的情況下。盡管人們需要

一種方法來利用相同硬件上的多個處理器內核，但虛擬機技術的最新進展提供了一種方法來使這些內核看起來像是獨特的處理節點，同時不會產生大量的性能開銷 [BDR97] ，這可能讓這些設計具有可行性。

無事務型數據庫。 很多系統并不需要事務支持。尤其是在分布式網絡應用中，最終一致性通常比事務一致性更受歡迎 [Bre00, DHJ+07] 。而在其他情況下，例如，當所有的讀取需要在寫入之前完成時，輕量級事務可能是可以接受的 [AMS+07, SMA+07] 。

實際上，數據庫社區內部已經提出了幾個方案來構建具有部分或全部上述特性的數據庫系統 [WSA97, SMA+07] 。然而，一個待解決的問題是，如果這些不同的配置被實際構建出來的話，它們的性能表現會有多好。這是本白皮書的中心問題。

1.2 測量 OLTP 的開銷

為了理解這個問題，我們選擇了一個現代開源數據庫系統（ Shore—— 參閱 http://www.cs.wisc.edu/shore/ ），并在 TPC-C 基準測試程序的一個子集上對它進行基準測試。我們在一個現代臺式機上進行的初始實現每秒運行大約 640 個事務 (640 TPS) 。然后我們通過從引擎中逐一移除不同的功能來修改它，并在每一步進行新的基準測試，直到我們得到一個可以處理 12700 TPS 的查詢處理代碼的微內核。這個內核是一個單線程、無鎖、不帶恢復功能的主存儲器數據庫系統。在這個分解過程中，我們確定了四個主要組件，將它們移除后，系統的處理能力得到大幅改善：

日志記錄。 匯編日志記錄和追蹤數據庫結構中的所有更改導致系統性能下降。如果沒有可恢復性需求，或者可恢復性可以通過其他方式（例如，網絡上的其他站點）來實現，日志記錄可能不再必要。

封鎖。 由于對數據庫結構的所有訪問均由一個單獨的實體（鎖管理器）管理，傳統的兩階段封鎖會造成相當大的開銷。

鎖存。 在多線程數據庫中，許多數據結構必須在被鎖存之后才能被訪問。移除這項功能并進入一種單線程方法后，性能受到顯著影響。

緩沖區管理。 主存儲器數據庫系統并不需要通過一個緩沖池來訪問頁面，從而在每個記錄訪問時消除一個中間層。

1.3 結果

圖 1 展示了這些修改的每一項如何影響 Shore 的底線性能（依照每個 TPC-C 新訂單事務的 CPU 指令）。我們可以看到

底部虛線是有用的工作，通過在無開銷的內核上執行事務來度量。

每一個子系統本身占總運行時的 10% 到 35% （此圖的總高度代表 173 萬個指令）。在這里， “ 手工編碼的優化 ” 代表我們對代碼進行的一系列優化，這些優化主要改善了 B 樹包的性能。實際用來處理查詢的指令（標記為 “ 有用的工作 ” ，通過我們在手工編碼的主存儲器 B 樹包上構建的最小實現來度量）只有上述數據的 1/60 。 “ 緩沖區管理器 ” 下方的白色框代表我們移除所有功能之后的 Shore 版本，它仍然能夠運行事務，但它使用的指令大約只有原始系統的 1/15 ，或者大約是有用的工作中的指令數量的 4 倍。在我們的實現中，額外開銷歸因于 Shore 的調用堆棧深度，以及我們不能完全去掉對事務和緩沖區管理器的所有引用。

圖 1. 各種 DBMS 組件針對 TPC-C 新訂單事務的指令數的分解。條形圖的頂部是原始 Shore 的性能（主存數據庫，無線程爭用）。

1.4 本白皮書的貢獻和組織結構

本白皮書的主要貢獻在于： 1) 仔細分析時間消耗在現代數據庫系統中的什么地方； 2) 仔細地測量現代數據庫系統各種精簡變體的性能； 3) 使用這些測量結果來推測人們能夠構建的各種數據管理系統的性能，例如沒有事務或日志的系統。

本白皮書其余部分的組織結構如下所述。在第 2 部分，我們將討論可能很快被淘汰（或者已經被淘汰）的 OLTP 功能。在第 3 部分，我們將探討 Shore DBMS （它是我們整個探索過程的起點），并描述我們進行的分解。第 4 部分含有我們使用 Shore 進行的實驗。然后在第 5 部分，我們將使用測量結果討論這對未來 OLTP 引擎的影響，并推測一些假設的數據管理系統的性能。我們將在第 6 部分介紹其他的相關工作，并在第 7 部分進行總結。

2. 關于 OLTP 的趨勢

如在前言中所述，大多數常見的關系型數據庫管理系統 (RDBMS) 起源于在 20 世紀 70 年代開發的系統，并且包含諸如基于磁盤的索引和堆文件、基于日志的事務和基于鎖的并發控制之類的功能。然而，自人們做出這些架構決策算起，已經過去 30 年了。與這些傳統系統問世的時代相比，如今的計算世界已經大為不同；本部分的目的在于探索這些不同之處的影響。我們曾在 [SMA+07] 中進行過一系列相似的觀察。

2.1 集群計算

當前一代的大多數 RDBMS 最初是在 20 世紀 70 年代為共享內存的多處理器設計的。很多廠商在 20 世紀 80 年代增加了對共享磁盤架構的支持。在過去的二十年里，我們已經見證了類似于 Gamma 的無共享數據庫 [DGS+90] 的出現，以及針對許多大型計算任務的商用計算機集群的興起。未來的所有數據庫系統都必須從頭開始設計來運行這些集群。

2.2 內存數據庫

鑒于 RAM 容量在過去幾十年里的急劇增長，我們有充分的理由相信，很多 OLTP 系統已經或很快將會被放入內存，尤其是大型集群的聚合內存。這在很大程度上歸因于大多數 OTLP 系統的尺寸沒有像 RAM 容量一樣在顯著增長，因為它們記錄的信息所涉及到的客戶、產品和其他現實世界實體的數量并沒有按照摩爾定律來增長。鑒于這種情況，數據庫廠商創建能夠優化內存系統常見用例的系統是有道理的。在這些系統中，考慮優化的索引 [RR99, RR00] 以及避免磁盤優化的元組格式和頁面布局（或者缺乏它們） [GS92] 十分重要。

2.3 OLTP 系統中的單線程

所有現代數據庫包含對多線程的廣泛支持，包括一系列事務并發控制協議以及使用鎖存命令廣泛滲透它們的代碼來支持多線程訪問緩沖池和索引頁等共享結構。多線程的傳統動機在于允許一個事務進行事務處理，同時讓另一個事務等待來自磁盤的數據，并防止長時間運行的事務阻礙短時間運行的事務取得進展。

我們斷言，所有這些動機都不再有效。首先，如果數據庫駐留在內存中，那就不再需要等待來自磁盤數據。此外，生產事務系統不含任何用戶等待 —— 事務幾乎完全通過存儲的程序來執行。其次， OLTP 工作負載十分簡單。一個典型的事務由一些索引查找和更新組成，在內存系統中，這些索引查找和更新可以在數百微秒內完成。此外，隨著現代數據庫行業分叉為一個事務處理和一個數據倉庫市場，長期運行（分析）的查詢現在由數據倉庫提供服務。

我們關心的一個問題就是，多線程需要支持配有多個處理器的機器。然而，我們認為，這個問題的解決方式可以是，把擁有多個處理器的一個物理節點當作一個無共享集群中的多個節點來處理，這可能是由一個虛擬機監視器來進行管理，而這個監視器可以動態地在這些邏輯節點之間分配資源 [BDR97] 。

另一個問題是，網絡將會變成新磁盤，從而將延遲引入分布式事務并且需要事務的重新引入。在普通情況下，這個問題無疑是存在的，但對于很多事務應用來說，劃分工作負載使其成為 “ 單站點 ”[_ Hel07, SMA+07] 負載是可能的，這樣所有的事務可以完全在集群的一個單一節點上運行。

因此，某些類別的數據庫應用將不需要支持多線程；在這些數據庫系統中，傳統的封鎖和鎖存代碼成為不必要的開銷。

2.4 高可用性與日志記錄

產品事務處理系統需要 24x7 全天候的可用性。為此，大多數系統使用某種形式的高可用性，本質上是使用兩倍（或更多倍）的硬件來確保在發生故障時有一個可用的備用品。

最近的論文 [LM06] 指出，至少對于倉庫系統來說，利用這些可用的備用品來促進恢復是可能的。特別是，我們可以通過從其他數據庫副本復制丟失狀態來完成恢復，而不是使用 REDO 日志。在我們之前的研究中，我們已經聲稱這也可以用于事務系統 [SMA+07] 。如果事實確實如此的話，那么傳統數據庫中的恢復代碼也將成為不必要的開銷。

2.5 事務變體

盡管很多 OLTP 系統明確需要事務語義，但最近出現了一些針對具有弱一致性的數據管理系統的方案，特別是在互聯網領域。通常，我們相信可用性比事務語義更為重要，因此我們需要的是某種形式的最終一致性 [Bre00, DHJ+07] 。此類環境的數據庫可能不太需要針對事務（例如日志、鎖、兩階段提交等）開發的機器。

即使有人需要某種嚴格一致性，也是可能存在很多弱一致性模型的。例如，快照隔離（非事務型）的廣泛采用表明，很多用戶愿意用事務語義來換取性能（就此例而言，歸因于讀鎖的消除）。

最后，最新的研究表明，數量有限的一些事務形式需要的機器遠少于標準數據庫事務所需要的機器。例如，如果所有的事務都是 “ 兩階段 ” ，即它們在任何寫入操作之前執行它們的所有讀取操作，并得到在完成讀取之后不會中止的保證，那么 UNDO 日志沒有存在的必要 [AMS+07, SMA+07] 。

2.6 總結

如我們的參考文獻所示，一些研究小組，包括 _ Amazon [DHJ+07] 、 HP [AMS+07] 、 NYU [WSA97] 和 MIT

[SMA+07] ，已經展示了他們對構建與經典 OTLP 設計之間存在本質區別的系統的興趣。特別是， MIT H-Store [SMA+07] 系統證明，移除所有上述功能可以在事務吞吐量方面帶來兩個數量級的加速，這表明其中一些數據庫變體很有可能提供卓越的性能。因此，傳統的數據庫廠商似乎有必要考慮生產明確禁用這些功能的產品。為了幫助這些實踐者理解他們可能考慮構建的不同變體的性能影響，我們繼續對 Shore 以及我們構建的它的變體進行詳細的性能研究。

(待續)