面對(duì)千億量級(jí)的小文件，存儲(chǔ)系統(tǒng)壓力山大

所謂小文件，指的是存儲(chǔ)占用空間相對(duì)較小的文件，一般來(lái)說(shuō)低于64MB的文件就可以被認(rèn)定為小文件，而大量的小文件大小則在幾KB到幾十KB之間。在云計(jì)算、大數(shù)據(jù)業(yè)務(wù)中，文本、圖片、音樂(lè)等是典型的小文件應(yīng)用場(chǎng)景。

隨著數(shù)字化創(chuàng)新的加速，組織內(nèi)部的數(shù)據(jù)呈現(xiàn)出指數(shù)級(jí)增長(zhǎng)的趨勢(shì)，特別是小文件更是隨著業(yè)務(wù)增長(zhǎng)到一個(gè)巨大的量級(jí)。與大文件的存儲(chǔ)不同的是，大量磁盤在小文件存儲(chǔ)場(chǎng)景中的性能極低，單塊企業(yè)級(jí)SATA磁盤如果全部存儲(chǔ)4KB左右的小文件，帶寬只有520KB/s，遠(yuǎn)遠(yuǎn)小于應(yīng)有的120MB/s的帶寬標(biāo)準(zhǔn)值，很容易因?yàn)榇鎯?chǔ)系統(tǒng)的性能不足造成上層應(yīng)用“卡頓”。把磁盤全部換成固態(tài)盤固然可以解決問(wèn)題，但是，固態(tài)盤的價(jià)格數(shù)倍于SATA磁盤，對(duì)于很多用戶來(lái)說(shuō)，全面的應(yīng)用固態(tài)盤在成本上仍然不現(xiàn)實(shí)。

百億~萬(wàn)億量級(jí)的小文件對(duì)存儲(chǔ)性能提出

而且，每個(gè)應(yīng)用場(chǎng)景對(duì)于存儲(chǔ)系統(tǒng)的性能往往有著不同的要求。例如，某領(lǐng)先電商平臺(tái)已經(jīng)存儲(chǔ)了數(shù)量以百億計(jì)算的圖片文件，這些圖片平均大小在15KB左右，用戶對(duì)于這些圖片文件的讀取完全是隨機(jī)讀取，一旦大量用戶同時(shí)在線訪問(wèn)網(wǎng)址或者搜索商品，往往就會(huì)給存儲(chǔ)系統(tǒng)的隨機(jī)讀寫能力帶來(lái)巨大的挑戰(zhàn)；在交警系統(tǒng)中，路口的抓拍攝像頭會(huì)將違章圖片傳送至區(qū)中心的計(jì)算服務(wù)器，不僅攝像頭數(shù)量多，而且每臺(tái)攝像頭每天都可能生成數(shù)千乃至上萬(wàn)張照片，某市每天相關(guān)圖片寫入甚至超過(guò)一億張，要降低存儲(chǔ)系統(tǒng)的壓力，就需要及時(shí)刪除正常的圖片，這對(duì)存儲(chǔ)系統(tǒng)的寫入、刪除能力要求很高。

?

海量小文件帶來(lái)的問(wèn)題

1、海量數(shù)據(jù)的性能問(wèn)題。這是64K寫的性能測(cè)試，一開(kāi)始的1萬(wàn)到4億個(gè)對(duì)象，這個(gè)時(shí)候會(huì)發(fā)現(xiàn)寫入的性能逐步下降，從開(kāi)始有15K的oes到下降到2.5，實(shí)際上下滑比例已經(jīng)達(dá)到了80%多，海量小文件的沖擊是非常大的。

究其原因，如果用的是Fd，底下的文件是要從Fd到dentry再到inode，superblock，1億的文件，256B，它已經(jīng)占了24G，小文件帶來(lái)的是要直接操作磁盤，直接操作磁盤會(huì)導(dǎo)致性能下降，海量的小文件會(huì)破壞空間的連續(xù)性，會(huì)產(chǎn)生大量的隨即讀寫。海量小文件會(huì)有大量源數(shù)據(jù)，性能還是不能得到流暢。

2、數(shù)據(jù)恢復(fù)效率問(wèn)題， 數(shù)據(jù)在做恢復(fù)的過(guò)程中效率的問(wèn)題，海量場(chǎng)景下恢復(fù)的速度，后者是前者的10倍，海量的小文件場(chǎng)景下，數(shù)據(jù)恢復(fù)的速度比較緩慢，而且效率很低，在此期間如果剛好不巧有業(yè)務(wù)請(qǐng)求過(guò)來(lái)，有可能會(huì)看到Slow Requses或是blocked，是存在風(fēng)險(xiǎn)的。

3、擴(kuò)容、恢復(fù)以后集群的性能還會(huì)出現(xiàn)驟降的情況。如果做了擴(kuò)容或是故障恢復(fù)，這個(gè)時(shí)候大量的小文件可能會(huì)被刪除，可能會(huì)出現(xiàn)大量的碎片，這個(gè)碎片可能出現(xiàn)在磁盤上，如果不進(jìn)行碎片的回收，里面系統(tǒng)的性能會(huì)出現(xiàn)驟降的情況，這是我們測(cè)的一組數(shù)據(jù)，前面很平穩(wěn)，一旦擴(kuò)容等恢復(fù)以后，這個(gè)比例會(huì)變大。

4、海量小文件的場(chǎng)景，數(shù)據(jù)的遷移效率比較低?？赡芟胗脭?shù)據(jù)冷熱分層的方式把熱數(shù)據(jù)移到冷的存儲(chǔ)池，這個(gè)時(shí)候有大量的小文件在這個(gè)過(guò)程中會(huì)產(chǎn)生遷移，而且這個(gè)遷移的過(guò)程中前面也會(huì)有，遷移以后數(shù)據(jù)可能進(jìn)行大量的刪除操作。之前測(cè)試的4000萬(wàn)的小文件遷移消耗時(shí)間大于72個(gè)小時(shí)，算下來(lái)要兩天多的時(shí)間。這種情況下遷移的效率太低了。

解決小文件問(wèn)題的幾點(diǎn)想法

海量小文件，是不是可以做合并？合并之后的文件，不是體積很小的文件，空間的使用效率是比較高的，對(duì)磁盤還是比較友好的。合并以后是不是可以提高讀寫的性能？

我們都知道，現(xiàn)在流數(shù)據(jù)，而且是寫在對(duì)象里，源數(shù)據(jù)是不是可以獨(dú)立？為什么做獨(dú)立？源數(shù)據(jù)獨(dú)立有兩個(gè)好處，源數(shù)據(jù)可以更加靈活的做選擇存儲(chǔ)，可以對(duì)這些源數(shù)據(jù)做一些其他的操作，比如說(shuō)源數(shù)據(jù)是不是可以做其他方面的管理、檢索，都很方便的做。是不是可以把源數(shù)據(jù)部分抽出來(lái)？

同步和刪除的流程是不是可以改進(jìn)？如果做到第一點(diǎn)，文件做了合并的話，傳輸也是可以做合并的，而且刪除操作的時(shí)候，批量刪除是可以提升效率的。

基于這三點(diǎn)，Sandstone Mos針對(duì)海量小文件的問(wèn)題提出了方案。

Sandstone Mos海量小文件的方案

第一步我們把源數(shù)據(jù)從Data pool抽出來(lái)進(jìn)行分離，源數(shù)據(jù)存在index pool，部署方式是不是和其他的部署方式不一樣，沒(méi)必要和Data pool綁在一起。每個(gè)對(duì)象把源數(shù)據(jù)抽出來(lái)以后，放在BI，源數(shù)據(jù)有它的BI，會(huì)有對(duì)應(yīng)的Data pool數(shù)據(jù)實(shí)體。我們?nèi)サ絀D里的Index，多個(gè)對(duì)象放在一起管理，這個(gè)時(shí)候很方便的能實(shí)現(xiàn)多個(gè)版本的數(shù)據(jù)管理。

這方面我們也需要一些數(shù)據(jù)，簡(jiǎn)化整體的數(shù)據(jù)結(jié)構(gòu)。比如說(shuō)讀寫數(shù)據(jù)有非常重要的結(jié)構(gòu)，在應(yīng)用數(shù)據(jù)結(jié)構(gòu)的時(shí)候發(fā)現(xiàn)有很多數(shù)據(jù)，這些數(shù)據(jù)不好的地方是沒(méi)怎么用、沒(méi)什么用，放在這里很占空間。里面有RGW很占空間，讀寫數(shù)據(jù)的時(shí)候其實(shí)沒(méi)必要關(guān)心這個(gè)對(duì)象是什么樣的，我們也去掉一部分的冗余數(shù)據(jù)簡(jiǎn)化數(shù)據(jù)結(jié)構(gòu)。

在這上面我們也做了文件合并的工作。開(kāi)始的想法是不同的對(duì)象可以寫到一個(gè)大項(xiàng)里，實(shí)際上這里會(huì)有幾個(gè)問(wèn)題，對(duì)象寫進(jìn)來(lái)以后應(yīng)該朝哪個(gè)地方寫？后面會(huì)講一下大概的流程，處理小文件寫入的時(shí)候可不可以給一些因素簡(jiǎn)化流程？不同的bucke的小文件合并到不同的大文件里，如果對(duì)象是同一個(gè)bucket會(huì)寫到同一個(gè)大對(duì)象里。我們都知道用的是shard的思想，BI分了不同的shard，為了簡(jiǎn)化處理流程，，不同bucket的小文件存到不同的大文件。

文件合并以后要讀的時(shí)候應(yīng)該怎么讀？小文件的讀取比較簡(jiǎn)單，存進(jìn)去改一下加上offs和lenght就可以了，所有的對(duì)象指向的數(shù)據(jù)實(shí)體只有一個(gè)，對(duì)象讀的時(shí)候知道開(kāi)始位置就可以得到對(duì)應(yīng)小文件的數(shù)據(jù)。還是會(huì)有問(wèn)題，簡(jiǎn)單的話是合并就完了，問(wèn)題是這個(gè)東西進(jìn)來(lái)以后，應(yīng)該寫到哪個(gè)對(duì)象上？所以對(duì)象進(jìn)來(lái)以后可能好幾層，這里就會(huì)有一個(gè)問(wèn)題，假設(shè)兩個(gè)對(duì)象是寫到同一個(gè)大對(duì)象上，這個(gè)大對(duì)象的空間分配會(huì)是一個(gè)關(guān)鍵的問(wèn)題，對(duì)象的空間分配一定要統(tǒng)一一個(gè)來(lái)源，可以避免寫同一個(gè)對(duì)象，保證區(qū)間不會(huì)相互交集。我們?cè)贐ucket使用omap_key存儲(chǔ)大對(duì)象元數(shù)據(jù)，可以起到空間分配的作用，對(duì)象寫進(jìn)來(lái)以后，最后是不是要確定對(duì)象放在哪個(gè)Bucket shard上，可以看到需要用哪個(gè)merged object，可能第一個(gè)寫0到24，第二個(gè)會(huì)記一個(gè)狀態(tài)，會(huì)把他的狀態(tài)記為已經(jīng)使用，下一次線程過(guò)來(lái)就不會(huì)用空間。會(huì)把空閑的空間分配給他，我每個(gè)線程寫的時(shí)候拿到的空間分配信息之后，就可以寫相應(yīng)的偏移。我們每個(gè)對(duì)象在上面都做了空間的管理。

刪除操作可能會(huì)出現(xiàn)幾個(gè)問(wèn)題，刪除的空間怎么進(jìn)行回收？可能刪了幾個(gè)小對(duì)象后大對(duì)象整體會(huì)出現(xiàn)空洞的情況，什么時(shí)候進(jìn)行整體的回收？進(jìn)行整體回收的時(shí)候這些小文件要怎么進(jìn)行適度的遷移？前面說(shuō)的空間管理情況下有條目的狀態(tài)，既可以在空間分配中用到，也可以在刪除小文件的時(shí)候用到，刪除小文件的時(shí)候是異步刪除的方式，可以在這個(gè)大對(duì)象上做個(gè)狀態(tài)的更改，里面會(huì)涉及到兩個(gè)操作，不單只是刪除小文件的時(shí)候要?jiǎng)h原來(lái)的小文件BI，還要改大BI的狀態(tài)。

我們有兩個(gè)對(duì)象可能被刪除會(huì)標(biāo)deleted的狀態(tài)，刪除的時(shí)候如果數(shù)據(jù)不進(jìn)行立刻的回收，空間是存在一定的浪費(fèi)。這個(gè)時(shí)候要靈活運(yùn)用object的接口，這個(gè)時(shí)候空間做了一定的回收，所以這個(gè)接口是比較友好的，對(duì)于快速釋放空間，提高空間的利用率，有可能大對(duì)象的區(qū)間被刪除，當(dāng)空間使用率達(dá)到一定程度的時(shí)候，我們要進(jìn)行整體的回收，大對(duì)象可以反向索引到每個(gè)小對(duì)象上，小對(duì)象也需要記錄自己所處的大對(duì)象，這兩個(gè)操作是為了后面鋪墊的，要做刪除操作的時(shí)候，小對(duì)象必須自己清楚，我是屬于哪個(gè)大對(duì)象的？刪除的時(shí)候可以在上面記這個(gè)狀態(tài)，大對(duì)象有要記自己被哪些小對(duì)象引用，為什么這樣處理？如果說(shuō)空間使用率低到一定程度的時(shí)候，要進(jìn)行整體的回收，這個(gè)時(shí)候還在使用小文件怎么辦？大對(duì)象必須反向索引到有哪些小對(duì)象在用它？這個(gè)時(shí)候我們把小文件的數(shù)據(jù)挪出來(lái)，遷移到其他大對(duì)象里。整體的機(jī)器操作是完全的異步方式，如果你在刪除對(duì)象的時(shí)候會(huì)進(jìn)行res的，為了處理其他的問(wèn)題，把整個(gè)過(guò)程變成異步的，包括BI的刪除和數(shù)據(jù)的刪除都變成異步的方式。

同步和數(shù)據(jù)遷移原理是一樣的，無(wú)非是把大量的數(shù)據(jù)從一個(gè)站點(diǎn)，從一個(gè)存儲(chǔ)池遷到另一個(gè)存儲(chǔ)池，這一點(diǎn)是最為頭疼的，會(huì)涉及到非常多邏輯的問(wèn)題，比如說(shuō)合并后的文件是怎么進(jìn)行同步的？小文件的元數(shù)據(jù)，合并以后的文件進(jìn)行同步，元數(shù)據(jù)怎么同步，是不是會(huì)存在先后順序的問(wèn)題？

大家如果了解的話，多站點(diǎn)的同步分為兩部分，一個(gè)是全量同步，一個(gè)是增量同步，兩個(gè)同步的方式和base的實(shí)際結(jié)構(gòu)是不太一樣的。如果你是全量投入的情況下，AB兩個(gè)站點(diǎn)是進(jìn)行全量同步的，我做全量同步的時(shí)候會(huì)把里面的對(duì)象都拿過(guò)來(lái)，增量同步就不一樣。先分場(chǎng)景做，我第一步是先把這些合并之后的文件、數(shù)據(jù)整體的拉過(guò)去，包括前面提到的大對(duì)象，實(shí)際上也有自己的BI，這個(gè)時(shí)候?qū)ξ襾?lái)說(shuō)也是一個(gè)對(duì)象，我會(huì)把這些數(shù)據(jù)統(tǒng)一丟過(guò)去，小文件的元數(shù)據(jù)還是維持。

增量同步的情況比較復(fù)雜，這個(gè)大對(duì)象是寫到100，這個(gè)時(shí)候怎么把它同步過(guò)來(lái)？這里面有點(diǎn)取巧，像這種情況下，我們要處理這個(gè)邏輯，前面全量可能把這個(gè)拉過(guò)去，根據(jù)多個(gè)BI，如果發(fā)現(xiàn)是多條邊、是寫在同一個(gè)同類項(xiàng)上，這個(gè)時(shí)候會(huì)把數(shù)據(jù)做合并類似于前面同步的方式，把數(shù)據(jù)合并丟過(guò)去。最后源數(shù)據(jù)還是通過(guò)BI的方式，把源數(shù)據(jù)拉過(guò)來(lái)，每次請(qǐng)求的效率會(huì)比以前高一些。

兩個(gè)數(shù)據(jù)池遷移的時(shí)候，跟全量同步的場(chǎng)景是一樣的，全量同步的情況下和存儲(chǔ)數(shù)據(jù)池的遷移是一樣的場(chǎng)景，這個(gè)時(shí)候沒(méi)有單列存儲(chǔ)池的場(chǎng)景。

總結(jié)

1.海量小文件的性能。我們?cè)谧鐾晡募喜⒁院螅募?shù)是能明顯下降的，解決海量數(shù)據(jù)場(chǎng)景下的性能問(wèn)題，文件合并以后，對(duì)于磁盤來(lái)說(shuō)是比較友好的，合并以后可能是比較大的文件，比如說(shuō)我們合并至少都是4M的文件，合并以后文件的數(shù)據(jù)量會(huì)明顯下降。

2.恢復(fù)效率。文件合并以后效率也可以得到巨大的支撐，原來(lái)都是32K的文件，有100個(gè)32K的文件，合并以后是3M多的文件，每次請(qǐng)求要恢復(fù)的文件數(shù)目明顯減少了。

3.擴(kuò)容后的性能驟降的問(wèn)題，合并后的文件對(duì)于空間的使用率更高，就算會(huì)出現(xiàn)大量的數(shù)據(jù)刪除情況，這個(gè)時(shí)候?qū)τ诖疟P的使用也是更加友好的，因?yàn)檫@個(gè)時(shí)候磁盤也不會(huì)出現(xiàn)過(guò)度的空洞碎片。

4.數(shù)據(jù)遷移的整體做了優(yōu)化，數(shù)據(jù)合并之后遷移的效率也會(huì)明顯的提高，前面可能分了100個(gè)小文件，可能是請(qǐng)求100次的32K文件，可能是100次32K的請(qǐng)求，合并之后只需要一次移過(guò)量就可以了，后面的所有操作都是不需要再跨兩個(gè)Pool。