閃存存儲特性以及數(shù)據(jù)庫相關優(yōu)化思路
閃存存儲當前越來越多的應用于企業(yè)級環(huán)境,特別是提升數(shù)據(jù)庫性能方面。本次分享主要介紹閃存的特性,閃存的劣勢及其解決機制,以及采用閃存存儲時數(shù)據(jù)庫的一些優(yōu)化思路。
目錄
- 閃存的特性
- 閃存的劣勢及其解決機制
- 數(shù)據(jù)庫場景測試
一.閃存的特性
凡是采用Flash Memory的存儲設備,可以統(tǒng)稱為閃存存儲。我們經(jīng)常談的固態(tài)硬盤(SSD),可以由volatile/non-volatile memory構成,其實固態(tài)硬盤的范疇是大于閃存的,只是當前的固態(tài)硬盤大多數(shù)采用閃存介質,所以很多時候我們默認固態(tài)硬盤就是閃存盤。
除了閃存以外,還有其它多種快速存儲技術,如DRAM ,NVRAM, MRAM and Spin-Torque(自旋力矩磁阻式隨機存取內存), Carbon Nanotube( 碳納米管 ), Phase Change Memory(相變內存),Memristor ( 憶阻器 )等等。
未來存儲設備的創(chuàng)新其實就是存儲材料的創(chuàng)新,這也是國外很多初創(chuàng)的半導體公司一個研發(fā)的方向。
從半導體的角度來看,閃存屬于非易失性存儲,但是屬于不可靠介質。因為閃存是采用電子驅動,因此具有電子元器件所固有的缺陷,電子泄露,衰減等等。
決定閃存存儲大規(guī)模應用的主要因素是量產(chǎn)規(guī)模、穩(wěn)定性以及經(jīng)濟性。
閃存設備隨著使用時間和數(shù)據(jù)量的增長,壞塊會逐漸增加,會產(chǎn)生大量的ECC Error,這時設備性能和可靠性會大幅度下降,對應用性能和數(shù)據(jù)安全帶來影響。閃存產(chǎn)品在使用過程中往往會存在性能衰減和可靠性下降的問題。這里提醒一下,如果我們使用閃存產(chǎn)品,一定要使用工具監(jiān)控閃存產(chǎn)品的健康狀態(tài),防止老化,數(shù)據(jù)丟失。
通過對閃存產(chǎn)品的良好設計和質量控制,也可以避免性能衰減和可靠性下降的問題,但是往往會帶來成本的增加和性能的下降(相比于直寫閃存)。
對于企業(yè)級應用而言,穩(wěn)定是***位,其次是易用性,第三才是性能。閃存設備的性能相比于應用的需要是足夠的。
閃存在企業(yè)級以及數(shù)據(jù)中心的應用,實際上也是依賴于互聯(lián)網(wǎng)以及大數(shù)據(jù)的興起。
互聯(lián)網(wǎng)的分布式架構以及多副本保護機制,消除了集中式存儲的瓶頸,滿足了海量用戶以及應用的請求,帶來了更高的性能需求。同時多副本的保護機制,又解決了閃存作為不可靠介質可能帶來的數(shù)據(jù)存儲安全的問題。
但是由于閃存的可靠性問題,其實互聯(lián)網(wǎng)客戶也是有選擇地在特定業(yè)務上使用閃存,并不是在所有業(yè)務上都使用閃存設備。
有的時候我們還會發(fā)現(xiàn)意外斷電后,閃存設備故障,這往往是由于電路保護機制不完善或固件bug造成的。
二. 閃存的劣勢及其解決機制
在使用閃存設備的時候,我們需要考慮的問題要比使用磁盤多。
當前我們碰到的很多問題是,相比于IOPS,閃存比磁盤性能高上幾十甚至上百倍,但是我們將數(shù)據(jù)放置到閃存上,性能提升并沒有這么高,甚至沒有提高。
原因是閃存主要解決的是IO性能問題,并且主要隨機寫的性能,而順序讀寫性能并不如多塊磁盤匯聚之后的性能。
Linux文件系統(tǒng)
以Linux為例,Linux ext4屬于日志型文件系統(tǒng),為了保護數(shù)據(jù)安全,通過Journal機制提供一致性保護。那么我們在部署過程中可以將Journal日志放置到閃存上,可以提升IO性能。因為應用的IO操作還是通過OS層面完成的,因此OS層面的IO性能提升也可以帶來應用性能提升。
另外,操作系統(tǒng)以及應用的IO層往往是針對磁盤的特性進行了優(yōu)化,這些優(yōu)化往往不適用于閃存設備,甚至還有副作用。例如OS層面IO scheduler有三種模式,CFQ、Deadline和noop,其中前兩種模式是針對磁盤低IO特性和物理尋道機制進行優(yōu)化的,例如做IO合并、尋道算法等等,會有默認的等待嚴實以等到更多的IO block進行合并和處理。對于閃存而言,是不存在尋道處理的,因此前兩種處理機制反而會造成延時增加。如果我們在系統(tǒng)中使用了SSD,需要將IO scheduler調整為noop模式。
三. 數(shù)據(jù)庫場景測試
剛才談到為了保證數(shù)據(jù)安全,我們需要在Linux采用Journal模式,但是MySQL也有double write的機制,我們需要怎么既保證數(shù)據(jù)安全,又不會增加過多的機制造成性能下降。我們在我們的閃存產(chǎn)品上做了這方面的測試。
上面是mySQL的寫入機制。當系統(tǒng)意外斷電時,數(shù)據(jù)庫16K的頁面可能沒有完成,就會出現(xiàn)partial write,而partial write會造成數(shù)據(jù)庫損壞。
MySQL 的Double write就是為了解決partial write造成的問題,但是DW也會帶來兩個問題,性能懲罰和對SSD的磨損增加。
我們按照上面的場景在我們的閃存卡上進行了測試。
在安全性層面,只要Metadata Journal+DW或Metadata Journal+Data Journal,都可以保護數(shù)據(jù)庫數(shù)據(jù)的安全,也就是意外掉電數(shù)據(jù)不會損壞,數(shù)據(jù)庫可以正常啟動,數(shù)據(jù)不丟失。
但是在CPU bound的情況下,前個組合的性能衰減(8%)要小于后面的保護組合(10%)。如果是在IO bound的情況下,前個組合的性能衰減(10%)要小于后面的保護組合(34%)。但是DW下的數(shù)據(jù)寫入量會比后者增加23%,也就是會增加SSD的磨損。這個是我們在應用時需要注意的。
另外,我們在做DB2的測試時也發(fā)現(xiàn)幾個問題:
閃存存儲在非分區(qū)表的簡單的查詢統(tǒng)計條件的查詢方面具有明顯的優(yōu)勢和性能提升,性能提升3到4倍,但是在分區(qū)表的統(tǒng)計和加限制條件的查詢方面的性能提升并不明顯。而且對相應的復雜的存儲過程的統(tǒng)計計算未能體現(xiàn)出優(yōu)勢。這可能是由于分區(qū)表設計機制主要是面向磁盤性能優(yōu)化,在閃存上反而有負面影響。
另外我們在Oracle數(shù)據(jù)庫上應用閃存測試時發(fā)現(xiàn),帶子查詢的多表關聯(lián)查詢語句的存儲過程的調用性能表現(xiàn)很差,查看AWR發(fā)現(xiàn)大量的cache latch,出現(xiàn)長時間等待, 而在磁盤存儲上沒有這種情況。我們分析是由于閃存的性能比磁盤高很多,造成cursor數(shù)據(jù)量大,緩存內的latch沖突增加。通過增大share pool和將復雜查詢處理簡化為多個小查詢處理可以解決這個問題,性能也得到明顯提升。
Q & A
Q1 : 請問閃存和磁盤的比較中MTBF是什么意思?
A1:MTBF(Mean Time Before Failure),失敗前平均工作時間。閃存其實是沒有MTBF的概念的,因為閃存有擦寫次數(shù)的限制,數(shù)據(jù)擦寫到一定數(shù)量后,閃存介質就會物理性地損壞,閃存的壽命是可以通過監(jiān)控使用狀況推算出來的。而磁盤的損壞其實是概率,會有MTBF指標。
Q2 : 請問在測試db2的時候,是dpf環(huán)境,還是單機?
A2:單機。
Q3:mysql是基于xfs測試的嗎?
A3:Mysql測試時是基于ext4的。
Q4:閃存產(chǎn)品有沒有不同的系列,類似傳統(tǒng)的高中低端存儲那樣的分類?
A4:閃存也分高中低的,用于企業(yè)級高性能的一般以PCIe NVMe卡的形式為主。其實閃存產(chǎn)品的質量標準還有很多細分,這里就不細說了。
Q5:請問能談談Spacex用的閃存產(chǎn)品嗎?
A5:SpaceX用的是我們嵌入式閃存產(chǎn)品,和我們企業(yè)級閃存采用同樣的技術架構和閃存顆粒。主要用于控制代碼存儲和運行狀態(tài)數(shù)據(jù)存儲。
Q6:請問您有測過云主機的ssd 嗎?
A6 : 云主機的SSD基本上都采用SATA SSD,當前云計算平臺在數(shù)據(jù)庫應用方面還是個弱項。我們下一步計劃在ceph分布式存儲上進行數(shù)據(jù)庫測試,這也是嘗試在云計算平臺上運行關鍵數(shù)據(jù)庫應用。
Q7:寫放大,和抖動的問題現(xiàn)在已經(jīng)改善了很多吧?
A7 :寫放大和抖動問題是考驗閃存廠商的一個關鍵指標,在產(chǎn)品設計的時候就要考慮。各家處理的方式都不一樣。我們能做到***的WAF是6。而在性能抖動方面自認為處理***的是我們的產(chǎn)品,因為性能抖動主要是由垃圾回收處理和磨損平衡處理引起的。而我們采用的分區(qū)擦除算法和三重磨損平衡算法是完全基于對閃存顆粒底層的特性了解和經(jīng)驗積累。另外SSD還有一個很大的問題是性能衰減。使用1,2年后,性能可能只有原來的一半或者更低,性能波動也會頻繁出現(xiàn)。