SQL Server內(nèi)存數(shù)據(jù)庫(kù)原理解析

前言

關(guān)系型數(shù)據(jù)庫(kù)發(fā)展至今，細(xì)節(jié)上以做足文章，在尋求自身突破發(fā)展的過(guò)程中，內(nèi)存與分布式數(shù)據(jù)庫(kù)是當(dāng)下最流行的主題，這與性能及擴(kuò)展性在大數(shù)據(jù)時(shí)代的需求交相輝映。

SQL Server作為傳統(tǒng)的數(shù)據(jù)庫(kù)也在最新發(fā)布版本SQL Server 2014中提供了新利器 SQL Server In-Memory OLTP（Hekaton），使得其在OLTP系統(tǒng)中的性能有了幾十倍甚至上百倍的性能提升，本篇文章為大家探究一二。 

大數(shù)據(jù)時(shí)代的數(shù)據(jù)如何組織應(yīng)用？這恐怕眾口不一。但不可否認(rèn)，關(guān)系型數(shù)據(jù)依舊是當(dāng)下世界最有效的應(yīng)用方式。作為應(yīng)用技術(shù)，也必將伴隨著應(yīng)用的需求而不斷演化。

信息爆炸對(duì)信息處理提出了更為嚴(yán)苛的需求，單從傳統(tǒng)的OLTP系統(tǒng)來(lái)看，性能和擴(kuò)展性便是應(yīng)用者最為關(guān)注的方面。假如應(yīng)用者告訴你我需要當(dāng)下數(shù)據(jù)庫(kù)訪問(wèn)量100倍的計(jì)算資源，單純硬件？顯然新的技術(shù)應(yīng)用呼之而出。

傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)自誕生起自身不斷完善的同時(shí)也伴隨著硬件的飛速發(fā)展，性能提升上伴隨處理器神奇的摩爾定律，TPC-C，TPC-E等指標(biāo)不斷提升，而隨著今年來(lái)處理器物理工藝接近極限，CPU的主頻速度幾乎不再提升，這時(shí)計(jì)算機(jī)朝著多核方向進(jìn)展，同時(shí)內(nèi)存成本也在線性降低，不再如此昂貴，目前內(nèi)存的成本已經(jīng)低于10$/GB。

而固態(tài)硬盤(pán)（SSD）的廣泛應(yīng)用也使得傳統(tǒng)數(shù)據(jù)庫(kù)在性能上有更多的延伸。面對(duì)這些新的硬件環(huán)境，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)自然也有其設(shè)計(jì)之初不可避免的自身性能瓶頸。

SQL Server 2014的傳統(tǒng)引擎中引入緩沖池?cái)U(kuò)展（Buffer Pool Extension）功能，利用SSD的高IOPS作為緩沖池的有利延伸，構(gòu)成了熱，活，冷三層數(shù)據(jù)體系，有效緩解磁盤(pán)的壓力。

我們可以把更多的數(shù)據(jù)放入內(nèi)存，SSD中，但即便如此數(shù)據(jù)庫(kù)的性能還是被自身的一些架構(gòu)和處理方式所約束著。

就著前面的假設(shè)，我們要把事務(wù)處理能力提升100倍。假設(shè)我們現(xiàn)在的處理能力是100 TPS，而這時(shí)每個(gè)事務(wù)所以得平均CPU指令為100萬(wàn)個(gè)，以此提升10倍1000 TPS，每個(gè)事務(wù)的CPU指令就需降為10萬(wàn)個(gè)，而再提升10倍10000TPS每個(gè)事務(wù)的CPU指令就需降為1萬(wàn)個(gè)，這在現(xiàn)有的數(shù)據(jù)庫(kù)系統(tǒng)中是不可能實(shí)現(xiàn)的，所以我們依舊需要新的處理方式。

一、傳統(tǒng)數(shù)據(jù)庫(kù)引擎面臨的問(wèn)題

有的朋友可能會(huì)說(shuō)把所有數(shù)據(jù)都放入內(nèi)存中就是內(nèi)存數(shù)據(jù)庫(kù)，就不存在短板了，但即便如此我們?nèi)悦媾R如下主要問(wèn)題：

1.保護(hù)內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)而采用的閂鎖（latch）引起的熱點(diǎn) （hot spots）問(wèn)題。

2.使用鎖機(jī)制控制多版本并發(fā)帶來(lái)的阻塞等問(wèn)題。

3.使用解釋型（interpretation）語(yǔ)言的執(zhí)行計(jì)劃的執(zhí)行效率問(wèn)題。

我們簡(jiǎn)單看下上述問(wèn)題的由來(lái)

1.假設(shè)我有一個(gè)查詢Q1需要訪問(wèn)一個(gè)數(shù)據(jù)頁(yè) 頁(yè)號(hào)7，此時(shí)數(shù)據(jù)頁(yè)不在BufferPool(BP)中，為此系統(tǒng)為其分配了內(nèi)存架構(gòu)，并去磁盤(pán)取相關(guān)數(shù)據(jù)頁(yè)置入BP中此過(guò)程正常大概10-20ms，而此時(shí)恰好另一個(gè)查詢Q2需訪問(wèn)數(shù)據(jù)頁(yè)號(hào)7，由于BP中已經(jīng)存在應(yīng)該頁(yè)架構(gòu)，如果此時(shí)允許Q2讀取，則Q2將會(huì)臟讀。

因此引入閂鎖，當(dāng)Q1去磁盤(pán)讀取數(shù)據(jù)時(shí)BP中的相應(yīng)架構(gòu)被閂鎖保護(hù)，Q2讀相應(yīng)的頁(yè)時(shí)將被阻塞，知道Q1完成相應(yīng)操作并釋放閂鎖，如下圖1-1所示：

圖1-1

現(xiàn)在有數(shù)據(jù)庫(kù)系統(tǒng)中為保證多線程下的共享數(shù)據(jù)一致性，內(nèi)存任何數(shù)據(jù)結(jié)構(gòu)都需被閂鎖保護(hù)。而當(dāng)大量并發(fā)進(jìn)程同時(shí)訪問(wèn)一個(gè)數(shù)據(jù)頁(yè)(結(jié)構(gòu))就造成了熱點(diǎn)問(wèn)題。消耗了大量CPU的同時(shí)影響了并發(fā)吞吐。

2.假設(shè)有如下兩個(gè)操作，都對(duì)數(shù)據(jù)庫(kù)中的某個(gè)值進(jìn)行修改：

A=1000

Q1:A = A + 100Q2: A = A + 500

在數(shù)據(jù)庫(kù)中的操作為

Q1:Read A，A=A+100， Write A

Q2:Read A，A=A+500， Write A

如果是串行先后執(zhí)行，則沒(méi)有問(wèn)題，但如果同時(shí)執(zhí)行則可以出現(xiàn)數(shù)據(jù)的不一致情形。

Q1，Q2同時(shí)讀取了A的原始值后，進(jìn)行修改，則數(shù)據(jù)不一致如圖1-2：

圖1-2

為了解決此問(wèn)題，已故的業(yè)界大神，圖靈獎(jiǎng)的獲得者JimGray提出了兩階段鎖概念 (Two-Phase Locking)，合理地解決了并發(fā)一致性問(wèn)題，并被絕大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)應(yīng)用并改進(jìn)(如SQL Server中數(shù)據(jù)不同粒度下并發(fā)兼容情形引入的意向鎖)。

本例中當(dāng)Q1讀取A時(shí)，對(duì)A加排他鎖，當(dāng)Q2試圖讀取時(shí)就會(huì)被阻塞，需等待Q1的事務(wù)完成后釋放鎖資源后才能繼續(xù)讀取。如圖1-3：

圖1-3

但也正因?yàn)殒i的引入，使得事務(wù)間可能出現(xiàn)相互阻塞，并且需要特定的進(jìn)行管理鎖資源，且需對(duì)死鎖等問(wèn)題即時(shí)檢測(cè)，而這些問(wèn)題自然地會(huì)影響并發(fā)性能。

3.熟悉SQL Server的人都知道一條語(yǔ)句在SQL Server中執(zhí)行，現(xiàn)有進(jìn)行綁定，語(yǔ)義分析，基于成本的優(yōu)化等一些列過(guò)程然后生成相應(yīng)的解釋性語(yǔ)言執(zhí)行計(jì)劃，而引擎在執(zhí)行相應(yīng)的執(zhí)行計(jì)劃時(shí)會(huì)調(diào)用相應(yīng)的數(shù)據(jù)庫(kù)函數(shù)，運(yùn)行每一個(gè)運(yùn)算符，如果數(shù)據(jù)在硬盤(pán)上則會(huì)去硬盤(pán)上取數(shù)據(jù)……

這些情形使得執(zhí)行解釋性語(yǔ)言時(shí)高時(shí)間消耗的同時(shí)也打斷CPU流水，使得CPU的效率無(wú)法充分發(fā)揮，而如果數(shù)據(jù)均在內(nèi)存中，則可以采用更高效的方式處理。而絕大多數(shù)關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)的執(zhí)行計(jì)劃均為解釋性語(yǔ)言。

面對(duì)這些問(wèn)題，巨頭數(shù)據(jù)庫(kù)廠商們都提供了相應(yīng)的內(nèi)存數(shù)據(jù)庫(kù)解決方案，如Oracle的Timesten，還有最新圖靈獎(jiǎng)獲得者M(jìn)ichael Stonebraker教授的研究H-store演化出的商業(yè)產(chǎn)品VoltDB等。

而微軟的SQL Server 2014也推出了內(nèi)存數(shù)據(jù)庫(kù)SQL Server In-Memory OLTP(開(kāi)發(fā)代號(hào)Hekaton)，接下來(lái)我們就簡(jiǎn)要的看下Hekaton如何應(yīng)對(duì)上面的問(wèn)題，使得性能得到新的升華。

二、SQL Server Hekaton的應(yīng)對(duì)方式

SQL Server Hekaton是一個(gè)基于內(nèi)存優(yōu)化的高性能的OLTP數(shù)據(jù)庫(kù)引擎，且數(shù)據(jù)是可持久化的，它完全集成于SQL Server內(nèi)(可與傳統(tǒng)引擎，基于列存儲(chǔ)引擎混合透明使用如圖2-1)，且是基于現(xiàn)代多核CPU架構(gòu)設(shè)計(jì)。如圖2-1：

圖2-1

應(yīng)對(duì)上述三點(diǎn)性能瓶頸，熱點(diǎn)上Hekaton采用”Bw-tree”數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)Latch-free，并發(fā)鎖上采用樂(lè)觀并發(fā)中多版本時(shí)間戳數(shù)據(jù)行控制實(shí)現(xiàn)無(wú)鎖事務(wù)，解釋性語(yǔ)言執(zhí)行效率采用截執(zhí)行計(jì)劃編譯為機(jī)器代碼(DLL)提升CPU效率。

下面針對(duì)這三點(diǎn)來(lái)簡(jiǎn)要說(shuō)明下。

Hekaton中的數(shù)據(jù)頁(yè)大小是彈性的，以便于增量更新Delta update，因?yàn)楝F(xiàn)有傳統(tǒng)的update in place會(huì)使得現(xiàn)有的CPU Cache失效，在多核架構(gòu)下會(huì)使得性能受限。數(shù)據(jù)頁(yè)在內(nèi)存中通過(guò)映射表管理，將每個(gè)數(shù)據(jù)頁(yè)的邏輯ID與物理地址一一映射。如圖2-2：

圖2-2

在對(duì)數(shù)據(jù)進(jìn)行更新時(shí)采用Compareand Swap(CAS)實(shí)現(xiàn)無(wú)鎖(Latch free)操作

CAS：通過(guò)比對(duì)物理地址的值與攜帶值是否匹配，匹配則可操作，不匹配則拒絕操作。

如某個(gè)進(jìn)程在攜帶的地址M的值為20，匹配地址M的實(shí)際值，如果為20則可以修改，否則拒絕如圖2-3：

圖2-3

在對(duì)數(shù)據(jù)頁(yè)進(jìn)行增量更新時(shí)每次操作均會(huì)在數(shù)據(jù)上生成一個(gè)新的增量地址作為數(shù)據(jù)頁(yè)的訪問(wèn)入口，并采用CAS完成映射表中(mapping table)物理新地址的映射(delta address)，并對(duì)針對(duì)同一數(shù)據(jù)頁(yè)可能出現(xiàn)的同時(shí)更新進(jìn)行仲裁，此時(shí)勝出者將進(jìn)行更新，而失敗者可以進(jìn)行重試，遺憾的是目前SQL Server只會(huì)對(duì)失敗操作拋出錯(cuò)誤信息，需要我們自己捕捉錯(cuò)誤信息并重試，具體可參考聯(lián)機(jī)文檔。

具體如圖2-4所示：

圖2-4

這樣的操作方式下，當(dāng)更新鏈過(guò)長(zhǎng)時(shí)訪問(wèn)數(shù)據(jù)會(huì)造成時(shí)間復(fù)雜度提升從而影響性能，SQL server會(huì)在合適的情形下進(jìn)行整理，生成新的數(shù)據(jù)頁(yè)，并將物理地址指向新的數(shù)據(jù)頁(yè)，而老的數(shù)據(jù)頁(yè)鏈表將會(huì)作為垃圾回收釋放內(nèi)存。

如圖2-5：

圖2-5

由于數(shù)據(jù)頁(yè)是彈性的，所以可能造成數(shù)據(jù)頁(yè)過(guò)大或是過(guò)程，Hekaton中會(huì)在其認(rèn)為合適的情形下進(jìn)行頁(yè)分裂或是合并。限于篇幅這里就不在詳細(xì)敘述了，在實(shí)現(xiàn)Latch-free中所有內(nèi)存中的操作都是通過(guò)一個(gè)或多個(gè)原子操作完成。感興趣的朋友可以參考微軟的相關(guān)文獻(xiàn)。

有的朋友可能會(huì)說(shuō)閂鎖本身是保護(hù)內(nèi)存結(jié)構(gòu)的輕量級(jí)鎖，況且不同類型的閂鎖可能兼容，Latch-free對(duì)性能幫助能有多大呢？

實(shí)際SQL Server在訪問(wèn)內(nèi)存中數(shù)據(jù)時(shí)，閂鎖本身用作控制數(shù)據(jù)訪問(wèn)時(shí)成本很高，為此會(huì)在數(shù)據(jù)上加自旋鎖(Spin lock)供線程探測(cè)數(shù)據(jù)是否可以訪問(wèn)，Spin lock實(shí)現(xiàn)即一個(gè)Bit位（0或1），線程會(huì)一直探測(cè)內(nèi)存中的這個(gè)Bit位以試圖獲得自旋鎖，如果可以訪問(wèn)則訪問(wèn)，否則自旋，如果幾千次的探測(cè)仍無(wú)法訪問(wèn)則停下”休息”這個(gè)稱作一次碰撞。

但是在自旋的過(guò)程CPU負(fù)荷狀態(tài)，因此也就造成CPU資源白白浪費(fèi)。生產(chǎn)中我們可能看到CPU高啟，而并發(fā)卻上不去，訪問(wèn)變慢，其中的一個(gè)原因就是大量進(jìn)程訪問(wèn)熱點(diǎn)數(shù)據(jù)下大量自旋鎖征用使得性能受限。

而在Hekaton中無(wú)閂鎖的情況下就不存在這樣問(wèn)題，單從這個(gè)角度來(lái)看隨著線程的增加性能也是線性放大。當(dāng)然除了Latch-free，其他的兩個(gè)方面Hekaton同樣表現(xiàn)出色。

前文中敘述可知，關(guān)系型數(shù)據(jù)庫(kù)中事務(wù)是靠鎖來(lái)保證多版本并發(fā)控制的，由此帶來(lái)的阻塞死鎖等問(wèn)題相信所有的DBA都印象深刻。而Hekaton中采用樂(lè)觀并發(fā)下多版本數(shù)據(jù)加時(shí)間戳的形式實(shí)現(xiàn)。

下面來(lái)簡(jiǎn)要解下。

Hekaton中將一個(gè)事務(wù)分為三個(gè)階段，正常事務(wù)處理步驟用于我們的數(shù)據(jù)操作DML則創(chuàng)建新的版本行。驗(yàn)證提交階段驗(yàn)證這個(gè)事務(wù)是否可以安全提交(根據(jù)版本數(shù)據(jù))。提交處理階段用于寫(xiě)日志，并將新的版本行數(shù)據(jù)對(duì)其它事務(wù)可見(jiàn)。

如圖2-6：

圖2-6

我們通過(guò)一個(gè)實(shí)例簡(jiǎn)要說(shuō)明下：

事務(wù)過(guò)程采用Timestamps(時(shí)間戳(全局時(shí)鐘))標(biāo)記事務(wù)和行版本，每個(gè)事務(wù)開(kāi)始時(shí)賦予開(kāi)始時(shí)間戳Begin_TS，用于讀取正確的行版本(數(shù)據(jù)行同樣均具有時(shí)間戳)，行版本數(shù)據(jù)結(jié)束時(shí)間戳End_TS一般為正無(wú)窮(+∞)，當(dāng)進(jìn)行數(shù)據(jù)更新時(shí)創(chuàng)建新的版本行，并將舊的版本行End_TS修改為事務(wù)ID Xb(此處非時(shí)間戳)，新的版本行的Begin_TS同樣標(biāo)記為事務(wù)ID (Xb)。然后獲取事務(wù)的End_TS (唯一)，確認(rèn)可提交后，提交事務(wù)，并將新舊版本的事務(wù)ID(Xb)替換成獲取的End_TS。至此完成一次操作。未涉及任何鎖，閂鎖，阻塞。

如圖2-7：

圖2-7

有的同學(xué)看到上圖可能回想，這樣X(jué)a讀取的版本行是正確的嗎？他為什么不能讀到Xb的新行數(shù)據(jù)。我們來(lái)簡(jiǎn)單分析下。

Xa開(kāi)始時(shí)分配的時(shí)間戳為25，Xb為35，這就意味著Xb的結(jié)束時(shí)間戳一定大于35此時(shí)Xa讀取數(shù)據(jù)，時(shí)間戳范圍應(yīng)為Begin_TS-20，End_TS-+∞，而Xa的Begin_TS小于Xb的Begin_TS，所以讀取正確如圖2-8：

圖2-8

實(shí)際上Hekaton中規(guī)定 查詢的可見(jiàn)值區(qū)間必須覆蓋此查詢的開(kāi)始時(shí)間戳比如一個(gè)查詢事務(wù)的開(kāi)始時(shí)間戳為30，他可見(jiàn)的行版本可以包括10至+∞，20至150，但不能看到40至+∞。如圖2-9：

圖2-9

有的同學(xué)可能會(huì)想，隨著訪問(wèn)，DML的增加，會(huì)累積大量的無(wú)用數(shù)據(jù)占用內(nèi)存，實(shí)際上根據(jù)查詢自身的事務(wù)時(shí)間戳，如上當(dāng)最古老的事務(wù)開(kāi)始時(shí)間戳大于等于50時(shí)，舊版本的數(shù)據(jù)就可以安全的清除釋放內(nèi)存了。清除工作可以使多線程并行執(zhí)行，對(duì)新能影響很小。

從圖2-6中可以看到，并不是每個(gè)事務(wù)都可以安全提交的，在驗(yàn)證階段，Hekaton會(huì)根據(jù)用戶設(shè)定的隔離級(jí)別進(jìn)行驗(yàn)證。

Hekaton為樂(lè)觀并發(fā)，提供三種隔離級(jí)別的支持分別為快照隔離級(jí)別（Snapshot Isolation），可重復(fù)讀隔離級(jí)別（RepeatableReads Isolation）及序列化隔離級(jí)別（Serializable），這與傳統(tǒng)的關(guān)系型數(shù)據(jù)類似，Snapshot中是無(wú)需驗(yàn)證的，而可重復(fù)則需在提交前再次驗(yàn)證與事務(wù)開(kāi)始時(shí)的數(shù)據(jù)是否一致，如一致則可提交，否則不可提交。

而序列化中顧名思義讀取的區(qū)間數(shù)據(jù)都需一致，否則失敗。有同學(xué)可能會(huì)想序列化中將匹配多少數(shù)據(jù)啊，成本是不是太高了，別忘了這是在內(nèi)存中，依然比傳統(tǒng)的序列化成本要低很多。

熟悉樂(lè)觀級(jí)別的同學(xué)都知道，傳統(tǒng)的樂(lè)觀并發(fā)級(jí)別下回滾成本是非常高的，而Hekaton中采用驗(yàn)證的方式有效的規(guī)避了這項(xiàng)成本。提交就是寫(xiě)日志記錄變化，并將數(shù)據(jù)行中事務(wù)ID替換成獲取的時(shí)間戳，對(duì)其他事務(wù)可見(jiàn)。

當(dāng)然提高寫(xiě)日志，我們都知道磁盤(pán)終究是瓶頸，為此Hekaton也有其特定的優(yōu)化方式來(lái)緩解這個(gè)問(wèn)題，限于篇幅這里就不在敘述。而且針對(duì)一些特定的場(chǎng)景我們可以選擇只保留Schema而無(wú)需數(shù)據(jù)持久化（如游戲的場(chǎng)景數(shù)據(jù)等）。

最后，針對(duì)CPU執(zhí)行效率將執(zhí)行計(jì)劃由解釋性語(yǔ)言（Interpreted）替換為機(jī)器語(yǔ)言（Native）。

優(yōu)化器可以說(shuō)是關(guān)系型數(shù)據(jù)庫(kù)最復(fù)雜的部分了，簡(jiǎn)單說(shuō)下SQLServer優(yōu)化器處理過(guò)程：一條語(yǔ)句交給優(yōu)化器會(huì)進(jìn)行綁定解析，生成解析樹(shù)，然后進(jìn)行語(yǔ)義分析生成邏輯執(zhí)行計(jì)劃，最后優(yōu)化器再為邏輯執(zhí)行計(jì)劃基于成本生成物理的執(zhí)行計(jì)劃。

而Hekaton中，如果我們選擇Native方式執(zhí)行（將所執(zhí)行語(yǔ)句通過(guò)存儲(chǔ)過(guò)程特殊編譯），在生成邏輯執(zhí)行計(jì)劃之后將會(huì)根據(jù)不同的算法，成本預(yù)估生成不同的物理執(zhí)行計(jì)劃，然后將物理執(zhí)行計(jì)劃轉(zhuǎn)譯成C語(yǔ)言代碼再通過(guò)編譯器將其編譯成DLL即機(jī)器代碼。如圖2-10：

圖2-10

曾經(jīng)微博上有朋友問(wèn)為什么Mysql重構(gòu)優(yōu)化器時(shí)為什么要將parsing，optimizing， execution三個(gè)模塊分開(kāi)而不是混在一起了，我想這里可能就找到答案了，一個(gè)優(yōu)秀RDBMS它自身的健壯是多么重要。

在Native下，所有的執(zhí)行都是“Goto”，直接讀取數(shù)據(jù)，再也不用一個(gè)一個(gè)的function的調(diào)用，極大提升CPU的工作效率。有人可能會(huì)問(wèn)這樣每次都編譯將是非常大的工作成本，實(shí)際上Hekaton將指定查詢（存儲(chǔ)過(guò)程）編譯成DLL文件，只是在第一次將其載入內(nèi)存就可以了。對(duì)于即席查詢是不可以的。

Hekaton在機(jī)器代碼下執(zhí)行效率大幅提升，以下是微軟給出的測(cè)試數(shù)據(jù)：

a.Interpreted與Native的對(duì)比，其中分為是否為內(nèi)存優(yōu)化表，查詢單條數(shù)據(jù)所消耗的CPU指令。如圖2-11：

圖2-11

b.隨機(jī)查找1000萬(wàn)數(shù)據(jù)普通表與Hekaton內(nèi)存優(yōu)化表查詢時(shí)間對(duì)比圖2-12：

圖2-12

c.普通表與Hekaton內(nèi)存優(yōu)化表內(nèi)存中隨機(jī)更新數(shù)據(jù)對(duì)比，此時(shí)不寫(xiě)日志如圖2-13：

圖2-13

三、Hekaton應(yīng)用案例

Hekaton，古希臘語(yǔ)中表示百倍，雖然目前還未達(dá)到愿景，我想這個(gè)出色的團(tuán)隊(duì)一定能夠做到。

SQL Server有了這個(gè)新利器，在應(yīng)對(duì)性能問(wèn)題上更加出色。在微軟的官方網(wǎng)站上有大量案例，這里我們列舉幾個(gè)。

Bwin，歐洲最大的在線×××，采用Hekaton后，線上每秒批處理由15000提升到250000。

EdgeNet，硅谷著名的數(shù)據(jù)服務(wù)商，采用Hekaton后，線上入庫(kù)數(shù)據(jù)量由7450/s提升到126665/s均由近17倍的速度提升。如圖3-1：

圖3-1

而將易車的惠買車的訪問(wèn)量在Hekaton模擬運(yùn)行時(shí)，各項(xiàng)性能指標(biāo)都表現(xiàn)的很淡定。如圖3-2：

圖3-2

Hekaton不僅為我們解決了不少場(chǎng)景下的性能問(wèn)題，我想面對(duì)特定場(chǎng)景中的一些棘手問(wèn)題也有一定的幫助。比如電商熱衷的秒殺/搶購(gòu)。這里筆者就不在敘述業(yè)內(nèi)朋友研究的排隊(duì)論，批量提交等等辦法。

實(shí)際上計(jì)算機(jī)在當(dāng)下普遍應(yīng)用都是模擬三維空間內(nèi)的人為活動(dòng)，試想下，搶購(gòu)的過(guò)程終究有成功或是失敗，就好像你在搶購(gòu)熱銷產(chǎn)品時(shí)被身手矯健的大媽推到一邊你沒(méi)搶到一樣，這不正好符合Hekaton中的事務(wù)機(jī)制？我們?cè)谠O(shè)計(jì)網(wǎng)上產(chǎn)品活動(dòng)的時(shí)候是否該想想模擬到現(xiàn)實(shí)中是什么樣子的？對(duì)此，我認(rèn)為我們需要的是可控，而不是控制。

四、結(jié)語(yǔ)

最后，這么多帶給人驚喜振奮的數(shù)據(jù)庫(kù)，它就完美無(wú)缺嗎？當(dāng)然不是。Hekaton的樂(lè)觀并發(fā)級(jí)別限定使得其并不適合大量更新沖突的場(chǎng)景，其以空間換速度的設(shè)計(jì)要求會(huì)消耗大量?jī)?nèi)存，需要應(yīng)用者合理規(guī)劃設(shè)計(jì)……

請(qǐng)牢記“任何技術(shù)都是有缺陷的”，沒(méi)有哪項(xiàng)技術(shù)/架構(gòu)是完美無(wú)缺的，合適的場(chǎng)景選擇合理的技術(shù)/架構(gòu)才是我們的初衷。