SQL Server 記憶體中OLTP內部機制概述（一）

標籤：style   blog   http   io   os   使用   ar   檔案   資料   

----------------------------我是分割線-------------------------------

本文翻譯自微軟白皮書《SQL Server In-Memory OLTP Internals Overview》：http://technet.microsoft.com/en-us/library/dn720242.aspx

 

----------------------------我是分割線-------------------------------

 

SQL Server 記憶體中OLTP內部機制概述

 

摘要：

記憶體中OLTP（項目名為“Hekaton”）是一個新的完全整合到SQL Server中的資料庫引擎組件。它專為訪問記憶體駐留資料的OLTP工作負載而進行最佳化。記憶體中OLTP有助於OLTP工作負載實現顯著的效能改進，並減少了處理時間。可以通過將表聲明成“記憶體中最佳化”來啟用記憶體中OLTP的功能。記憶體最佳化表完全支援事務，並且可以使用Transact-SQL進行訪問。 Transact-SQL預存程序可以被編譯成機器代碼從而進一步提升記憶體最佳化表的效能。引擎針對高並發進行設計，並使阻塞最小化。

簡介

在最初設計SQL Server的時候假定主記憶體是非常昂貴的，因此除非當資料確實需要進行處理，否則資料都駐留在磁碟上。由於記憶體價格在過去的30年中已經大幅下降，這種假設已不再有效。與此同時，多核伺服器也已不再昂貴，所以如今人們只需花費不到5萬美元就可以購買到擁有32個核心和1TB記憶體的伺服器。由於生產環境的許多（儘管並不是絕大多數）OLTP資料庫能夠完全裝進1TB的記憶體中，我們需要重新評估將資料存放區在磁碟上的好處，以及當讀取資料到記憶體中進行處理時所導致的I/O開銷。此外，OLTP資料庫在更新資料並且需要將資料寫回到磁碟時，也會產生開銷。記憶體最佳化表的儲存方式與基於磁碟的表完全不同，並且這些新的資料結構有助於更加有效地訪問和處理資料。

由於更多可用記憶體和更多核心的這種趨勢，微軟SQL Server團隊開始構建一種針對大量主記憶體和多核CPU進行最佳化的資料庫引擎。本文給出了這個新的資料庫引擎功能：記憶體中OLTP的技術概述。

有關記憶體中OLTP的更多資訊，請參閱在記憶體內部 OLTP（記憶體中最佳化）。

 

設計注意事項與目的

開發一個真正的記憶體資料庫的舉動由三種基本的需求所驅動：1）將工作負載所需的大部分或全部資料放到記憶體中，2）對於資料操作更低的延遲時間，3）針對特定類型的工作負載的專業資料庫引擎需要為那些工作負載進行最佳化。摩爾定律已經影響了記憶體的成本，允許主記憶體足夠大以滿足需求（1）及部分滿足需求（2）。 （更大的記憶體降低了讀取的延遲，但並沒有影響傳統資料庫系統所需的寫入到磁碟需要的延遲）。記憶體中OLTP的其他功能大大提高了資料修改操作的延遲。專為特定類型工作負載設計的系統能夠比通用系統資料表現優異10倍或者10倍以上，正是這樣的認知驅動了專業資料庫引擎的需求。最專業的系統，包括那些用於複雜事件處理（CEP, Complex Event Processing），DW/BI和OLTP的系統，都通過專註於記憶體中的結構來最佳化資料結構和演算法。

微軟之所以開發了記憶體中OLTP的功能，主要來源於這樣一個事實即主記憶體大小正以極快的速度增長，並變得更加便宜。此外，由於64位架構和多核處理器的普及，有理由認為大多數（儘管並不是所有）OLTP資料庫或者對效能敏感的整個工作資料集可以完全在記憶體中駐留。最大的金融，線上零售和航空訂票系統中的許多系統的大小降低至500GB與5TB之間，工作集也顯著變小。截至2012年，即使是一個雙插槽伺服器也可以通過採用32GB的DIMMs（Dual In-line Memory Module）來容納2TB 的DRAM（Dynamic Random Access Memory）（比如IBM x3680 X5）。展望未來，在未來幾年內，以不到5美元/GB的成本來構建擁有1-10 PB容量的基於DRAM的分布式系統，是完全有可能的。非易失性的RAM變為可行也只是一個時間問題。

如果一個應用程式的大多數或所有資料都能夠完全駐留在記憶體中，那麼SQL Server最佳化器從最初版本就開始使用的成本計算規則將變得幾乎完全過時，因為規則假定所有訪問的資料頁都可能需要從磁碟進行物理讀。如果不需要從磁碟進行讀取，最佳化器則可以使用不同的成本計算演算法。此外，如果沒有磁碟讀取所需的等待時間，其他等待的統計資訊，比如等待鎖被釋放，等待閂鎖可用或者等待日誌寫入完成，就會變得無比龐大。記憶體中OLTP解決了所有的這些問題。記憶體中OLTP消除了等待鎖釋放的問題，採用了一種新型的多版本開放式並行存取控制。記憶體中OLTP產生比原先少得多的日誌資料，並且只需要更少的日誌寫入，從而減少了等待日誌寫入的延遲。

 

術語

SQL Server 2014的記憶體中OLTP功能涉及到一系列與使用記憶體最佳化表相關的技術。與記憶體最佳化表相對的表將被稱為基於磁碟的表，這正是SQL Server一直所提供的。使用的術語包括：

• 記憶體最佳化表：是指採用了新的資料結構的表，這種資料結構作為記憶體中OLTP的一部分，將在本文中詳細描述。
• 基於磁碟的表：與記憶體最佳化表相對，採用SQL Server此前一直使用的資料結構，以從磁碟讀取和寫入所需的8K大小的資料頁作為一個單元。
• 原生編譯的預存程序：是指記憶體中OLTP功能支援的一種物件類型，被編譯為機器代碼，並且比起只使用記憶體最佳化表，原生編譯的預存程序有進一步增進效能的潛力。與之對應的是SQL Server此前一直使用的解釋型的Transact-SQL預存程序。原生編譯的預存程序只能引用記憶體最佳化表。
• 交叉容器事務：是指同時引用記憶體最佳化表和基於磁碟的表的事務。
• 互操作：是指引用記憶體最佳化表的解釋型的Transact-SQL

 

功能概述

在使用記憶體中OLTP對資料進行大多數的處理操作時，你可能並不會察覺到正在使用的是記憶體最佳化表而不是基於磁碟的表。但是，如果資料存放區在記憶體最佳化表中，SQL Server處理資料的方式非常不同。在本節中，我們將看到與SQL Server中基於磁碟的操作和資料不同的記憶體中OLTP運作原理和資料處理方式的概述。我們也將簡單介紹來自於競爭者的一些記憶體最佳化資料庫的解決方案，並指出SQL Server的記憶體中OLTP與它們的區別。

 

記憶體中OLTP有何特殊之處

雖然記憶體中OLTP與SQL Server關聯式引擎整合，並且可以使用相同的介面透明地進行訪問，但它的內部行為和功能有很大的不同。圖1給出了包含記憶體中OLTP組件的SQL Server引擎的概述。

圖1  包含記憶體中OLTP組件的SQL Server引擎

 

請注意，對於記憶體最佳化表或者基於磁碟的表，無論是將調用本地編譯的預存程序或解釋型的Transact-SQL，用戶端應用程式串連到TDS處理常式都採用相同的方式。你可以看到，解釋型的Transact-SQL可以使用互操作功能來訪問記憶體最佳化表，但本地編譯預存程序只能訪問記憶體最佳化表。

記憶體最佳化表

記憶體最佳化表和基於磁碟的表之間最重要的區別是，當訪問記憶體最佳化表時，資料頁不需要從磁碟讀入快取。所有的資料都始終被儲存在記憶體中。僅用於恢複的目的的檢查點檔案組（資料和差異檔案對）建立在駐留在記憶體最佳化檔案組中的檔案中，記錄了資料更改的跟蹤，而檢查點檔案是只能被附加的。

在記憶體最佳化表上的操作與在基於磁碟的表的操作使用同樣的交易記錄，和往常一樣，交易記錄被儲存在磁碟上。萬一系統崩潰或者伺服器關機，記憶體最佳化表中的資料行可以通過檢查點檔案和交易記錄重建。

通過使用一個名為SCHEMA_ONLY的選項，記憶體中OLTP能夠選擇建立一個非持久的和不記錄日誌的表。如這個選項名所示，即便資料是非持久的，表架構也將是持久的。這些表在交易處理期間不需要任何IO操作，但是只有當SQL Server運行時，資料在記憶體中可用。一旦SQL Server關機或者AlwaysOn可用性群組進行容錯移轉，這些表中的資料會丟失。當它們所屬的資料庫進行恢複時，表將會被重建，而表中沒有資料。這些表可能會是有用的，例如，ETL情境裡的暫存資料表或者用於儲存Web伺服器工作階段狀態的暫存資料表。雖然資料是非持久的，但這些表上的操作符合事務其他所有的要求：原子性，隔離性和一致性。我們將會在建立表的章節看到建立一個非持久表的文法。

記憶體最佳化表上的索引

記憶體最佳化表上的索引並不按照傳統的B樹結構進行儲存。記憶體最佳化表支援非叢集雜湊索引，非叢集雜湊索引以雜湊表的方式儲存，雜湊表中擁有將相同雜湊值的所有資料行與記憶體最佳化的非叢集索引串連起來的連結清單，而記憶體最佳化的非叢集索引使用的是特殊的BW樹進行儲存。非叢集雜湊索引針對點尋找進行最佳化，而記憶體最佳化非叢集索引則為檢索值的範圍和行排序提供支援，並最佳化了使用不等謂詞的查詢的效能。

每個記憶體最佳化表都必須至少有一個索引，因為正是索引將所有資料行組合成一張表。記憶體最佳化表永遠不會像基於磁碟的堆表那樣儲存成無組織的資料行集合。

索引永遠不會儲存在磁碟上，在磁碟上的檢查點檔案中也不會體現，並且在索引中的操作永遠不會被日誌記錄。與基於磁碟的表上的B樹索引相同，在記憶體最佳化表上的所有修改操作發生時，索引是自動進行維護的，但一旦SQL Server重新啟動，由於資料會載入到記憶體中，則記憶體最佳化表上的索引會被重建。

並發性的改進

當訪問記憶體最佳化表時，SQL Server實現了一個樂觀的多版本並發控制。儘管SQL Server以前通過在SQL Server 2005中引入的基於快照的隔離等級，從而號稱支援開放式並行存取控制，但這些所謂的樂觀方式在資料修改操作的過程中的確需要擷取鎖。對於記憶體最佳化表，不需要擷取鎖，從而沒有因為阻塞而產生的等待。

注意，這並不意味著在使用記憶體最佳化表時，不可能產生等待。仍會存在其他等待類型，比如在事務結束時等待日誌寫入完成。不過，在對記憶體最佳化表變更時，記憶體最佳化表的日誌記錄比起基於磁碟的表更有效率的多，因此等待時間會更短。而且從磁碟讀取資料永遠不會有等待，也沒有因為資料行上的鎖而產生的等待。

本地編譯的預存程序

當使用擁有記憶體最佳化表的原生編譯的預存程序時，能獲得最好的執行效能。不過，相對於解釋型的代碼可供使用的豐富的功能集，本地編譯預存程序內部允許的Transact-SQL語言結構有一些限制。此外，原生編譯預存程序只能訪問記憶體最佳化表，並不能引用基於磁碟的表。

記憶體中OLTP僅僅只是DBCC PINTABLE的改進？

DBCC PINTABLE是舊版本的SQL Server提供的功能，一旦資料頁從磁碟中讀取，這張被“固定”的表裡的任何資料頁就不會從記憶體中移除。這些資料頁需要被初始化讀取，所以這樣的表被訪問總是會有第一次讀取資料頁的成本。這些固定的表與任何其他基於磁碟的表並無任何不同。它們需要相同數量的鎖、閂鎖和日誌記錄，也使用相同的索引結構，這些索引同樣也需要鎖和日誌記錄。記憶體中OLTP的記憶體最佳化表與SQL Server的基於磁碟的表則完全不同，它們使用不同的資料和索引結構，不使用鎖，並且日誌記錄這些記憶體最佳化表的更改比起基於磁碟的表效率更高。

競爭者的產品

對於處理OLTP資料，有兩種類型的專業引擎。第一類是主記憶體資料庫。 Oracle有TimesTen，IBM有solidDB，還有許多其它產品主要是針對嵌入式資料庫空間。第二類是應用程式快取或者KVStore for Redis（例如，Velocity–App Fabric Cache和GigaSpaces），利用應用程式和中介層的記憶體來降低資料庫系統的工作負載。這些緩衝逐漸層得更為複雜，並擁有類似事務、範圍索引和查詢這樣的資料庫功能（例如GigaSpaces已經擁有了這些功能）。同時，資料庫系統擁有緩衝功能，比如高效能雜湊索引和跨多伺服器叢集的擴充（比如VoltDB）。記憶體中OLTP引擎意在提供這兩種類型引擎中各自的優點。可以認為記憶體中OLTP擁有緩衝的效能和資料庫的功能。它支援在記憶體中儲存表和索引，這樣你就可以將整個資料庫建成一個完整的記憶體中的系統。它也提供了高效能索引和日誌記錄，以及其它特性以顯著提高查詢的執行效能。

SQL Server的記憶體中OLTP提供了極少競爭者產品能夠提供的以下功能：

• 記憶體最佳化表和基於磁碟的表之間的整合，遷移到記憶體駐留資料庫可以逐步進行，只將最關鍵的表和預存程序建立成記憶體最佳化的對象。
• 原生編譯的預存程序為基本的資料處理操作的執行時間提供了數量級的改進
• 記憶體最佳化的非叢集雜湊索引和記憶體最佳化的非叢集索引都專門為主記憶體訪問進行了最佳化
• 不在資料頁上儲存資料，不需要資料頁閂鎖。
• 對任何操作都沒有鎖或者閂鎖的真正多版本開放式並行存取控制

SQL Server記憶體中OLTP與競爭者產品設計最顯著的區別是“互操作”的整合。在一個典型的高端OLTP工作負載中，效能瓶頸主要集中在一些特定的地區，比如一小部分的表和預存程序。迫使將整個資料庫駐留在記憶體中將是昂貴和低效的。但到目前為止，其他主要的競爭產品都採用這種方法。對於SQL Server，高效能和高競爭地區可以遷移到記憶體中OLTP，那麼在這些記憶體最佳化表上的操作（預存程序）可以在本地進行編譯從而達到最大的業務處理效能。

記憶體中OLTP改進的另一個關鍵是移除了記憶體最佳化表的資料頁結構。這從根本上將資料操作演算法從基於磁碟最佳化改變成基於記憶體和緩衝最佳化。正如前面提到的，關於記憶體中OLTP的困惑之一是，它只像“DBCC PINTABLE”那樣簡單的將表鎖定在緩衝池中。然而，即使資料頁被強制駐留記憶體中時，許多競爭產品仍然採用資料頁結構。例如SAP的HANA仍使用16KB大小的資料頁來處理記憶體中資料行的儲存，在高效能環境下，這從本質上仍需要忍受資料頁閂鎖爭用的影響。

 

---------------------------待續-------------------------------

 

SQL Server 記憶體中OLTP內部機制概述（一）