有關(guān)sqlserver2022內(nèi)存數(shù)據(jù)庫特性介紹范文

有關(guān)sqlserver2022內(nèi)存數(shù)據(jù)庫特性介紹范文相信大家對內(nèi)存數(shù)據(jù)庫的概念并不陌生，之前也有多位大牛介紹過SQL內(nèi)存數(shù)據(jù)庫的創(chuàng)立辦法，我曾仔細(xì)拜讀過，有了大致了解，不過仍有很多細(xì)節(jié)不清晰，比方：

〔1〕內(nèi)存數(shù)據(jù)庫是把整個數(shù)據(jù)庫放到內(nèi)存中的嗎？

〔2〕數(shù)據(jù)都在內(nèi)存里面，那宕機(jī)或者斷電了，數(shù)據(jù)不是沒有了嗎？

〔3〕據(jù)在內(nèi)存是怎么寄存的，還是按照頁的方式嗎，一行的大小有限制嗎？

〔4〕內(nèi)存數(shù)據(jù)庫號稱無鎖式設(shè)計，SQL是如何處理并發(fā)沖突的呢？

相信這些疑問也是大家在思考內(nèi)存數(shù)據(jù)庫時經(jīng)常遇到的難題，下文將為大家一一揭開這些問題的面紗，如有不對之處，還請各位看官幫我指出。

一、內(nèi)存數(shù)據(jù)庫是如何存儲的，只放在內(nèi)存嗎？是把整個數(shù)據(jù)庫放在內(nèi)存嗎？

答案：不是。

sqlserver2022提供了眾多沖動人心的新功能，但其中我想最讓人期待的特性之一就要算內(nèi)存數(shù)據(jù)庫了。去年我再西雅圖加入SQLPASSSummit2022的開幕式時，微軟就宣布了將在下一個SQLServer版本中附帶代號為Hekaton的內(nèi)存數(shù)據(jù)庫引擎?，F(xiàn)在隨著2022CTP1的到來，我們終于可以一窺其面貌。

內(nèi)存數(shù)據(jù)庫

在傳統(tǒng)的數(shù)據(jù)庫表中，由于磁盤的物理結(jié)構(gòu)限制，表和索引的結(jié)構(gòu)為B-Tree，這就使得該類索引在大并發(fā)的OLTP環(huán)境中顯得非常乏力，雖然有很多方法來解決這類問題，比方說樂觀并發(fā)控制，應(yīng)用程序緩存，分布式等。但本錢依然會略高。而隨著這些年硬件的開展，現(xiàn)在效勞器擁有幾百G內(nèi)存并不罕見，此外由于NUMA架構(gòu)的成熟，也打消了多CPU訪問內(nèi)存的瓶頸問題，因此內(nèi)存數(shù)據(jù)庫得以出現(xiàn)。

內(nèi)存的學(xué)名叫做RandomAccessMemory〔RAM〕，因此如其特性一樣，是隨機(jī)訪問的，因此對于內(nèi)存，對應(yīng)的數(shù)據(jù)結(jié)構(gòu)也會是Hash-Index，而并發(fā)的隔離方式也對應(yīng)的變成了MVCC，因此內(nèi)存數(shù)據(jù)庫可以在同樣的硬件資源下，Handle更多的并發(fā)和請求，并且不會被鎖阻塞，而SQLServer2022集成了這個強(qiáng)大的功能，并不像Oracle的TimesTen需要額外付費(fèi)，因此結(jié)合SSDASBufferPool特性，所產(chǎn)生的效果將會非常值得期待。

SQLServer內(nèi)存數(shù)據(jù)庫的表現(xiàn)形式

在SQLServer的Hekaton引擎由兩局部組成：內(nèi)存優(yōu)化表和本地編譯存儲過程。雖然Hekaton集成進(jìn)了關(guān)系數(shù)據(jù)庫引擎，但訪問他們的辦法對于客戶端是透明的，這也意味著從客戶端應(yīng)用程序的角度來看，并不會知道Hekaton引擎的存在。如圖1所示。

圖1.客戶端APP不會感知Hekaton引擎的存在

首先內(nèi)存優(yōu)化表完全不會再存在鎖的概念〔雖然之前的版本有快照隔離這個樂觀并發(fā)控制的概念，但快照隔離仍然需要在修改數(shù)據(jù)的時候加鎖〕，此外內(nèi)存優(yōu)化表Hash-Index結(jié)構(gòu)使得隨機(jī)讀寫的速度大大提高，另外內(nèi)存優(yōu)化表可以設(shè)置為非持久內(nèi)存優(yōu)化表，從而也就沒有了日志〔適合于ETL中間結(jié)果操作，但存在數(shù)據(jù)喪失的危險〕

在這篇文章中，我想著重引用如下兩個信息：

〔1〕內(nèi)存數(shù)據(jù)庫其實就是將指定的表放到內(nèi)存中，而不是整個數(shù)據(jù)庫；

〔2〕內(nèi)存數(shù)據(jù)庫用文件流的方式組織磁盤中的數(shù)據(jù)文件；

我再補(bǔ)充一個信息

〔3〕內(nèi)存數(shù)據(jù)庫的數(shù)據(jù)文件分datafile和deltafile，而且是成對出現(xiàn)；

1、內(nèi)存數(shù)據(jù)庫其實就是將指定的表放到內(nèi)存中，而不是整個數(shù)據(jù)庫；

內(nèi)存數(shù)據(jù)庫的創(chuàng)立過程其實就是將表寄存到內(nèi)存中，而不是整個數(shù)據(jù)庫。下列圖展示了創(chuàng)立內(nèi)存優(yōu)化表的語法，紅色框標(biāo)注了內(nèi)存與傳統(tǒng)表創(chuàng)立時語法不相同的地方。

內(nèi)存優(yōu)化表不僅僅是把數(shù)據(jù)寄存到內(nèi)存中，要不然跟傳統(tǒng)數(shù)據(jù)的緩存沒有區(qū)別。在內(nèi)存數(shù)據(jù)庫中，內(nèi)存優(yōu)化表也叫為"nativelycompilememory-optimizedtables"，翻譯過來就是本地編譯內(nèi)存優(yōu)化表，內(nèi)存優(yōu)化表在創(chuàng)立的同時被編譯本錢地機(jī)器代碼裝載到內(nèi)存中，本地機(jī)器代碼包含了能被CPU直接執(zhí)行的機(jī)器指令，所以對內(nèi)存優(yōu)化表的訪問和操作將非常快。

內(nèi)存優(yōu)化表分兩類，持久性表和非持久性表，對持久性表的改動會記錄日志，即使數(shù)據(jù)庫重啟，數(shù)據(jù)也不會喪失；對非持久性表的操作不會記錄日志，這些操作結(jié)果只保存在內(nèi)存中，數(shù)據(jù)庫重啟后數(shù)據(jù)會喪失。

上文只是介紹了新建一張表的情況，在正常的業(yè)務(wù)環(huán)境中我們不可能對一個業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫的每張表都去create，那對于已經(jīng)存在的表，有沒有配置辦法呢？答案恐怕不太令人稱心，目前SQL暫不支持遷移現(xiàn)有表到內(nèi)存中，因此要想使用內(nèi)存數(shù)據(jù)庫，現(xiàn)有的業(yè)務(wù)數(shù)據(jù)表必須重新創(chuàng)立。

2、內(nèi)存數(shù)據(jù)庫用文件流的方式組織磁盤中的數(shù)據(jù)文件

在內(nèi)存數(shù)據(jù)庫中，磁盤上存儲的數(shù)據(jù)文件不在是區(qū)、頁的存儲方式，而是基于文件流存儲。文件流存儲的一個特點之一就是支持快速的讀操作，這在數(shù)據(jù)庫重啟時將文件流中的數(shù)據(jù)load到內(nèi)存中時很能提高效率。

3、內(nèi)存數(shù)據(jù)庫的數(shù)據(jù)文件分datafile和deltafile，而且是成對出現(xiàn)；

內(nèi)存數(shù)據(jù)庫中插入、更新的數(shù)據(jù)和刪除的數(shù)據(jù)物理分開存儲的，分別用datafile和deltafile保留。

〔1〕Datafile

Datafile用來保留"插入"或者"更新"的數(shù)據(jù)行，datafile中數(shù)據(jù)行的存儲順序嚴(yán)格按照事務(wù)執(zhí)行的順序組織，比方datafile中第一行的數(shù)據(jù)來自于事務(wù)1，第二行數(shù)據(jù)來自于事務(wù)2，這兩行可以是同一個表的數(shù)據(jù)，也可以是不同表的數(shù)據(jù)，取決于這兩個連續(xù)的事務(wù)操作的內(nèi)存優(yōu)化表是否相同。這種方式的好處是保證了磁盤IO的連續(xù)性，防止隨機(jī)IO。

Datafile的大小是固定的，為128MB，當(dāng)一個datafile被寫滿了后，SQL會自動新建一個datafile。因為數(shù)據(jù)在datafile中保留的順序是按照事務(wù)的執(zhí)行順序進(jìn)行的，所以一張表的數(shù)據(jù)行〔來自多個事務(wù)〕可能跨越了多個datafile，當(dāng)對多行進(jìn)行更新操作時，寫操作可以分配到多個文件上，并且同時進(jìn)行，這樣就可以加快更新的效率。〔下文介紹deltafile時會介紹〕

如圖所示，一共有4個datafiles〔淺藍(lán)色〕，第一個datafile的事務(wù)范圍為100-200，第二個datafile的事務(wù)范圍為200-300……〔100、200表示時間戳〕

在Datafile中，如果一行被刪除或者更新了，這行不會從datafile中移除，而是通過deltafile〔上圖黃色框〕來標(biāo)記刪除的行，〔update的本質(zhì)是和的匯合，所以執(zhí)行update時也會有刪除的動作〕，這樣可以打消不必要的磁盤IO。

如果datafile的數(shù)據(jù)永不刪除，那文件豈不是無限制的增大，以后備份不是得用很大的磁盤才行？當(dāng)然不是，SQL在處理這個問題用到辦法其實很簡單——"合并"，根據(jù)合并策略，將多個datafile和deltafile合并起來，依據(jù)deltafile的內(nèi)容刪除datafile中的多余記錄，然后將多個datafile合并成一個文件，從而減小數(shù)據(jù)文件占用的磁盤空間大小。

〔2〕Deltafile

每個datafile都有一個與之匹配的DeltaFile，這個匹配是指事務(wù)范圍上的匹配，兩者記錄的是同一段事務(wù)〔包括一個或者多個事務(wù)〕上的數(shù)據(jù)，DeltaFile中記錄了datafile中被刪除行的標(biāo)記，這個標(biāo)記其實就是一個關(guān)聯(lián)信息{ing_tx_id,row_id,deleting_tx_id}。它跟datafile一樣，也是嚴(yán)格按照事務(wù)操作的順序來保留刪除的行的信息。

如上圖，該內(nèi)存數(shù)據(jù)庫有5個datafile，分別寄存了事務(wù)范圍在100-200、200-300、300-400、400-500及500的數(shù)據(jù)。如果有一個時間戳為501的事務(wù)需要刪除時間戳為150、250、450的事務(wù)所產(chǎn)生的數(shù)據(jù)和增加一些新數(shù)據(jù)時，相應(yīng)的IO請求就會被分配到第1、2、4的deltafile上和第5的datafile上。刪除操作可以分配到多個文件上，并且同時進(jìn)行，這樣就可以加快刪除的效率。

二、數(shù)據(jù)都在內(nèi)存里面，那宕機(jī)或者斷電了，數(shù)據(jù)不是沒有了嗎？

答案：不是。

內(nèi)存數(shù)據(jù)庫通過兩種方式保證數(shù)據(jù)的持久性：事務(wù)日志和chcekpoint。

〔1〕事務(wù)日志

內(nèi)存數(shù)據(jù)庫的"寫日志"和"寫數(shù)據(jù)"在一個事務(wù)中進(jìn)行，在事務(wù)執(zhí)行期間，SQL會先"寫數(shù)據(jù)"然后在才"寫日志"，這點與傳統(tǒng)數(shù)據(jù)庫不同，在傳統(tǒng)數(shù)據(jù)庫中，不論是在內(nèi)存中還是磁盤中，"寫數(shù)據(jù)"總是在"寫日志"之后，也就是通常所說的WAL〔Write-AheadTransactionLog〕。但是，在事務(wù)提交時，內(nèi)存數(shù)據(jù)庫和傳統(tǒng)數(shù)據(jù)庫在"寫日志"上沒有什么區(qū)別：日志會先于數(shù)據(jù)寫入到磁盤中。

因此，即使效勞器發(fā)生了宕機(jī)或者斷電，下次數(shù)據(jù)庫重啟時會按照已經(jīng)保留在磁盤中事務(wù)日志將業(yè)務(wù)redo〔重做〕，所以不要擔(dān)憂數(shù)據(jù)會喪失。

另外，需要補(bǔ)充的是，內(nèi)存數(shù)據(jù)庫只會對持久性表將已提交的'事物日志保留到磁盤中。這樣做的好處可以減少寫磁盤的次數(shù)。內(nèi)存數(shù)據(jù)庫支持頻繁、快速的增、刪、改等操作，這個強(qiáng)度遠(yuǎn)遠(yuǎn)高于傳統(tǒng)數(shù)據(jù)庫，數(shù)據(jù)庫需要為每筆操作寫日志，這樣就會產(chǎn)生大量磁盤IO，寫日志操作將有可能成為性能瓶頸，不記錄未提交的事務(wù)日志就減少寫日志的數(shù)量，從而可以提高數(shù)據(jù)庫的性能。

有同學(xué)會想，不記錄未提交事務(wù)的日志會不會導(dǎo)致數(shù)據(jù)不一致呢？

肯定不會，因為日志在寫入磁盤前不可能發(fā)生先把"臟數(shù)據(jù)"寫入到磁盤的現(xiàn)象〔下面介紹checkpoint的時候會介紹原因〕。

〔2〕CheckPoint

在內(nèi)存數(shù)據(jù)庫中，CheckPoint的主要目的就是將內(nèi)存中的"數(shù)據(jù)"寫入到磁盤中，從而在數(shù)據(jù)庫崩潰或者重啟時減少數(shù)據(jù)恢復(fù)的時間。不需要數(shù)據(jù)庫逐條讀取所有的日志來恢復(fù)數(shù)據(jù)。默認(rèn)情況下Checkpoint是周期性進(jìn)行的，當(dāng)日志至上次checkpoint后增加了512M時會觸發(fā)新一輪CheckPoint。

在傳統(tǒng)數(shù)據(jù)庫這種，Checkpoint可以將未提交的數(shù)據(jù)flush到磁盤的mdf文件中，這個現(xiàn)象在內(nèi)存數(shù)據(jù)庫中不會發(fā)生，因為內(nèi)存數(shù)據(jù)庫只將已提交事務(wù)的日志，而在寫日志〔到磁盤〕之前不可能將數(shù)據(jù)先寫到磁盤中，因此可以保證寫到磁盤中的數(shù)據(jù)一定是已提交事務(wù)的數(shù)據(jù)。

三、數(shù)據(jù)在內(nèi)存是怎么寄存的，還是按照頁的方式嗎，一行的大小有限制嗎？

答案：不是按照頁的方式，一行的限制大小為8060Bytes。

內(nèi)存優(yōu)化表是基于行版本存儲的，同一行在內(nèi)存中會有多個版本，可以將內(nèi)存優(yōu)化表的存儲結(jié)構(gòu)看作是該表中所有行的多個行版本的匯合。

內(nèi)存優(yōu)化表中的行跟傳統(tǒng)數(shù)據(jù)庫的行結(jié)構(gòu)是不一樣的，下列圖描述了內(nèi)存優(yōu)化表中一行的數(shù)據(jù)結(jié)構(gòu)：

在內(nèi)存優(yōu)化表中，一行有兩個大局部組成：Rowheader和Rowbody，

Rowheader記錄這個行的有效期〔開始時間戳和結(jié)束時間戳〕和索引指針

Rowbody記錄了一行的實際數(shù)據(jù)。

在內(nèi)存優(yōu)化表中，行版本的數(shù)量是由針對該行的操作次數(shù)決定的，比方：每更新一次，就會新產(chǎn)生一行，增加一個行版本，新行有新的開始時間戳，新行產(chǎn)生后，原來的數(shù)據(jù)行會自動填充結(jié)束時間戳，意味這行已經(jīng)過期。

備注：上圖實際上只有3行，第1行有3個行版本，第2行有2個行版本，第3行有4個行版本。

既然同一行在內(nèi)存中存在這么多的行版本，那數(shù)據(jù)庫在訪問時是怎么控制的呢？

在傳統(tǒng)數(shù)據(jù)庫中，表中每一行都是唯一的，一個事務(wù)如想找到一行，通過文件號、頁號、槽位就可以了。

在內(nèi)存數(shù)據(jù)庫中，每一行有多個行版本，一個事務(wù)不可能對將每個行版本都操作一遍，實際上，一個事物只能操作同一行的一個行版本，至于它能對哪個行版本進(jìn)行操作，取決于事務(wù)執(zhí)行時間是否在這行的兩個時間戳之間。除此之外的其他行版本對該事務(wù)而言是不可見的。

由于一行可能存在多個行版本，大家可能會提出這樣一個疑問：每行都有這么多行版本，一張上百萬行的表，內(nèi)存哪夠呀。不用擔(dān)憂，前文介紹過了，每個行實際上是有時間戳的，對于已經(jīng)打上結(jié)束時間戳且沒有活動事務(wù)訪問的行，SQLServer會通過garbagecollection機(jī)制回收它占用的內(nèi)存，從而節(jié)省內(nèi)存。所以不要擔(dān)憂內(nèi)存不夠。

四、內(nèi)存數(shù)據(jù)庫號稱無鎖式設(shè)計，那如果發(fā)生了并發(fā)沖突怎么辦，SQL是如何處理沖突的呢？

答案：內(nèi)存數(shù)據(jù)庫用行版本來處理沖突。

鎖的一個重要作用就是防止多個進(jìn)程同時修改數(shù)據(jù)，從而造成數(shù)據(jù)不一致。常見的沖突現(xiàn)象包括讀寫互鎖和寫寫互鎖。那內(nèi)存數(shù)據(jù)庫是如何通過行版本來解決這兩種鎖定現(xiàn)象的呢？

〔1〕讀寫互鎖

在內(nèi)存數(shù)據(jù)庫中，所有對內(nèi)存優(yōu)化表的事務(wù)隔離都是基于快照的，準(zhǔn)確的說是基于行的快照。從上文行的結(jié)構(gòu)可以知道，每行的行頭包括開始時間戳和結(jié)束時間戳的，一個事務(wù)能不能訪問到這行關(guān)鍵在于事務(wù)的啟動時間是不是在這行的兩個時間戳內(nèi)。

如果某個事務(wù)正在修改一行〔快照〕，但還未提交到內(nèi)存優(yōu)化表中，也就是說"新行"還沒有結(jié)束時間戳，對"讀事務(wù)"而言，它讀還是是原來行〔快照〕，因此不會存在