在今天的文章里，我想談下使用內存中OLTP的內存優(yōu)化文件組來獲得持久性，還有如何配置它來獲得高性能。在進入正題前，我想簡單介紹下使用你數據庫里這個特定文件組，內存OLTP是如何獲得持久性的。

早些天對內存中OLTP（代號Hekaton）的一個大誤解是，人們認為內存中OLTP是不具有ACID屬性的——只有ACI屬性，沒有D屬性（Durability）。但這不是真的，因為在內存中OLTP里，每個在內存中的操作都是完全日志的。如果你的數據庫崩潰，內存中OLTP可以將你的數據庫和內存優(yōu)化表在崩潰發(fā)生前恢復常態(tài)。內存中OLTP記錄每個操作到傳統(tǒng)SQL Server的事務日志。因為在非持久性內存里發(fā)生的一切都是基于MVCC原則，內存中OLTP只記錄重做（redo）日志記錄，任何時間都沒有撤銷（undo）日志，因為用內存中OLTP在故障恢復期間從不會有撤銷操作發(fā)生。對進行中的事務進行回滾操作，只有前版本才是可以的。

當事務的提交時，重做（redo）日志才會寫入。另外所謂的離線檢查點工作者（Offline Checkpoint Worker）將成功提交的事務從事務填入一對所謂的數據和Delta文件（Data and Delta Files），來自內存中OLTP的數據和Delta文件會加速故障恢復。故障恢復重建你的內存優(yōu)化表初始于數據和Delta文件對，然后自上個檢查發(fā)生的所有改變從事務日志里應用。我們來看下這個概念。

因為在內存OLTP里一切都是和高性能有關，數據和Delta文件SQL Server只用順序讀寫（sequential I/O）。不會涉及到隨機讀寫（random I/O），因為這會殺死性能。現在的問題是，什么信息會寫入數據和Delta文件對？內存中OLTP數據文件包含插入到內存優(yōu)化表的記錄。因為插入只發(fā)生在文件末尾，順序讀寫很容易實現。當你在內存優(yōu)化表刪除指定記錄時，記錄只在對應的Delta文件邏輯上標記為刪除。這個信息也是加在Delta文件末尾，這樣又是真正的在存儲里順序讀寫。UPDATE語句只是新記錄和老記錄副本INSERT語句和DELETE語句的組合。很簡單，是不是？下圖展示了這個重要概念。

如果你想進一步了解內存中OLTP如何實現持久性的，我強烈推薦Tony Rogerson寫的文章How Hekaton (XTP) achieves Durability for “Memory Optimised” Tables。

內存優(yōu)化表的故障恢復以你數據和Delta文件對存儲的速度進行。因此當你創(chuàng)建數據庫，當考慮并決定配置存儲文件對的內存中OLTL文件組，仔細對待就非常重要。首先你要包含內存優(yōu)化數據的存儲增加文件組，如下代碼所示：

-- Add a new memory optimized file groupALTER DATABASE InMemoryOLTPADD FILEGROUP InMemoryOLTPFileGroup CONTAINS MEMORY_OPTIMIZED_DATAGO

在內存優(yōu)化文件組創(chuàng)建后（在傳統(tǒng)FILESTREAM文件組覆蓋下），你可以添加存儲容器（storage container）到文件組。這里你可以使用ADD FILE命令，如下代碼所示：

1 -- Add a new storage container2 ALTER DATABASE InMemoryOLTP ADD FILE3 (4     NAME = N'InMemoryOLTPContainer', 5     FILENAME = N'C:/PRogram Files/Microsoft SQL Server/MSSQL12.SQL2014/MSSQL/DATA/InMemoryOLTPContainer'6 )7 TO FILEGROUP [InMemoryOLTPFileGroup]8 GO

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

• 數據和Delta文件對存儲在同個物理硬盤
• 寫數據和Delta文件對在同個物理硬盤導致隨機讀寫（random I/O）
• 故障恢復只能和一個物理硬盤那么塊，那里存儲這數據和Delta文件

為了克服這些限制，你可以添加多個屬于內存優(yōu)化文件的存儲容器在不同的“物理”硬盤上。這樣的話，數據和Delta文件在多個存儲容器間會以循環(huán)（round-robin）樣式分配。假設配置2個存儲容器會發(fā)生什么：

• 第1個數據文件存入第1個存儲容器
• 第1個Delta文件存入第2個存儲容器
• 第2個數據文件存入第1個存儲容器
• 第2個Delta文件存入第2個存儲容器

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

但是只使用2個存儲容器并不解決你的磁盤瓶頸問題，因為只有2個容器，所有的數據文件存儲在第1個容器，所有的Delta文件存儲在第2個容器。一般來說，你的數據文件比你的Delta文件會多很多，這就是說在不同物理硬盤上的2個存儲容器之間的讀寫很不平衡。存儲你所有數據文件的第1個存儲容器比存儲你所有Delta文件的第2個容器需要更多的IOPS。

為了多個物理硬盤之間IOPS平均分布與平衡。對于你的內存優(yōu)化文件組，微軟推薦至少4個存儲容器。當你有4個存儲容器時，想象下會發(fā)生什么，如下圖所示：

如果你使用這個配置，在第1個物理硬盤上你有第1個文件對（數據和Delta文件），在第2個物理存儲上你有第2個文件對（數據和Delta文件），在第1個物理硬盤上你有第3個文件對（數據和Delta文件），以此類推。最后你在多個物理硬盤鍵平均散布了你的讀寫請求，這會加速你的故障恢復進程，因為故障恢復可以在存儲容器里并行，這會加速你數據庫聯(lián)機。

在這個文件里你看到對于內存中OLTP，存儲速度和吞吐量還是非常重要的。在存儲里，你的數據必須是物理永駐的，不然當你的SQL Server崩潰或重啟時，你的數據就會丟失。你內存優(yōu)化文件組配置會大大影響文件組給你的吞吐量。如果你在生產環(huán)境運行內存中OLTP，你應該至少配置4個存儲容器分布在2個物理硬盤。在性能要求更高的場景，你甚至可以增加超過2個物理硬盤的更多存儲容器。正如微軟說的：“內存中OLTP的故障恢復是以你存儲速度進行的”。

感謝關注！