相信大家對內(nèi)存數(shù)據(jù)庫的 概念并不陌生,之前園子里也有多位大牛介紹過SQL內(nèi)存數(shù)據(jù)庫的創(chuàng)建方法,我曾仔細 拜讀過,有了大致了解,不過仍有很多細節(jié)不清晰,比如:
(1)內(nèi)存數(shù)據(jù)庫是把整個數(shù)據(jù)庫放到內(nèi)存中的嗎?
(2)數(shù)據(jù)都在內(nèi)存里面,那宕機或者斷電了,數(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)存嗎?
答案:不是。
SQL Server 2014提供了眾多激動人心的新功能,但其中我想最讓人期待的特性之一就要算內(nèi)存數(shù)據(jù)庫了。去年我再西雅圖參加SQL PASS Summit 2012的開幕式時,微軟就宣布了將在下一個SQL Server版本中附帶代號為Hekaton的內(nèi)存數(shù)據(jù)庫引擎,F(xiàn)在隨著2014CTP1的到來,我們終于可以一窺其面貌。
內(nèi)存數(shù)據(jù)庫
在傳統(tǒng)的數(shù)據(jù)庫表中,由于磁盤的物理結(jié)構(gòu)限制,表和索引的結(jié)構(gòu)為B-Tree,這就使得該類索引在大并發(fā)的OLTP環(huán)境中顯得非常乏力,雖然有很多辦法來解決這類問題,比如說樂觀并發(fā)控制,應(yīng)用程序緩存,分布式等。但成本依然會略高。而隨著這些年硬件的發(fā)展,現(xiàn)在服務(wù)器擁有幾百G內(nèi)存并不罕見,此外由于NUMA架構(gòu)的成熟,也消除了多CPU訪問內(nèi)存的瓶頸問題,因此內(nèi)存數(shù)據(jù)庫得以出現(xiàn)。
內(nèi)存的學名叫做Random Access Memory(RAM),因此如其特性一樣,是隨機訪問的,因此對于內(nèi)存,對應(yīng)的數(shù)據(jù)結(jié)構(gòu)也會是Hash-Index,而并發(fā)的隔離方式也對應(yīng)的變成了MVCC,因此內(nèi)存數(shù)據(jù)庫可以在同樣的硬件資源下,Handle更多的并發(fā)和請求,并且不會被鎖阻塞,而SQL Server 2014集成了這個強大的功能,并不像Oracle的TimesTen需要額外付費,因此結(jié)合SSD AS Buffer Pool特性,所產(chǎn)生的效果將會非常值得期待。
SQL Server內(nèi)存數(shù)據(jù)庫的表現(xiàn)形式
在SQL Server的Hekaton引擎由兩部分組成:內(nèi)存優(yōu)化表和本地編譯存儲過程。雖然Hekaton集成進了關(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)使得隨機讀寫的速度大大提高,另外內(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ù)文件;
我再補充一個信息
(3)內(nèi)存數(shù)據(jù)庫的數(shù)據(jù)文件分data file和delta file,而且是成對出現(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)化表的語法,紅色框標注了內(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)化表也叫為" natively compile memory-optimized tables",翻譯過來就是本地編譯內(nèi)存優(yōu)化表,內(nèi)存優(yōu)化表在創(chuàng)建的同時被編譯成本地機器代碼裝載到內(nèi)存中,本地機器代碼包含了能被CPU直接執(zhí)行的機器指令,所以對內(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ù)文件分data file和delta file,而且是成對出現(xiàn);
內(nèi)存數(shù)據(jù)庫中插入、更新的數(shù)據(jù)和刪除的數(shù)據(jù)物理分開存儲的,分別用data file和delta file保存。
(1)Data file
Data file用來保存"插入"或者"更新"的數(shù)據(jù)行,data file中數(shù)據(jù)行的存儲順序嚴格按照事務(wù)執(zhí)行的順序組織,比如data file中第一行的數(shù)據(jù)來自于事務(wù)1,第二行數(shù)據(jù)來自于事務(wù)2,這兩行可以是同一個表的數(shù)據(jù),也可以是不同表的數(shù)據(jù),取決于這兩個連續(xù)的事務(wù)操作的內(nèi)存優(yōu)化表是否相同。 這種方式的好處是保證了磁盤IO的連續(xù)性,避免隨機IO。
Data file的大小是固定的,為128MB,當一個data file被寫滿了后,SQL會自動新建一個data file。因為數(shù)據(jù)在data file中保存的順序是按照事務(wù)的執(zhí)行順序進行的,所以一張表的數(shù)據(jù)行(來自多個事務(wù))可能跨越了多個data file,當對多行進行更新操作時,寫操作可以分配到多個文件上,并且同時進行,這樣就可以加快更新的效率。(下文介紹delta file時會介紹)
如下圖,一共有4個data files(淺藍色),第一個data file的事務(wù)范圍為100-200,第二個data file的事務(wù)范圍為200-300……(100、200表示時間戳)
在Data file中,如果一行被刪除或者更新了,這行不會從data file中移除,而是通過delta file(上圖黃色框)來標記刪除的行,(update的本質(zhì)是delete和insert的集合,所以執(zhí)行update時也會有刪除的動作),這樣可以消除不必要的磁盤IO。
如果data file的數(shù)據(jù)永不刪除,那文件豈不是無限制的增大,以后備份不是得用很大的磁盤才行?當然不是,SQL在處理這個問題用到方法其實很簡單——"合并",根據(jù)合并策略,將多個data file和delta file合并起來,依據(jù)delta file的內(nèi)容刪除data file中的多余記錄,然后將多個data file合并成一個文件,從而減小數(shù)據(jù)文件占用的磁盤空間大小。
(2) Delta file
每個data file都有一個與之匹配的Delta File,這個匹配是指事務(wù)范圍上的匹配,兩者記錄的是同一段事務(wù)(包括一個或者多個事務(wù))上的數(shù)據(jù),Delta File中記錄了data file中被刪除行的標記,這個標記其實就是一個關(guān)聯(lián)信息{inserting_tx_id, row_id, deleting_tx_id }。它跟data file一樣,也是嚴格按照事務(wù)操作的順序來保存刪除的行的信息。
如上圖,該內(nèi)存數(shù)據(jù)庫有5個data file,分別存放了事務(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的 delta file上和第5的data file上。刪除操作可以分配到多個文件上,并且同時進行,這樣就可以加快刪除的效率。
二、數(shù)據(jù)都在內(nèi)存里面,那宕機或者斷電了,數(shù)據(jù)不是沒有了嗎?
答案:不是。
內(nèi)存數(shù)據(jù)庫通過兩種方式保證數(shù)據(jù)的持久性:事務(wù)日志和chcekpoint。
(1)事務(wù)日志
內(nèi)存數(shù)據(jù)庫的"寫日志"和"寫數(shù)據(jù)"在一個事務(wù)中進行,在事務(wù)執(zhí)行期間,SQL會先"寫數(shù)據(jù)"然后在才"寫日志",這點與傳統(tǒng)數(shù)據(jù)庫不同,在傳統(tǒng)數(shù)據(jù)庫中,不管是在內(nèi)存中還是磁盤中,"寫數(shù)據(jù)"總是在"寫日志"之后,也就是通常所說的WAL(Write-Ahead Transaction Log)。但是,在事務(wù)提交時,內(nèi)存數(shù)據(jù)庫和傳統(tǒng)數(shù)據(jù)庫在"寫日志"上沒有什么區(qū)別:日志會先于數(shù)據(jù)寫入到磁盤中。
因此,即使服務(wù)器發(fā)生了宕機或者斷電,下次數(shù)據(jù)庫重啟時會按照已經(jīng)保存在磁盤中事務(wù)日志將業(yè)務(wù)redo(重做),所以不要擔心數(shù)據(jù)會丟失。
另外,需要補充的是,內(nèi)存數(shù)據(jù)庫只會對持久性表將已提交的事物日志保存到磁盤中。這樣做的好處可以減少寫磁盤的次數(shù)。內(nèi)存數(shù)據(jù)庫支持頻繁、快速的增、刪、改等操作,這個強度遠遠高于傳統(tǒng)數(shù)據(jù)庫,數(shù)據(jù)庫需要為每筆操作寫日志,這樣就會產(chǎn)生大量磁盤IO,寫日志操作將有可能成為性能瓶頸,不記錄未提交的事務(wù)日志就減少寫日志的數(shù)量,從而可以提高數(shù)據(jù)庫的性能。
有同學會想,不記錄未提交事務(wù)的日志會不會導致數(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ù)。默認情況下Checkpoint是周期性進行的,當日志至上次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)化表中,一行有兩個大部分組成:Row header和Row body,
Row header記錄這個行的有效期(開始時間戳和結(jié)束時間戳)和索引指針
Row body記錄了一行的實際數(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ù)不可能對將每個行版本都操作一遍,實際上,一個事物只能操作同一行的一個行版本,至于它能對哪個行版本進行操作,取決于事務(wù)執(zhí)行時間是否在這行的兩個時間戳之間。除此之外的其他行版本對該事務(wù)而言是不可見的。
由于一行可能存在多個行版本,大家可能會提出這樣一個疑問:每行都有這么多行版本,一張上百萬行的表,內(nèi)存哪夠呀。不用擔心,前文介紹過了,每個行實際上是有時間戳的,對于已經(jīng)打上結(jié)束時間戳且沒有活動事務(wù)訪問的行,SQL Server會通過garbage collection機制回收它占用的內(nèi)存,從而節(jié)省內(nèi)存。所以不要擔心內(nèi)存不夠。
四、內(nèi)存數(shù)據(jù)庫號稱無鎖式設(shè)計,那如果發(fā)生了并發(fā)沖突怎么辦,SQL是如何處理沖突的呢?
答案:內(nèi)存數(shù)據(jù)庫用行版本來處理沖突。
鎖的一個重要作用就是避免多個進程同時修改數(shù)據(jù),從而造成數(shù)據(jù)不一致。常見的沖突現(xiàn)象包括讀寫互鎖和寫寫互鎖。那內(nèi)存數(shù)據(jù)庫是如何通過行版本來解決這兩種鎖定現(xiàn)象的呢?
(1)讀寫互鎖
在內(nèi)存數(shù)據(jù)庫中,所有對內(nèi)存優(yōu)化表的事務(wù)隔離都是基于快照的,準確的說是基于行的快照。從上文行的 結(jié)構(gòu)可以知道,每行的行頭包括開始時間戳和結(jié)束時間戳的,一個事務(wù)能不能訪問到這行關(guān)鍵在于事務(wù)的啟動時間是不是在這行的兩個時間戳內(nèi)。
如果某個事務(wù)正在修改一行(快照),但還未提交到內(nèi)存優(yōu)化表中,也就是說"新行"還沒有結(jié)束時間戳,對"讀事務(wù)"而言,它讀還是是原來行(快照),因此不會存在臟讀的現(xiàn)象。
(2)寫寫互鎖
兩個事務(wù)同時更新一行時,就會發(fā)生寫寫互鎖。
內(nèi)存數(shù)據(jù)庫沖突發(fā)生的概率比傳統(tǒng)數(shù)據(jù)庫小很多,但如果實在遇到了沖突,只能調(diào)整應(yīng)用程序,在應(yīng)用程序中加入"重試邏輯"(等待一會,然后再重新發(fā)起事務(wù))來解決。
或許有同學覺得這種方式好像也沒有什么大的性能改變。其實不然,舉個例子,在傳統(tǒng)數(shù)據(jù)庫中一個鎖可能將整個表都管住了,在表鎖期間只能等待這個事務(wù)做完才能執(zhí)行其他事務(wù),而實際上這個事務(wù)可能只是修改了小部分行,因為表鎖的存在,其他行那些不需要被這個事務(wù)操作的行。但內(nèi)存數(shù)據(jù)庫中寫寫沖突總是發(fā)生在行級別的,這個粒度小多了,影響沒這么大。