[發明專利]一種小文件的定位方法及系統

有效

• 申請號: 201410850201.0
• 申請日: 2014-12-30
• 公開（公告）號: CN104965845A
• 公開（公告）日: 2015-10-07
• 發明（設計）人: 許焰;周明偉;江文龍
• 申請（專利權）人: 浙江大華技術股份有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 北京同達信恒知識產權代理有限公司 11291
• 代理人: 朱佳

技術領域

本發明涉及互聯網領域，特別涉及一種小文件的定位方法及系統。

背景技術

隨著互聯網、物聯網、云計算等高速發展，大量的互聯網企業涌入人們的生活，很多互聯網企業都會遇到海量小文件(Lost?of?Small?Files，LOSF)的問題，例如，文本、圖片以及音樂等，如此海量的小文件必然會要求更高的系統存取性能，以及會面臨小文件的備份與恢復困難等問題。另外，社會化網絡、移動通信、網絡視頻音頻、傳感器網絡等各種應用產生的數據量很大，往往能夠產生千萬級、億級甚至十億、百億級的海量小文件，而且大多海量小文件都是混合存儲，因此，在元數據管理、訪問性能、存儲效率等方面面臨著巨大的挑戰。

目前，小文件的存儲方法主要是采用多副本的方式進行備份并存儲，對于海量的小文件來說，主要特點就是數據量大，同時存在大量的元數據，因此，在此種情況下，小文件的存儲會占用大量的存儲空間。另外，為了提供標準的文件目錄結構，還需配備一個目錄服務器，目錄服務器多采用數據庫或者目錄樹進行管理。

下面以現有技術中兩種小文件系統為例，介紹現有技術中的小文件的存取方法。

第一種小文件系統主要通過將海量的小文件(如圖片、文本等)打包進大文件進行存儲，并通過多副本的方式來解決數據的可靠性，其中，用于存儲多個小文件的大文件可稱作一個Block，通常64MB大小，Block內部存儲的每個文件用一個File?id標識，下面將TFS中小文件存儲的過程分兩個步驟進行介紹。

小文件寫的過程：

客戶端向名稱服務器(稱為Name?Server)發送寫請求；

Name?Server根據Block的負載情況，向客戶端提供可用的Block、File?id以及該Block所屬的數據服務器(稱為Data?Server)；

客戶端向相應的Data?Server發送數據，Data?Server通過管道運輸(即pipeline)模式將數據復制到其他的Data?Server。

小文件讀的過程：

客戶端通過編碼將文件名轉換為Block?id和File?id，然后向名稱服務器(即Name?Server)索要數據服務器(即Data?Server)；

Data?Server收到請求后，通過接收到的Block?id和File?id定位到Block的具體位置，并讀取數據，將讀取的數據返回客戶端。

第二種小文件系統以Haystack為例，其針對存儲圖片的數量巨大的網站，Haystack的主要架構主要有三個部分：Haystack目錄(即Haystack?Directory)，Haystack存儲(即Haystack?Store)以及Haystack貯存區(即Haystack?Cache)。其中，Haystack?Store是物理存儲節點，以物理卷軸的形式組織存儲空間，每個物理卷軸一般很大(例如100GB)，每一個物理卷軸對應一個物理文件，因此，每個存儲節點上的物理文件的元數據信息都很小，多個物理存儲節點上的物理卷軸組成一個邏輯卷軸，用于備份，Haystack?Directory用于存放邏輯卷軸和物理卷軸的對應關系。

下面將Haystack中小文件存儲的流程分兩個步驟進行介紹。

小文件寫的過程(例如圖片上傳的過程)為：

網頁服務器(稱為Web?Server)首先請求Haystack?Directory獲取圖片的id和可寫的邏輯卷軸，接著將數據寫入對應的每一個物理卷軸，一般備份數為3；

小文件讀的過程(例如圖片下載或瀏覽的過程)為：

當用戶訪問一個頁面時，Web?Server請求Haystack?Directory構造一個URL：http://<CDN>/<Cache>/<Machine?id>/<Logical?Volume，Photo>，后續根據各個部分的信息一次訪問內容分發網絡(Content?Delivery?Network，CDN)，Cache和后端的Haystack?Store存儲節點。

Haystack?Directory的實現采用Replicated?Database做持久化存儲，前面增加一個Memcache集群滿足查詢需求。