基于對象存儲系統中屬性管理的研究與實現

摘要：針對現有屬性管理方法上的缺陷和不足，提出了一種新的屬性管理方法——哈希桶。哈希桶方法對對象的屬性進行集中管理，不僅降低了管理存儲成本，更有效地提高了系統的吞吐率。經過仿真測試表明，哈希桶對象屬性管理方法性能遠優于現有的屬性管理方法。

關鍵詞:基于對象存儲系統；對象屬性；哈希桶

中圖分類號：TP311文獻標志碼：A

文章編號：1001-3695(2007)11-0188-03

0引言

隨著計算機技術的快速普及，人們對數據的需求呈指數級增長，存儲系統已經成為制約計算機進一步發展的瓶頸。傳統的存儲系統，如NAS和SAN都難以提供完美的存儲解決方案：NAS基于文件，文件級別的接口提供了安全性和跨平臺的互操作性；SAN基于塊，塊級別接口在快速訪問、高性能方面有優勢。此時，基于對象的存儲系統[1]在眾多存儲方案中脫穎而出，它在性能、可擴展、數據共享以及容錯、容災等方面有杰出表現，為人們提供一個完美的解決方案。對象存儲系統的概念已經被工業界廣泛認可，并由多家公司聯合，由美國國家標準組織（ANSI）下屬的T10工作組制定標準——OSD命令集（object－based storage device commands）[2]；IBM、Panasas等公司已經推出了相關產品。目前影響較大的對象存儲系統有集群文件系統公司開發的Lustre文件系統[3]和Panasas公司開發的Panasas ActiveScale storage cluster[4]等。

基于對象存儲系統之所以取得這么大的成功，最根本的原因在于它推出了一個全新的存儲接口，即對象（object）。

對象是一些具有邏輯關系的數據的載體，它與塊的固定大小不一樣。對象是可變長的，可包含任何類型的數據，如文件、數據庫記錄、圖像以及多媒體視頻、音頻等。至于包含何種類型數據由應用決定，對象可動態地擴大和縮小。對象分為用戶對象、分區對象、集合對象和根對象四種。其中：用戶對象是對象存儲設備中數量最多的，它存放各種對象數據及其屬性數據；把用戶對象進行分區管理，構成分區對象；集合對象是一些具有相同或相近特性的用戶對象或者分區對象的集合；根對象及其屬性用于描述對象存儲設備的一些特征，一個對象存儲設備只有一個根對象。對象由一個128 bit的標志符惟一表示。該128 bit的標志符為64 bit的partition_ID和64 bit的user_Object_ID的組合。

本文根據當前存儲系統應用的一些特點，結合對象存儲設備自身的優點，提出了一種對象屬性管理的新方法——哈希桶。通過哈希桶對對象屬性進行集中式的管理，大幅度地提高了系統的性能。

1對象存儲系統和對象存儲設備

對象存儲系統的體系結構如圖1所示。高速網絡將用戶、元數據服務器（metadata server，MDS）和對象存儲設備（OSD）[5]連接起來。OBSS實現一個基于對象的分布式網絡文件系統。MDS提供全局名字空間，管理文件到對象的映射，提供身份驗證等安全機制。OSD則向外提供對象接口，以對象作為存取單元。用戶訪問文件時先向元數據服務器發送請求，獲取文件的信息（如文件由哪些對象組成以及對象所在的設備等）及訪問證書，然后客戶與OSD直接交互。OSD收到客戶請求后，對其身份進行認證，然后執行客戶的對象讀寫請求。在這里客戶向OSD發送的I/O請求與基于塊的I/O請求不同，僅包括對象ID、對象的偏移地址以及長度。

OSD是一個智能化的設備，包括CPU、memory、網絡接口以及塊設備接口，管理對象存儲空間的分配、數據組織以及對象的屬性。對象存儲系統的最大好處之一就是將底層的數據組織和同步操作交由OSD管理，這就大大減輕了用戶端和元數據服務器的負擔，同時也提高了整個系統的并行性和可擴展性。

2對象屬性

對象屬性是對象特點的描述或歷史行為的記錄，充分利用對象的屬性特征能有效地提高基于對象存儲系統的整體性能。

對象可以表示任何類型的應用數據。對于不同的應用，數據的屬性是不同的。如果為所有的對象定義一種統一的屬性表示方式，這種表示方式會占用大量的存儲空間。為簡化和擴展對象屬性的表示，本文采用一種屬性頁（attribute page）的表示方法，每個屬性頁上記錄相關或相近的屬性。每個屬性頁用屬性頁號（attri_Page_ID）來表示；屬性頁中具體的一個屬性用屬性索引號（attri_Index_ID）來索引。因此，對象的一個屬性以（partition_ID， user_ID， attri_Page_ID， attri_Index_ID）惟一表示。

對于每個對象都具有的公共屬性則定義為公共屬性頁（其ID號為0），如每個對象都具有創建時間、最近一次修改時間、對象大小等屬性。每個對象至少有一張屬性卡片，那就是公共屬性卡片，由系統定義、系統方法和用戶自定義方法均可解釋存取。

對于與應用有關的屬性，則可定義為用戶屬性頁，如多媒體對象與數據庫表格對象具有完全不同的特點：多媒體對象有QoS[6]、幀速率、視頻圖像大小等屬性，可定義為多媒體屬性卡片；數據庫表格對象的屬性可能有記錄的條數、每條記錄的格式等內容，可定義為數據庫表格屬性卡片。不同的對象使用了不同的自定義的屬性卡片。

屬性頁的使用為表示新對象類型的相應特征提供了方便，只要根據新對象的特點定義針對該對象特點的屬性卡片，就可對屬性進行擴展，從而表示新對象的特征。如為每個對象定義一個預取屬性頁，對用戶訪問對象存儲設備的規律進行智能的自我學習，提高了對象存儲設備的預取命中率，從而提高對象存儲設備的性能。

屬性管理可分為分布式和集中式管理兩種。分布式的屬性管理將每個對象的所有屬性存放到一個前綴名與對象相同的文件中，如對象ID為123，對象的屬性文件命名為123.attri。這樣一個對象就對應數據文件和屬性文件兩個文件。筆者采用文件方法實現了分布式屬性管理。文件方法雖然簡單易行，但是其存儲管理開銷大，在實際實現時性能不是很理想。集中式屬性管理，即將所有對象的屬性集中存放管理，采用哈希桶方法予以實現。最終實驗數據表明該方法不僅降低了管理成本，而且提高了整個系統的吞吐率。

3對象屬性的存放策略

3．1哈希桶

屬性是對象存儲系統中最大的特色，用戶在實際應用中需要進行大量的查找、增添、刪除屬性的操作。如何提高屬性的存取速度和效率，對于提高整個對象存儲系統的性能有著重要的意義。因此，本文提出了哈希桶的方法來集中管理屬性的存放。

哈希桶的整體設計思想是：屬性用〈key， value〉的記錄方式表示，并以桶(bucket)為單位進行存放。用戶只需知道相應屬性的key，根據哈希映射關系便可迅速找到屬性的value，而不需要按照傳統的文件方法，先根據屬性文件名查找對應的屬性文件，再在該屬性文件中查找對應的具體屬性。

屬性的key用〈partition_ID， user_ID， attri_Page_ID， attri_Index_ID〉表示。由于partition_ID、user_ID惟一表示了一個對象，這樣的組合就惟一確定了每一個對象的每一條具體屬性。Key對應的value中存放相應的屬性數據。桶用來記錄查找屬性的相關信息（用struct bucket_element表示，包括屬性的哈希值（hash_value）、該屬性記錄在磁盤中的位置（data_poin￣ter）、屬性的key長度（key_size）、屬性的value長度（data_size）等）。桶的大小可以由用戶自己設定，默認為1 024 Byte；桶中可裝載的bucket_element的個數用max_count表示。當桶中的記錄裝滿時，即count=max_count，該桶就裂變成兩個桶。為了迅速地定位到所需要的桶，還引進了目錄表（dir_table），記錄了所有桶對應的在磁盤上的存放地址信息。

3．2屬性查找

下面來看一下屬性查找的過程（圖2），具體用obs_findkey(uint64_t partition_ID，uint64_t user_ID， uint32_t attri_Page_ID，uint32_t attri_Index_ID，…)函數來實現。

a)根據屬性key中的〈partition_ID， user_ID〉，通過哈希計算得到相應31位的hash_value。

b)取hash_value的高N位作為目錄表(dir_table)的索引， dir[N]中的值指向存放該屬性信息的桶。根據該值從磁盤讀入相應的桶。

c)Hash_vale % max_count，得到的值作為所查找屬性在桶中的索引（index）位置。 

d)在桶中第index個bucket_element中記錄了屬性的相關信息，從中得到 date_pointer中記錄了該屬性在磁盤上的具體存放地址。

e)根據date_pointer值從磁盤中讀入該屬性記錄，比較該屬性的key值與要查找屬性的key值。如果相同，該屬性就是所查找的屬性，查找成功；反之，index值加1，跳轉步驟d)。

3．3屬性刪除

在哈希算法中，哈希沖突是不可避免的。同樣，在哈希桶的方法中，由于采用了哈希算法，哈希值相同的屬性由于哈希沖突必然會相鄰地存放在同一個桶里。在之前的屬性查找過程中，提到根據屬性的〈partition_ID， user_ID〉來計算hash值，而沒有用精確度更好、哈希沖突較少的整個key值〈partition_ID， user_ID， attri_Page_ID， attri_Index_ID〉來計算哈希值，正是利用哈希沖突的特性很好地解決了屬性刪除這個難點。在刪除一個對象時，不僅要刪除對象的數據，還要刪除對象所有的屬性。如果按整個key計算哈希值的話，由于哈希值的不定性，該對象的屬性將會分布到多個桶中，這樣在刪除屬性時，就需要讀入多個與之相關的桶。在最壞的情況下，需要遍歷所有的桶，大大降低了速度。而且，用戶還需要了解對象的所有屬性key值，造成使用上的諸多不便，在某些場合還會直接導致操作失敗。根據〈partition_ID， user_ID〉計算hash值，同一個對象的所有屬性，由于其〈partition_ID， user_ID〉相同，所得的hash值也必定相同；而根據解決哈希沖突的處理方法，hash值相同的屬性順次相鄰存放，因此該對象所有的屬性必定存放到同一個桶中。在刪除對象屬性時，只需要從磁盤上讀入該桶，查找桶中所有〈partition_ID， user_ID〉相同的屬性，便可完全刪除該對象的所有屬性，從而實現對象快速、高效的刪除。



4性能評估

為了測試兩種屬性管理方法的優劣，筆者編寫程序生成一個綜合負載[7]。該負載中對象屬性大小分布在1 KB~8 MB，且服從正態分布，屬性的請求隨機到達。在本測試的trace中，讀屬性操作占60%，寫屬性與刪除屬性操作占40%。實驗平臺采用Intel P4 3 GHz處理器，512 MB內存，ATA 120 GB 2 MB緩存的磁盤。在單個OSD設備上進行仿真測試。 

實驗結果如圖3所示。在屬性管理的性能比較上，總體而言，哈希桶方法遠遠優于文件方法管理。文件方法管理由于涉及到眾多file、dentry、inode等內核數據結構之間的復雜關系[8]，在大量的文件讀、寫、刪除操作以后，性能下降很快。特別是在文件的讀寫屬性操作時，更是因為要加互斥操作以及維護數據的一致性，使得其操作時間要高于哈希桶方法中的處理時間。在哈希桶的管理方法中，由于涉及的數據結構較少，系統的吞吐率雖然隨著訪問次數的增長不可避免地有所下降，但是仍大幅度地優于同等條件下的文件管理方法。

（a） 系統總吞吐率（b） 讀請求吞吐率

（c） 寫請求吞吐率（d） 刪除請求吞吐率

5結束語

本文研究了對象存儲系統中的屬性管理方法哈希桶，通過集中管理對象屬性降低了存儲管理成本，提高了管理效率。在同等條件下仿真測試得出結論，哈希桶屬性管理方法的性能遠遠優于現有的文件屬性管理方法。

參考文獻:

[1]MESNIER M， GANGER G R， RIEDEL E. Object－based storage[J].IEEE Communications Magazine，2003，41(8):84-90.

[2]LOHMEYER J B， PENOKIE G O， ALOISI P D， et al. Information technology SCSI object－based storage device commands (OSD)，Technical Council Proposal Douament T10/1355－D[R].[S.l.]:ANSI， 2004.

[3]BRAAM P J. The Lustre storage architecture[EB/OL]. http://www.lustre.org/docs/lustre.pdf.

[4]Panasas. Object storage architecture: defining a new generation of storage systems built on distributed， intelligent storage devices[R].[S.l.]:Storage Networking Solutions Europe， 2004.

[5]FENG Dan，QIN Ling－jun，ZENG Ling－fang， et al. A scalable object－based intelligent storage device[C]//Proc of the 3rd International Conference on Machine Learning and Cybernetics. Shanghai:[s.n.]，2004:387-391.

[6]LU Ying－ping， DU D H C， RUWART T.QoS provisioning framework for an OSD－based storage system[C]//Proc of the 22nd IEEE/13th NASA Goddard Conference on Mass Storage Systems and Technologies.2005:28-35.

[7]WANG Feng，XIN Qin，HONG Bo，et al.File system workload analysis for large scientific computing applications[C]//Proc of the 21st IEEE/12th NASA Goddard Conference on Mass Storage Systems and Technologies.2004:129－152.

[8]BOVET D P， CESATI M. Understanding the Linux kernel[M]. 2nd ed.[S.l.]: O’Reilly，2002:400-465.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”