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

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

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

百億~萬億量級的小文件對存儲性能提出

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

?

海量小文件帶來的問題

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

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

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

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

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

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

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

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

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

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

Sandstone Mos海量小文件的方案

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

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

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

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

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

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

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

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

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

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

總結(jié)

1.海量小文件的性能。我們在做完文件合并以后，文件數(shù)是能明顯下降的，解決海量數(shù)據(jù)場景下的性能問題，文件合并以后，對于磁盤來說是比較友好的，合并以后可能是比較大的文件，比如說我們合并至少都是4M的文件，合并以后文件的數(shù)據(jù)量會明顯下降。

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

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

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