一種對于海量小文件在分布式存儲系統(tǒng)中上載的方法【
技術領域：
】[0001]本發(fā)明涉及一種上載方法，具體涉及一種對于海量小文件在分布式存儲系統(tǒng)中上載的方法?！?br>背景技術：
】[0002]數字化時代的今天，隨著需要存儲的數據量日益增長，單一的存儲硬件設備已經難以在容量和性能上滿足數目眾多的行業(yè)的存儲需求。為了滿足數目繁多的行業(yè)對非結構化數據的存儲需求，一批分布式文件系統(tǒng)應運而生，這其中的代表者如PNFS、GPFS、Lustre、GoogleFS,HDFS等。這些分布式文件系統(tǒng)都是通過軟件來將硬件集群進行統(tǒng)一管理，對外展現一個統(tǒng)一的存儲池，從而達到對硬件資源進行虛擬化整合的目的。[0003]對于目前分布式結構數據存儲來說，根據其存儲性，大致可分為大文件存儲和小文件存儲。大文件存儲例如:視頻存儲、高性能計算等，小文件存儲例如:數字圖書館、網上商城等。對于目前成熟的分布式文件系統(tǒng)，對大文件的存儲可謂是得心應手，而當面臨海量小文件時，卻往往顯得力不從心。為了減少小文件存儲對分布式文件系統(tǒng)的壓力，很多專用接口的文件系統(tǒng)，如GoogleFS、HDFS、TBFS，均采用將多個小文件聚合成大文件的方式，來減緩頻繁訪問對于底層磁盤件的壓力，從而達到提供服務能力的效果。而提供通用接口的分布式文件系統(tǒng)，對于小文件存儲則沒有對應的優(yōu)化策略，導致在數字圖書館、網上商城等小文件應用的表現不容樂觀。[0004]數字圖書館和網上商城這類應用的訪問模式是集中上載，然后進行隨機讀取。上載時，通常需要在短時間內創(chuàng)建和寫入上億個小文件；上載完畢后，這些小文件會隨時被讀取。據用戶測試反應，通常一個TB的小文件上載需要的時間往往大于48小時，這樣的性能令人無法忍受。[0005]對于分布式文件系統(tǒng)的小文件上載壓力可歸為以下兩個方面:其一是上載時元數據和數據的創(chuàng)建壓力，即需要在短時間內創(chuàng)建上億個文件；其二是上載時數據的寫壓力，即需要在短時間內將上億個小文件寫入磁盤。為了解決第一個問題，GPFS等文件系統(tǒng)采用了多元數據服務器的方法，其不足在于對于硬件資源比較浪費，成本相對較高；對于第二個問題，GoogleFS等文件系統(tǒng)采用了多個小文件聚合成大文件的方式來提高硬盤的1帶寬，不足之處在于需要增加額外的管理數據，復雜度較高?！?br/>發(fā)明內容】[0006]針對現有技術的不足，本發(fā)明提出一種對于海量小文件在分布式存儲系統(tǒng)中上載的方法，根據操作系統(tǒng)的標準POSix語義，合并文件的查找和創(chuàng)建動作；該方法操作簡單，克服了小文件上載速率不足的缺陷，提高了整體上載的性能，從而減少了硬件資源浪費，降低了成本。[0007]本發(fā)明的目的是采用下述技術方案實現的:[0008]針對現有技術的不足，本發(fā)明提出一種對于海量小文件在分布式存儲系統(tǒng)中上載的方法，所述上載方法包括下述步驟:[0009](I)客戶端根據操作系統(tǒng)的標準POSIX語義，查找?guī)в袆?chuàng)建請求的目標文件；[0010](2)元數據服務器對文件進行預創(chuàng)建，建立文件池；[0011](3)利用元數據服務器聚合管理文件元數據；[0012](4)經內核模塊對文件排序后批量同步上載。[0013]優(yōu)選的，所述步驟(I)中，所述客戶端為分布式文件系統(tǒng)的入口，根據文件系統(tǒng)的標準POSIX語義，合并文件的查找和創(chuàng)建動作；如果檢測到本次查找的意圖是創(chuàng)建，則在服務端完成創(chuàng)建動作，并由查找請求將對應文件元數據帶回。[0014]優(yōu)選的，所述步驟(2)中，所述元數據服務器對文件進行預創(chuàng)建步驟如下:[0015]2-1為待創(chuàng)建文件分配唯一標識；[0016]2-2向數據服務器發(fā)起對象創(chuàng)建請求，并等待處理完成；[0017]2-3進行元數據創(chuàng)建操作；[0018]2-4返回客戶端。[0019]進一步地，所述步驟2-3中，所述進行元數據創(chuàng)建操作，包括在元數據服務器上預先創(chuàng)建一定數目的文件，并放入備用文件池中；當客戶端有創(chuàng)建請求到來時，從文件池中分配一個文件，返回給客戶端即可；當空閑文件池中沒有可用文件時，元數據服務器直接向數據服務器發(fā)起對象創(chuàng)建請求，同時，喚醒后臺線程向文件池填充空閑文件。[0020]優(yōu)選的，所述步驟(3)中，所述聚合管理是將文件的元數據存放在一個元數據文件中。[0021]進一步地，如果一個元數據文件管理N個元數據，此時操作磁盤的次數將由原來的N次減小為I次。[0022]優(yōu)選的，所述步驟(4)中，所述批量同步上載的方法包括下述步驟:[0023]步驟4-1.將多個小文件同時寫入操作系統(tǒng)的文件緩存，由系統(tǒng)后臺線程回寫，回寫時按批聚合，不進行單次操作的磁盤同步；[0024]步驟4-2.引入內核模塊，按照文件在磁盤上的數據塊排列順序，從小到大并發(fā)同步，使得磁盤訪問按順序進彳丁，減少磁頭跳動，提聞磁盤性能；[0025]步驟4-3.對由元數據發(fā)起的創(chuàng)建對象請求進行批量聚合處理，完成同步上載。[0026]與最接近的現有技術比，本發(fā)明的優(yōu)異效果為:[0027]本發(fā)明針對海量小文件在分布式存儲系統(tǒng)中上載的方法，結合分布式文件系統(tǒng)客戶端、元數據服務器和數據服務器各個組件的特性，對客戶端、元數據服務器和數據服務器三個組件進行同時優(yōu)化。一方面大大提高了海量小文件上載性能，優(yōu)化了系統(tǒng)總文件上載過程中創(chuàng)建速率，另一方面，減少了磁盤訪問頻率和硬件資源浪費，降低了成本，對于保護硬盤、延長其硬盤使用壽命也大有裨益?！靖綀D說明】[0028]如圖1所示為本發(fā)明中元數據服務器創(chuàng)建請求的流程圖?！揪唧w實施方式】[0029]下面結合附圖對本發(fā)明作進一步詳細說明。[0030]如圖1所示，所述上載方法包括下述步驟:[0031](I)客戶端根據操作系統(tǒng)的標準POSIX(PortableOperatingSystemInterface表示可移植操作系統(tǒng)接口)語義，查找?guī)в袆?chuàng)建請求的目標文件；[0032]其中，所述客戶端為分布式文件系統(tǒng)的入口，根據文件系統(tǒng)的標準POSIX(PortableOperatingSystemInterface表不可移植操作系統(tǒng)接口)語義，合并文件的查找和創(chuàng)建動作；如果檢測到本次查找的意圖是創(chuàng)建，則在服務端完成創(chuàng)建動作，并由查找請求將對應文件元數據帶回。[0033](2)元數據服務器對文件進行預創(chuàng)建，建立文件池；[0034]其中，所述元數據服務器對文件進行預創(chuàng)建步驟如下:[0035]2-1為待創(chuàng)建文件分配唯一標識；[0036]2-2向數據服務器發(fā)起對象創(chuàng)建請求，并等待處理完成；[0037]2-3進行元數據創(chuàng)建操作；[0038]其中，所述進行元數據創(chuàng)建操作，包括在元數據服務器上預先創(chuàng)建一定數目的文件，并放入備用文件池中；當客戶端有創(chuàng)建請求到來時，從文件池中分配一個文件，返回給客戶端即可；當空閑文件池中沒有可用文件時，元數據服務器直接向數據服務器發(fā)起對象創(chuàng)建請求，同時，喚醒后臺線程向文件池填充空閑文件。[0039]2-4返回客戶端。[0040](3)利用元數據服務器聚合管理文件元數據；[0041]其中，所述聚合管理是將文件的元數據存放在一個元數據文件中；[0042]如果一個元數據文件管理N個元數據，此時操作磁盤的次數將由原來的N次減小為I次。[0043](4)經內核模塊對文件排序后批量同步上載。[0044]其中，其方法包括下述步驟:[0045]步驟4-1.將多個小文件同時寫入操作系統(tǒng)的文件緩存，由系統(tǒng)后臺線程回寫，回寫時按批聚合，不進行單次操作的磁盤同步；[0046]步驟4-2.引入內核模塊，按照文件在磁盤上的數據塊排列順序，從小到大并發(fā)同步，使得磁盤訪問按順序進彳丁，減少磁頭跳動，提聞磁盤性能；[0047]步驟4-3.對由元數據發(fā)起的創(chuàng)建對象請求進行批量聚合處理，完成同步上載。[0048]最后應當說明的是:以上實施例僅用以說明本發(fā)明的技術方案而非對其限制，盡管參照上述實施例對本發(fā)明進行了詳細的說明，所屬領域的普通技術人員依然可以對本發(fā)明的【具體實施方式】進行修改或者等同替換，而這些未脫離本發(fā)明精神和范圍的任何修改或者等同替換，其均在申請待批的本發(fā)明的權利要求保護范圍之內?！局鳈囗棥?.一種對于海量小文件在分布式存儲系統(tǒng)中上載的方法，所述上載方法包括下述步驟:(1)客戶端根據操作系統(tǒng)的標準POSix語義，查找?guī)в袆?chuàng)建請求的目標文件；(2)元數據服務器對文件進行預創(chuàng)建，建立文件池；(3)利用元數據服務器聚合管理文件元數據；(4)經內核模塊對文件排序后批量同步上載。2.如權利要求1所述的上載方法，其特征在于，所述步驟(I)中，所述客戶端為分布式文件系統(tǒng)的入口，根據文件系統(tǒng)的標準POSIX語義，合并文件的查找和創(chuàng)建動作；如果檢測到本次查找的意圖是創(chuàng)建，則在服務端完成創(chuàng)建動作，并由查找請求將對應文件元數據帶回。3.如權利要求1所述的上載方法，其特征在于，所述步驟(2)中，所述元數據服務器對文件進行預創(chuàng)建步驟如下:2-1為待創(chuàng)建文件分配唯一標識；2-2向數據服務器發(fā)起對象創(chuàng)建請求，并等待處理完成；2-3進行元數據創(chuàng)建操作；2-4返回客戶端。4.如權利要求3所述的上載方法，其特征在于，所述步驟2-3中，所述進行元數據創(chuàng)建操作，包括在元數據服務器上預先創(chuàng)建一定數目的文件，并放入備用文件池中；當客戶端有創(chuàng)建請求到來時，從文件池中分配一個文件，返回給客戶端即可；當空閑文件池中沒有可用文件時，元數據服務器直接向數據服務器發(fā)起對象創(chuàng)建請求，同時，喚醒后臺線程向文件池填充空閑文件。5.如權利要求1所述的上載方法，其特征在于，所述步驟(3)中，所述聚合管理是將文件的元數據存放在一個元數據文件中。6.如權利要求5所述的上載方法，其特征在于，如果一個元數據文件管理N個元數據，此時操作磁盤的次數將由原來的N次減小為I次。7.如權利要求1所述的上載方法，其特征在于，所述步驟(4)中，批量同步上載的方法包括下述步驟:步驟4-1.將多個小文件同時寫入操作系統(tǒng)的文件緩存，由系統(tǒng)后臺線程回寫，回寫時按批聚合，不進行單次操作的磁盤同步；步驟4-2.引入內核模塊，按照文件在磁盤上的數據塊排列順序，從小到大并發(fā)同步；步驟4-3.對由元數據發(fā)起的創(chuàng)建對象請求進行批量聚合處理，完成同步上載。【專利摘要】本發(fā)明涉及一種對于海量小文件在分布式存儲系統(tǒng)中上載的方法，該方法包括：客戶端根據操作系統(tǒng)的標準POSIX語義，查找?guī)в袆?chuàng)建請求的目標文件；元數據服務器對文件進行預創(chuàng)建，建立文件池；利用元數據服務器聚合管理文件元數據；經內核模塊對文件排序后批量同步上載。解決了小文件創(chuàng)建延遲大、數目少的問題，大大提高了上載速率，且減少了硬件資源浪費，節(jié)約了成本?！綢PC分類】G06F17/30【公開號】CN105630810【申請?zhí)枴緾N201410603326【發(fā)明人】楊浩,馬照云,王利虎,苗艷超,劉新春,邵宗有【申請人】曙光信息產業(yè)股份有限公司【公開日】2016年6月1日【申請日】2014年10月30日