作為一個做企業(yè)存儲市場的存儲人，最近兩年我不斷被重刪壓縮撩撥著。對于重刪壓縮這個技術(shù)的好壞，真實(shí)需求還是偽需求大家看法不一。今天我就只能談?wù)勎覀�人的看法。更多觀點(diǎn)請關(guān)注“圍爐煮酒論IT”公眾號
重刪壓縮是什么？
重刪和壓縮時完全不同的兩種技術(shù)，解決不同的問題。
重刪：就是說有很多分相同的數(shù)據(jù)，我只存儲其中一份，其他的重復(fù)數(shù)據(jù)塊我保留一個地址引用到這個唯一存儲的塊即可。
壓縮：將一個大字符串中的子串用一個很簡短的數(shù)字來標(biāo)記，然后檢索該字符串出現(xiàn)的位置，用個簡單的字符來替代。從而來減少數(shù)據(jù)表達(dá)所需要的空間，帶來空間節(jié)省。
比如說用1代表“AB”，用2代表“CD”，然后用255 來代表“hanfute”。1到255只需要8個bit，而“AB”“CD”或者“hanfute”則需要很多的空間，這樣多次掃描替代之后，就可以快速的將數(shù)據(jù)縮減。
用通俗的話說：重刪就是講相同的東西只存儲一次，而壓縮則是改造數(shù)據(jù)排布用一種算法來統(tǒng)計(jì)數(shù)據(jù)的排布模式，從而達(dá)到減少數(shù)據(jù)存儲的模式。
重刪的實(shí)現(xiàn)
重刪的實(shí)現(xiàn)技術(shù)比較簡單，最簡單的使用就比如我們的郵件服務(wù)器，我轉(zhuǎn)發(fā)一份郵件給100個人，大家收到我的郵件后就會產(chǎn)生100個一樣的文件，假設(shè)大家的數(shù)據(jù)盤使用的共享存儲，存儲只需要在每個人存入文件的時候查詢一下這個文件本地有沒有，有我就不再存儲。這樣在存儲上就只存儲了一個文件。這是一個最樸素的理解。
這里面涉及到幾個問題：
1、存儲怎么知道這個文件自己已經(jīng)存儲了？
2、如果不是存文件，而是塊存儲該怎么辦？
存儲怎么知道這個文件自己已經(jīng)有了呢？
在計(jì)算機(jī)里面有個技術(shù)名字叫做”指紋”，非常的形象生動，就好像每個人的指紋肯定不一樣，那么我們是不是可以用一個很小的數(shù)據(jù)來標(biāo)記一個文件的唯一信息。
這里有很多的算法可以快速的得到一個唯一值，比如說MD5算法、Sha算法。
- Sha算法是一種不可逆的數(shù)據(jù)加密算法，只能算指紋出來，但是無法通過指紋反推出來內(nèi)容。
- 他可以經(jīng)一個小于2^64的數(shù)據(jù)轉(zhuǎn)化成一個160位的不重復(fù)的指紋，最關(guān)鍵的是他的計(jì)算還很快。
- 所以比較兩個數(shù)據(jù)是否相同，就可以通過計(jì)算他的指紋，然后去對比指紋，而不是進(jìn)行數(shù)據(jù)的逐字節(jié)比對。效率要高得多。
這個指紋有沒有可能重復(fù)，比如說兩個人的指紋相同？
按照sha256算法，在4.8*10^29個數(shù)據(jù)中出現(xiàn)兩個數(shù)據(jù)指紋重復(fù)的概率大概小于10^-18.10^-18就是我們所說的16個9的可靠性。
轉(zhuǎn)化成存儲語言我們來討論一下。假如說我們的存儲每秒鐘寫入的10萬個文件，按照存儲7*24*365天工作，那么每年寫入的數(shù)據(jù)為365*24*3，600*10，000=3.15*10^12個文件。如果想讓存儲出現(xiàn)哈希碰撞而導(dǎo)致重刪丟數(shù)據(jù)（概率大于10^-18），那么需要運(yùn)行1.52*10^17年，可能會遇到一次。
其實(shí)我們主流存儲設(shè)備的可靠性一般為99.9999%也就是我們常說的6個9，是遠(yuǎn)遠(yuǎn)不如哈希值可靠的。這也是很多人擔(dān)心的重刪會不會把我的數(shù)據(jù)刪除沒有了，導(dǎo)致我的數(shù)據(jù)損壞呢，其實(shí)不用這個擔(dān)心。
但是還是有人會擔(dān)心，怎么辦呢？還有另外一種方法，那就是遇到一個新數(shù)據(jù)，我就用兩種算法，存儲兩個hash值，遇到了重復(fù)數(shù)據(jù)進(jìn)行兩重hash比對。但是有人還是對hash算法有擔(dān)心，也簡單，對于重復(fù)數(shù)據(jù)我們再進(jìn)行一次逐字節(jié)比對嘛，不過就是會稍微影響性能。
如果不是文件，塊存儲該怎么處理？
重復(fù)數(shù)據(jù)刪除技術(shù)在塊存儲的實(shí)現(xiàn)比較多樣化。
最簡單最基本的方式就是直接定長重刪。所以寫入的數(shù)據(jù)按照固定長度進(jìn)行切片，切片后進(jìn)行hash計(jì)算，然后進(jìn)行寫入處理，非重復(fù)數(shù)據(jù)就單獨(dú)寫入，重復(fù)數(shù)據(jù)就寫入引用即可。
但是這種處理方式重刪率是比較低的，比如說一個文件，我們只在文件上添加一個字符，然重新寫入，這個文件采用定長方式切片后就無法找到和以前相同的塊，導(dǎo)致無法被重刪掉數(shù)據(jù)。因此業(yè)界也有很多的邊長重刪的算法。
但是變長重刪對性能和算法要求都比較高，同時對于CPU內(nèi)存消耗也大，影響了數(shù)據(jù)的實(shí)時處理效率。畢竟存儲主要還是處理主機(jī)的IO讀寫響應(yīng)的。只有在備份歸檔領(lǐng)域用的比較多，因?yàn)檫@個場景節(jié)省空間比快速響應(yīng)要求高的多。
以下面這個圖片為例，變長重刪效率可能達(dá)到10：1，而定長重刪只有3：1.
因此，對于全閃存存儲這種響應(yīng)要求高的，建議定長重刪，速度快。對于歸檔、備份這種冷存儲建議變長重刪，重刪率高節(jié)省成本。
重刪總結(jié)
其實(shí)重刪這個功能在全閃存市場用處并不大，因?yàn)楹芏鄷r候定長重刪的效果很有限，比較典型的比如數(shù)據(jù)庫場景，重刪率只有可憐的1.05：1幾乎可以忽略不計(jì)。
對于全閃存來說壓縮更有效，下面我們來看看壓縮技術(shù)。
壓縮技術(shù)的實(shí)現(xiàn)
壓縮技術(shù)由來已久，分為無損壓縮和有損壓縮。
有損壓縮主要用于圖像處理領(lǐng)域，比如說我微信發(fā)一個照片，明明本地10M的高清圖片傳輸?shù)脚笥咽謾C(jī)里面就有300K的圖片。這主要為了節(jié)省網(wǎng)絡(luò)傳輸?shù)牧髁恳约拔⑿糯鎯臻g節(jié)省。
存儲系統(tǒng)領(lǐng)域用的壓縮都是無損壓縮。借助于算法的普及，業(yè)界主流存儲廠商的壓縮實(shí)現(xiàn)幾乎都沒有算法上的區(qū)別，只是在于壓縮的實(shí)現(xiàn)選擇上，主要考慮兼顧性能和數(shù)據(jù)縮減率。
那么壓縮對存儲的性能影響有多大？
壓縮對存儲的性能影響有多大
基于EMC Unity Sizer的性能評估工具，我們大概可以看到開啟壓縮相對于不開啟壓縮，IOPS從20萬左右降低到了12萬，存儲性能下降大概是40%。
其實(shí)我們最新的intel CPU里面已經(jīng)集成了壓縮算法，我上次私下里和我們測試經(jīng)理進(jìn)行了數(shù)據(jù)的了解，在開啟壓縮，滿負(fù)載的進(jìn)行存儲性能壓力測試，存儲CPU利用率75%的時候，其中用于壓縮所消耗的CPU資源不到3%。為什么存儲性能下降了這么多？？？
實(shí)現(xiàn)壓縮帶來的ROW架構(gòu)性效率下降
我們傳統(tǒng)的存儲，不需要壓縮的時候，我們每個數(shù)據(jù)都是由自己在硬盤上的固定地址的。比如說LUN1的LBA00xx64~00x128 存儲在5號磁盤的低8個扇區(qū)的第X位開始的連續(xù)64bit地址上。如果我以8KB為存儲的最小塊大小，那么每個8KB都是存儲在一個固定的8KB的物理盤片的具體物理地址上。在我第一次寫入的時候被我所獨(dú)占。
以后這個8KB不管怎么改寫讀取，都是8KB。記錄這些數(shù)據(jù)存儲的位置的方式非常簡單。假如說一個LUN一共1TB，那么我就記錄這么1TB分布在幾個盤里面，用一個很簡單的算法將他分布在那個盤的那個物理地址輕松地就算了出來。我只需要記錄一共由幾塊盤，一共組成了幾個RAID組，每個RAID條帶深度是多少，起始地址是多少，就能在內(nèi)存中快速的用這些基本數(shù)據(jù)算出數(shù)據(jù)對應(yīng)的物理地址是多少。
這種基本的寫入模式叫做COW（copy on write），就是說寫前拷貝。
傳統(tǒng)的RAID模式注定了 我們只要改寫一個位，就需要將原有數(shù)據(jù)和校驗(yàn)數(shù)據(jù)同時讀取，然后在內(nèi)存中計(jì)算后再寫進(jìn)去。讀取的原因是為了方式寫入失敗我可以恢復(fù)回去.
而寫前拷貝并不是指的這個問題，而是指在有數(shù)據(jù)快照的情況下如何寫入，這個時候我們不能破壞快照的數(shù)據(jù)，就只能將原有位置的數(shù)據(jù)拷貝到一個專門的快照存儲區(qū)域。這稱之為COW，他是相對于ROW（redirect on write）而發(fā)明的一個詞。
國內(nèi)很多人對于COW叫做“靠”架構(gòu)。
由于壓縮后一個8KB的數(shù)據(jù)有可能變成了1Kb、2KB、3KB也可能是8KB，那么我的數(shù)據(jù)就是一個可變的長度，如果還采用物理地址和邏輯地址一一對應(yīng)的方式我就達(dá)不到節(jié)省空間的效果了。我將一個8KB的塊壓縮成了1KB，結(jié)果你還是給我分配了8KB物理空間來存儲，這簡直就是不合適。因此在壓縮的實(shí)現(xiàn)上，存儲一般都采用ROW架構(gòu)來實(shí)現(xiàn)。
ROW帶來了那些性能下降
1、由于ROW架構(gòu)每個塊都需要單獨(dú)存儲一次地址的映射關(guān)系，所以容量越大，產(chǎn)生的元數(shù)據(jù)量也越大，所以ROW架構(gòu)一般容量越大，性能越差。
為了更好的處理數(shù)據(jù)，肯定想元數(shù)據(jù)全部在內(nèi)存中緩存是效率最好的，所以ROW架構(gòu)存儲對內(nèi)存的訴求很大。
2、由于ROW架構(gòu)每次寫入都需要記錄地址元數(shù)據(jù)，處于可靠性考慮，我們肯定需要持久化，每次都要元數(shù)據(jù)下盤，這樣一次寫入就會產(chǎn)生兩次的操作，寫入元數(shù)據(jù)，寫入數(shù)據(jù)。
3、由于ROW架構(gòu)的數(shù)據(jù)寫入采用了新找地址寫入，這樣原來邏輯上連續(xù)的數(shù)據(jù)會被不斷的離散化，最終連續(xù)IO也會變成隨機(jī)IO，對性能影響較大
4、ROW帶來了另一個問題，以上圖為例，我們?nèi)绻麤]有快照，那么C這個數(shù)據(jù)塊就是一個無效的數(shù)據(jù)，但是我們并不會在寫入的時候立即的刪除這個數(shù)據(jù)，因?yàn)闀绊懶阅�。我們就需要在沒有連續(xù)空間或者業(yè)務(wù)空閑的時候?qū)ｉT來處理這些失效的塊。這個也就是我們經(jīng)常所說的垃圾回收，垃圾回收對性能影響很大，很多廠商干脆就不回收，而采用直接填空寫入的方式。不管哪種方式對于垃圾空間的重復(fù)利用是對性能影響極大的一個操作。
這些問題在傳統(tǒng)硬盤場景影響更為明顯，這也是以前Netapp在HDD時代性能被詬病的一個原因。
而SSD盤內(nèi)部的數(shù)據(jù)處理也是類似，SSD中開啟垃圾回收導(dǎo)致的性能下降被稱之為“寫懸崖”
壓縮總結(jié)：
壓縮對于存儲性能帶來的沖擊，根本不是來自與壓縮本身，而是由于實(shí)現(xiàn)壓縮的架構(gòu)而帶來的影響。
按照當(dāng)前業(yè)界主流存儲廠商的軟件架構(gòu)和效率來評估，一般ROW架構(gòu)的存儲相對于COW架構(gòu)在性能上大概要下降35%左右，而壓縮本身帶來的性能損失一般在5%以內(nèi)，所以對于整個存儲系統(tǒng)來說，開啟壓縮性能下降幅度大概在40%左右
在ROW架構(gòu)上實(shí)現(xiàn)重刪還有有哪些沖擊呢
相對于壓縮在內(nèi)存中計(jì)算完成后就直接寫入，重刪的影響更大：
1、需要有單獨(dú)的空間來存儲指紋（帶來了內(nèi)存可支持存儲空間越來越�。�
2、每次寫入都需要進(jìn)行指紋比對（讀寫時延增加）
3、對于一個新數(shù)據(jù)塊的寫入產(chǎn)生了大幅的放大（指紋庫記錄一次、數(shù)據(jù)塊寫入一次、元數(shù)據(jù)記錄映射一次），所以很多時候重刪帶來的性能主要在時延。
極端情況：一個典型的極端情況，如果是HDD存儲環(huán)境，我們假設(shè)我們ROW系統(tǒng)的定長塊大小是8KB，如果我寫入一個128KB的數(shù)據(jù)，會被切片成16個數(shù)據(jù)片，進(jìn)行16*3次數(shù)據(jù)下盤操作，最終的時延可以達(dá)到HDD本身的48倍，假設(shè)一個HDD響應(yīng)是5ms，那么這個整個IO的響應(yīng)時延達(dá)到了200ms以上，對于SAN存儲來說這幾乎是不可接受。
如何實(shí)現(xiàn)高效的重刪壓縮
重刪壓縮對性能的影響大家都知道，如何降低存儲壓縮帶來的性能影響，我們在下一篇文章來詳細(xì)的介紹。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：淺談存儲重刪壓縮技術(shù)
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839624469.html
相關(guān)文章
