（轉）快閃記憶體表空間 VS 資料庫Flash Cache

快閃記憶體表空間 VS 資料庫Flash Cache

在這篇文章中,我將根據我最近針對使用SSD作為資料檔案的儲存以及使用Oracle 11GR2資料庫Flash Cache所做的測試,給出一份兩者的效能對比.
有時,我的整個職業生涯看上去都是在等待旋轉磁碟的終結.這項技術是如此古老,能力限制如此明確,如此機械.因此,SSD作為一種資料庫儲存介質越來越可行(Oracle 11GR2已經直接支援這一點),這個事實令人振奮.
使用SSD作為資料庫儲存的一部分確實會產生很大的問題,但是,理解快閃記憶體SSD的效能特徵卻是非常重要的,它可以幫助我們確保不會不當地使用它.
SSD有以下兩個特徵:

• 基於快閃記憶體的SSD使用與常見的USB盤相似的快閃記憶體技術,這種USB盤已經在小容量移動資料儲存領域替代軟盤.快閃記憶體RAM比較便宜,提供不需要電池備份的持久儲存,因此其耗電量也很低.
• 基於DDR RAM的SSD使用本質上與伺服器核心記憶體差別不大的記憶體模組.這種RAM需要有持久儲存(如磁碟或快閃記憶體RAM)和內部電池來支撐.在發生電力故障的時候,電池可以提供足夠的電力來保證可以將RAM記憶體中的內容寫到持久儲存.

DDR SSD非常昂貴(以及$$/GB這個級別),以致於目前無法作為專業的資料庫裝置使用.但是,基於快閃記憶體的SSD磁碟越來越稱為機械磁碟的一個可行的替代選項.

讀,寫以及擦寫操作

快閃記憶體盤儲存是按照頁(一般為4K)以及塊(一般為256K)來組織的.對於讀操作來講,快閃記憶體盤可以從單個頁(page)快速返回結果.往一個頁中寫資料要慢很多(可能要慢10倍).然而,只有在塊中剛好有一個空閒的頁的往頁寫才能達到這個速度.如果我們需要往整個塊寫資料,必須先清除塊內的內容才可以.維基百科關於SSD的條目給出了下面這個關於查詢/寫以及擦寫的時間:

當一個快閃記憶體SSD盤漸漸填滿資料時,需要清除操作的塊級別的寫操作的比例逐漸增加,快閃記憶體SSD的寫效能也相應下降.

TRIM API函式

高階的快閃記憶體SSD支援一種叫做TRIM的API,這個功能使得OS可以主動提前清除整個塊,從而寫操作可以在只有一個頁級別的IO內完成.大部分高階的SSD盤還支援一種防磨損演算法,這種演算法可以在裝置上移動熱點頁以避免塊級別出現故障的風險.快閃記憶體盤在塊變得不可靠之前只支援一定次數的擦寫操作,加入磁碟可以自動將熱點頁在物理儲存上移動時,這個缺陷就可以得到緩解.

MLC vs SLC

廉價的快閃記憶體盤一般都使用MLC(Multi-Level-Cell)技術,它可以實現在一個單元中儲存兩位的資料,而使用SLC時一個單元中只能儲存一位資料.MLC的效果是以犧牲效能的代價來提高資料密度,特別是寫效能.從資料丟失的角度講,MLC也是更加不可靠的.如果你關心寫效能,那麼或許你應該避免使用基於MLC的SSD.
通常,如果你想要一個高效能的快閃記憶體SSD的話(如果它不是高效能的,幹嘛還要它呢?),你就應該選擇基於SLC的快閃記憶體SSD,並且是支援TRIM API以及有著好的防磨損能力的SSD.在我的測試中,我使用一個Intel X-25 E 32GB的SSD盤.它大概需要600澳元(大概534美元).

讀寫速度差異的問題

假設大部分資料庫都是讀比寫多,我們還需要擔心快閃記憶體SSD在查詢時間與寫時間方面的差異嗎?毫無疑問答案是YES.對於一個Oracle資料庫來講,當透過Buffer Cache處理事務活動時,一個裝置的讀能力與往這個裝置的寫能力之間有很大的不匹配會非常有害.
這個問題與Buffer Cache中的資料的快取有關.如果往Buffer Cache中放入資料塊比從裡面寫出簡單很多,那麼Buffer Cache就很可能會被髒塊填滿,從而出現free buffer waits等待.下圖展示了free buffer waits是如何出現的:

如果使用的是廉價的快閃記憶體盤,那麼寫速度就會比讀速度慢更多,最終free buffer waits等待將成為事務活動高峰時期的限制因素.

Oracle資料庫Flash Cache

Oracle的資料庫Flash Cache提供了另外一種利用快閃記憶體SSD的途徑. 它不是將整個資料檔案放到快閃記憶體上,而是將快閃記憶體作為二級快取使用.Flash Cache可以非常大從而加快經常被訪問的資料塊的讀速度.但是,如果快閃記憶體盤非常繁忙的話,Oracle就只是儘量少寫快取.這樣,我們就可以得到快閃記憶體來最佳化讀操作的好處,而不用承擔多少寫操作帶來的損失.
我在前一篇文章中總結了Flash Cache的處理演算法,下面是我在那篇文章中使用的圖表,它概括了當資料庫使用Flash Cache時一個資料塊的生命週期.

這個架構的關鍵點是,只有在DBWR沒有超負荷時,它才會往Flash Cache中寫入資料塊.當DBWR逐漸變得繁忙時,往Flash Cache中的寫操作將被忽略(這將會降低Flash Cache的效率),它可以防止Buffer Cache被髒塊填滿,從而導致free buffer waits等待事件的出現.

快閃記憶體盤的讀效能

讓我們來看在實際操作中它是如何表現的.下面來看當我們針對如下情況執行500,000次隨機索引讀取時的效能對比:

• 1. 一個在機械磁碟上的表,不使用Flash Cache
• 2. 一個在機械磁碟上的表,使用Flash Cache
• 3. 一個直接儲存在快閃記憶體盤上的表

這個機械磁碟是一塊希捷7200.7 80GB Barracuda磁碟,同時這個SSD盤是一塊Intel X-25 E 32GB盤(一塊非常高階的SLC盤).在這兩種情況下,表空間都是建立在裸裝置上從而避免檔案系統快取的影響,並且重做日誌(Redo Log)以及其他表空間都放置在一個獨立的磁碟上.
下面是相關的讀效能:

如你所料,將表直接放置在快閃記憶體上是最快的,因為這裡只有讀IO,並且每個讀IO都是針對這個非常快的快閃記憶體SSD.注意,Flash Cache也同樣帶來了很大的好處,資料庫檔案的IO數量下降了,當然從Flash Cache讀取的速度是非常快的.

更新效能

下面,我將測量基於主鍵的更新操作的效能.這樣一個更新操作的效能是由讀效能(讀取這個資料塊到快取中)與DBWR效能共同決定的.如果DBWR寫出髒塊的速度不是足夠快的話,就會出現free buffer waits與write complete waits等待事件了.
我最初預計,對快閃記憶體表空間的測試肯定會遇到大量的free buffer waits,因為理論上講快閃記憶體的寫操作要比快閃記憶體的讀操作慢很多很多. 我認為使用Flash Cache將會避免這個問題,並且能夠提供更好的效能. 然而,結果非常出人意外.

我使用不同的負荷重複進行上面的測試,但是每一次結果都非常相似.然而,使用Flash Cache還是要比不使用Flash Cache來得好,將表直接儲存到快閃記憶體儲存上效能就更好了.X-25 E SSD盤支援一個遠遠超出我預期的寫頻率(大概2000次寫操作/秒).Intel 宣稱(現在我相信了)他們擁有精密的演算法可以有效避免通常與快閃記憶體SSD儲存介質有關的寫損失.
注意,實際上大部分的free buffer waits等待事件的產生都是由Flash Cache的配置導致的.Flash Cache使得Oracle的邏輯讀的速度更快,但是由於物理寫仍然會面對相對更慢的機械旋轉磁碟,Buffer Cache常常會被髒塊所填滿.
或許隨著時間的流逝,當所有的塊都被至少寫過一次,清除操作變得更加普遍時,X-25的效能會出現下降.然而,如果TRIM API能夠正常工作,那麼理論上這種效能惡化應該可以避免.注意,並不是所有環境都支援TRIM API,並不是所有的SSD都支援,舊版本的Windows操作可能也不支援.

Write complete waits: flash cache

在上一篇文章中,我注意到,當DBWR繁忙的時候會跳過而不寫Flash Cache,這一點應該可以避免Flash Cache的活動不會成為導致free buffer waits的直接原因.然而,我觀察到,在特定的負荷下會遇到大量的”write complete waits: flash cache“等待事件.例如,下面的輸出結果顯示大約有75%的實耗時間(elapsed time)消耗在這個等待事件上.

當一個會話想要修改一個資料,但同時DBWR又正在將這個資料塊寫到資料檔案的時候會出現write complete waits等待事件.Flash Cache相對應的等待事件的出現也是由於類似的原因,但這是不是寫資料塊到資料檔案,而將由DBWR將它寫到Flash Cache.當一個特定的資料塊被非常頻繁的修改的時候,這種現象就會出現;在這種情況下,資料塊在被DBWR寫完之前被修改的機會相當高.

結論

X-25 E快閃記憶體SSD盤給我留下了非常深刻的印象.如果它可以長時間的保持優異的寫吞吐量的話,相比於傳統的機械旋轉磁碟以及11GR2的資料庫Flash Cache,它提供的吞吐量有驚人的優勢.不過,還有幾句忠告:

• 我沒有長時間對這個SSD盤做壓力測試.有些快閃記憶體盤在磨損後顯示出更長寫延遲.理論上,Intel X-25 E的TRIM功能應該可以避免這一點,但我並沒有在這些測試中驗證這一點.
• 在經過長時間的使用後,快閃記憶體盤可能會成為一種不可靠的儲存介質.當然,任何磁碟都會損壞,但是快閃記憶體盤比機械磁碟更加容易損壞(雖然在損壞之前它可能可以做更多的工作).
• 在我的測試中,我的表很小,足以完全存放在快閃記憶體儲存上.如果做不到這一點,使用資料庫Flash Cache讓我們在無法將整個資料庫都放到SSD上的時候,也可以利用快閃記憶體盤.

  現在,我更加熱衷於使用快閃記憶體盤了.只要你購買一個高效能的SSD盤(考慮SLC & TRIM),你就可以考慮將整個表空間或者資料庫都存放在這些盤上.如果擔負不起所有的資料都存放在高階的快閃記憶體盤上,還可以考慮使用11GR2的資料庫Flash Cache來獲得顯著的效能提升.