配置記憶體中OLTP檔案組提高效能

2021-09-26 05:12:15 字數 3087 閱讀 6485

在今天的文章裡,我想談下使用記憶體中oltp的記憶體優化檔案組來獲得永續性,還有如何配置它來獲得高效能。在進入正題前,我想簡單介紹下使用你資料庫裡這個特定檔案組,記憶體oltp是如何獲得永續性的。

早些天對記憶體中oltp(代號hekaton)的乙個大誤解是,人們認為記憶體中oltp是不具有acid屬性的——只有aci屬性,沒有d屬性(durability)。但這不是真的,因為在記憶體中oltp裡,每個在記憶體中的操作都是完全日誌的。如果你的資料庫崩潰,記憶體中oltp可以將你的資料庫和記憶體優化表在崩潰發生前恢復常態。記憶體中oltp記錄每個操作到傳統sql server的事務日誌。因為在非永續性記憶體裡發生的一切都是基於mvcc原則,記憶體中oltp只記錄重做(redo)日誌記錄,任何時間都沒有撤銷(undo)日誌,因為用記憶體中oltp在故障恢復期間從不會有撤銷操作發生。對進行中的事務進行回滾操作,只有前版本才是可以的。

當事務的提交時,重做(redo)日誌才會寫入。另外所謂的離線檢查點工作者(offline checkpoint worker)將成功提交的事務從事務填入一對所謂的資料和delta檔案(data and delta files),來自記憶體中oltp的資料和delta檔案會加速故障恢復。故障恢復重建你的記憶體優化表初始於資料和delta檔案對,然後自上個檢查發生的所有改變從事務日誌裡應用。我們來看下這個概念。

因為在記憶體oltp裡一切都是和高效能有關,資料和delta檔案sql server只用順序讀寫(sequential i/o)。不會涉及到隨機讀寫(random i/o),因為這會殺死效能。現在的問題是,什麼資訊會寫入資料和delta檔案對?記憶體中oltp資料檔案包含插入到記憶體優化表的記錄。因為插入只發生在檔案末尾,順序讀寫很容易實現。當你在記憶體優化表刪除指定記錄時,記錄只在對應的delta檔案邏輯上標記為刪除。這個資訊也是加在delta檔案末尾,這樣又是真正的在儲存裡順序讀寫。update語句只是新記錄和老記錄副本insert語句和delete語句的組合。很簡單,是不是?下圖展示了這個重要概念。

如果你想進一步了解記憶體中oltp如何實現永續性的,我強烈推薦tony rogerson寫的文章how hekaton (xtp) achieves durability for 「memory optimised」 tables。

記憶體優化表的故障恢復以你資料和delta檔案對儲存的速度進行。因此當你建立資料庫,當考慮並決定配置儲存檔案對的記憶體中oltl檔案組,仔細對待就非常重要。首先你要包含記憶體優化資料的儲存增加檔案組,如下**所示:

--

add a new memory optimized file group

alter

database

inmemoryoltp

add filegroup inmemoryoltpfilegroup contains

memory_optimized_data

go

在記憶體優化檔案組建立後(在傳統filestream檔案組覆蓋下),你可以新增儲存容器(storage container)到檔案組。這裡你可以使用add file命令,如下**所示:

1

--add a new storage container

2alter

database inmemoryoltp add

file3(

4 name = n'

inmemoryoltpcontainer',

5 filename = n'

c:\program files\microsoft sql server\mssql12.sql2014\mssql\data\inmemoryoltpcontainer'6

)7to filegroup [

inmemoryoltpfilegroup]8

go

估計你現在網上看到的所有文章裡都只介紹增加1個儲存容器——這會大大傷及你的效能!原因很簡單:

為了克服這些限制,你可以新增多個屬於記憶體優化檔案的儲存容器在不同的「物理」硬碟上。這樣的話,資料和delta檔案在多個儲存容器間會以迴圈(round-robin)樣式分配。假設配置2個儲存容器會發生什麼:

下圖給你具體演示了這個概念。

但是只使用2個儲存容器並不解決你的磁碟瓶頸問題,因為只有2個容器,所有的資料檔案儲存在第1個容器,所有的delta檔案儲存在第2個容器。一般來說,你的資料檔案比你的delta檔案會多很多,這就是說在不同物理硬碟上的2個儲存容器之間的讀寫很不平衡。儲存你所有資料檔案的第1個儲存容器比儲存你所有delta檔案的第2個容器需要更多的iops。

為了多個物理硬碟之間iops平均分布與平衡。對於你的記憶體優化檔案組,微軟推薦至少4個儲存容器。當你有4個儲存容器時,想象下會發生什麼,如下圖所示:

如果你使用這個配置,在第1個物理硬碟上你有第1個檔案對(資料和delta檔案),在第2個物理儲存上你有第2個檔案對(資料和delta檔案),在第1個物理硬碟上你有第3個檔案對(資料和delta檔案),以此類推。最後你在多個物理硬碟鍵平均散布了你的讀寫請求,這會加速你的故障恢復程序,因為故障恢復可以在儲存容器裡並行,這會加速你資料庫聯機。

在這個檔案裡你看到對於記憶體中oltp,儲存速度和吞吐量還是非常重要的。在儲存裡,你的資料必須是物理永駐的,不然當你的sql server崩潰或重啟時,你的資料就會丟失。你記憶體優化檔案組配置會大大影響檔案組給你的吞吐量。如果你在生產環境執行記憶體中oltp,你應該至少配置4個儲存容器分布在2個物理硬碟。在效能要求更高的場景,你甚至可以增加超過2個物理硬碟的更多儲存容器。正如微軟說的:「記憶體中oltp的故障恢復是以你儲存速度進行的」。

感謝關注!

配置記憶體中OLTP檔案組提高效能

在今天的文章裡,我想談下使用記憶體中oltp的記憶體優化檔案組來獲得永續性,還有如何配置它來獲得高效能。在進入正題前,我想簡單介紹下使用你資料庫裡這個特定檔案組,記憶體oltp是如何獲得永續性的。早些天對記憶體中oltp 代號hekaton 的乙個大誤解是,人們認為記憶體中oltp是不具有acid屬...

為什麼我還不推薦記憶體中OLTP給使用者

嗯,有些人在看玩這篇文章後會恨我,但我還是要說。1個月來我在記憶體中oltp這個裡領域裡做了大量的工作,很多使用者都請求使用這個驚豔的新技術。遺憾的是,關於記憶體中oltp沒有乙個是真的令人激動的 看完你就知道了。沒有!真的!我喜歡這個驚豔的新技術,但我還不能推薦它給任何使用者。就這樣!很有使用者現...

利用Linux檔案系統記憶體cache來提高效能

利用linux檔案系統記憶體cache來提高效能 本地磁碟檔案 socket傳送,4步驟資料流向 左右圖的上部分為user和kernel的上下文切換。下部分為資料流向圖,其中左圖為正常流程中linux從檔案系統讀取檔案然後通過socket傳送的流程,其中共經歷了4次記憶體拷貝 右圖為改進版本,通過m...