对象存储

对象存储(英语:Object storage)是一种电脑数据存储架构,它将数据作为对象进行管理,与其他存储架构不同(如文件系统将数据作为文件层次结构进行管理,而块存储则将数据作为扇区和轨道内的块进行管理)。[1] 每个对象通常包括数据本身、数量不等的元数据和一个全局唯一的标识符。对象存储可以在多个层面实现,包括装置层面(对象存储装置)、系统层面和接口层面。在每一种情况下,对象存储都试图实现其他存储架构所不具备的能力,如可由应用程式直接编程的接口,可跨越多个物理硬件实例的命名空间,以及数据管理功能,如数据复制英语data replication和对象级粒度的数据分发。

对象存储系统允许保留大量的非结构化数据英语unstructured data。对象存储的用途包括:在Facebook上存储照片,在Spotify上存储歌曲,或在在线协作服务(如Dropbox)中存储文件。[2]

历史

起源

1995年,由Garth Gibson领导的关于网络附加安全磁碟的研究首次推广了将不太常见的操作(如命名空间操作)与常见的操作(如读和写)分开的概念,以优化两者的性能和规模。[3] 同年,比利时公司FilePool成立,为归档功能奠定了基础。1996年,对象存储作为一个研究项目在Gibson的卡内基·梅隆大学实验室提出。[4] 另一个关键概念是将数据的写入和读取抽象为更灵活的数据容器(对象)。NASD团队之一的Howard Gobioff进一步描述了通过对象存储架构[5]的细粒度访问控制,他后来是Google文件系统的发明人之一。[6] 其他相关工作包括卡内基·梅隆大学Coda文件系统项目,该项目始于1987年,并催生了Lustre文件系统[7] 还有1999年开始的加州大学伯克利分校的OceanStore项目[8][9]和1998年开始的田纳西大学诺克斯维尔分校的Logistical Networking项目。[10] 1999年,Gibson成立了Panasas英语Panasas公司,将NASD团队开发的概念商业化。

发展

希捷科技在对象存储的发展中发挥了核心作用。根据存储网络工业协会SNIA的说法,“对象存储起源于20世纪90年代末。希捷公司1999年的规范介绍了一些最早的命令和操作系统如何有效地从存储的消费中移除”。[11]

1999年10月25日的《基于对象的存储装置命令集提案》的初步版本是由希捷提交的,由希捷的Dave Anderson编辑,是国家存储产业联盟(NSIC)的工作成果,包括卡内基梅隆大学、希捷、IBM、昆腾和StorageTek的贡献。[12] 这篇论文是向INCITS T-10(国际资讯科技标准委员会英语International Committee for Information Technology Standards)提出的,目的是组建一个委员会并设计一个基于SCSI接口协议的规范。这个规范将对象定义为抽象的数据,具有唯一的标识符和元数据,还定义了对象如何与文件系统相关,以及其他许多创新概念。Anderson在1999年10月的SNIA会议上提出了许多这些想法。该演讲揭示了1997年2月原始合作者(由Anderson和Chris Malakapalli代表希捷)之间签署的知识产权协议,并涵盖了对象存储、可扩展计算、平台独立性和存储管理的好处。[13]

架构

 

存储的抽象化

对象存储的设计原则之一是将一些较低层次的存储从管理员和应用程式中抽象出来。因此,数据是作为对象而不是文件或块被暴露和管理的。对象包含额外的描述性属性,可用于更好地进行索引或管理。管理员不必执行较低层次的存储功能,如构建和管理逻辑卷以利用磁碟容量或设置RAID级别以处理磁碟故障。

对象存储还允许通过不仅仅是文件名和文件路径对单个对象进行寻址和识别。对象存储在一个桶内或整个系统中增加了一个唯一的标识符,以支持更大的命名空间并消除名称冲突。

将丰富的自定义元数据纳入对象中

对象存储明确地将文件元数据与数据分开,以支持额外的功能。相对于文件系统中的固定元数据(文件名、创建日期、类型等),对象存储提供了全功能的、自定义的、对象级的元数据,以便于:

  • 捕获特定应用或特定用户需要的资讯,以更好地进行索引
  • 支持数据管理策略(例如,驱动对象从一个存储层移动到另一个存储层的策略)。
  • 集中管理许多单独节点和集群的存储
  • 优化元数据存储(如封装、数据库或键值存储)和缓存/索引(当权威元数据与对象内部的元数据封装在一起时),独立于数据存储(如非结构化二进制存储)。

此外,在一些基于对象的文件系统实现中:

  • 文件系统客户端只在文件打开时与元数据伺服器联络一次,然后直接通过对象存储伺服器获得内容(而基于块的文件系统需要持续的元数据访问)。
  • 可以根据每个文件配置数据对象,以允许自适应条带宽度,甚至可以跨多个对象存储伺服器进行配置,从而支持对带宽和I/O进行优化

基于对象的存储装置OSD)以及一些软件实现(例如,DataCore Swarm)在存储装置层面管理元数据和数据:

  • 不是提供面向块的接口来读写固定大小的数据块,而是将数据组织成灵活大小的数据容器(称作“对象”)
  • 每个对象都有数据(未解释的字节序列)和元数据(描述对象的可扩展的属性集);将两者物理封装在一起有利于提升可恢复性。
  • 命令界面包括创建和删除对象、向单个对象写入字节和读取字节,以及设置和获取对象属性的命令
  • 安全机制提供每个对象和每个命令的访问控制

编程序的数据管理

对象存储提供了编程接口,使应用程式能够操作数据。在基础层面,这包括用于基础读、写和删除操作的增删改查(CRUD)功能。一些对象存储的实现更进一步,支持对象版本控制英语object versioning、对象复制、生命周期管理以及对象在不同层级和类型的存储之间的移动等附加功能。大多数API实现是基于REST的,允许使用许多标准的HTTP调用。

实现

云储存

市场上绝大多数的云储存都是利用对象存储的架构。一些值得注意的例子是2006年3月首次亮相的亚马逊网络服务S3Microsoft Azure Blob存储、Rackspace Files(其代码在2010年捐赠给Openstack项目并作为OpenStack Swift发布)以及2010年5月发布的谷歌云储存英语Google Cloud Storage

基于对象的文件系统

一些分布式文件系统使用基于对象的架构,其中文件元数据存储在元数据伺服器中,文件数据存储在对象存储伺服器中。文件系统客户端软件与不同的伺服器进行交互,并将其抽象化,以向用户和应用程式展示一个完整的文件系统。

对象存储系统

一些早期的对象存储被用于归档,因为实现是针对数据服务(如不变性)而不是性能进行优化。EMC Centera和日立HCP(以前被称为HCAP)是两个常见的用于归档的对象存储产品。另一个例子是Quantum Lattus对象存储平台。

更多的通用对象存储系统在2008年左右进入市场。在雅虎邮箱等网络应用的“私藏”存储系统的惊人增长和云储存的早期成功的诱惑下,对象存储系统承诺具有云储存的规模和能力,并能够在企业内或有志于云储存的服务提供商处部署系统。

混合存储

少数对象存储系统支持统一文件和对象(UFO)存储,允许一些客户在一个存储系统上存储对象,同时其他客户在同一存储系统上存储文件。虽然由于与混合旋转磁碟和闪存的混淆,“混合存储”并不是这个概念的一个广泛接受的术语,[14] 但在一些对象存储产品中,对相同的数据集有可操作的接口。

“私藏”对象存储

一些大型互联网公司在对象存储产品没有商业化或使用案例非常特殊的情况下开发了自己的软件。著名的Facebook开发了他们自己的对象存储软件,代号为Haystack,以有效解决他们特殊的大规模照片管理需求。

基于对象的存储装置

协议和装置层的对象存储是在20年前提出的,并在近10年前作为“基于对象的存储装置命令”(OSD)被批准用于SCSI命令集,[15] 然而,直到希捷Kinetic开放存储平台的开发,它还没有投入生产。[16][17] 对象存储装置的SCSI命令集是由SNIA的一个工作小组为国际资讯科技标准委员会(INCITS)的T10委员会开发的。[18] T10负责所有SCSI标准。

市场采用

最早的对象存储产品之一,Lustre,被用于70%的前100名超级计算机和约50%的前500名超级计算机[19] 截至2013年6月16日,这包括前10名中的7名,包括目前榜单上第四快的系统——中国的天河二号,和第七快的橡树岭国家实验室泰坦超级计算机[20]

对象存储系统在21世纪初作为存档平台有很好的应用,特别是在萨班斯-奥克斯利法案等合规法律出台后。在进入市场五年后,EMC的Centera产品声称到2007年有超过3500个客户和150PB的出货量。[21] 日立的HCP产品也声称有许多PB级的客户。[22] 较新的对象存储系统也得到了一些吸引力,特别是围绕非常大的定制应用,如eBay的拍卖网站,EMC Atmos被用来每天管理超过5亿个对象。[23] 截至2014年3月3日,EMC声称已经售出超过1.5兆字节的Atmos存储。[24] 2014年7月1日,洛斯阿拉莫斯国家实验室选择Scality RING英语Scality作为500PB存储环境的基础,这将是有史以来最大的存储环境之一。[25]

像Facebook的Haystack这样的“私藏”对象存储系统的规模也令人印象深刻。2009年4月,Haystack管理着600亿张照片和1.5PB的存储,每周增加2.2亿张照片和25TB。Facebook最近表示,他们每天增加3.5亿张照片,存储2400亿张照片。[26] 这可能相当于357PB之多。[27]

随着许多新的网络和流动应用程序选择云作为存储二进制数据的常用方式,云储存已经变得无处不在。[28] 作为许多流行的应用程式如SmugmugDropbox的存储后端,AWS S3已经发展到大规模,在2013年4月引用了超过2万亿的存储对象。[29] 两个月后,微软声称他们在Azure中存储的对象甚至更多,达到8.5万亿。[30] 到2014年4月,Azure声称存储了超过20万亿个对象。[31] Windows Azure存储管理着Blobs(用户文件)、表(结构化存储)和队列(消息传递),并把它们都算作对象。[32]

市场分析

IDC已经开始使用其MarketScape方法每年评估基于对象的存储市场。IDC将MarketScape描述为。"...对评估供应商在上述市场或细分市场的当前和未来成功的特征进行定量和定性评估,并提供一个衡量其成为领导者或保持领导地位的标准。IDC的MarketScape评估对新兴市场特别有帮助,这些市场往往是分散的,有几个参与者,缺乏明确的领导者。"[33]

在2019年,IDC将戴尔EMC、日立数据系统、IBMNetAppScality英语Scality评为领导者。

标准

基于对象的存储装置标准

OSD版本1

在OSD标准的第一个版本中,[34] 对象是用一个64位的分区ID和一个64位的对象ID指定的。分区在OSD中被创建和删除,而对象在分区中被创建和删除。分区或对象没有固定的大小,它们被允许在装置的物理大小限制或分区的逻辑配额限制下增长。

一套可扩展的属性描述对象。有些属性是由OSD直接实现的,如一个对象的字节数和一个对象的修改时间。有一个特殊的策略标签属性,是安全机制的一部分。其他的属性则不被OSD所解释。这些是由使用OSD进行持久化存储的上级存储系统在对象上设置的。例如,属性可能被用来对对象进行分类,或者用来捕捉存储在不同OSD上的不同对象之间的关系。

列表命令返回一个分区中的对象的标识符列表,可以选择通过与属性值的匹配进行过滤。列表命令还可以返回列表对象的选定属性。

读和写的命令可以与获取和设置属性的命令结合起来,或者说是捎带上的。这种能力减少了高层存储系统穿越接口到OSD的次数,这可以提高整体效率。

OSD版本2

第二代SCSI命令集“基于对象的存储装置-2”(OSD-2)增加了对快照、对象集合的支持,并改进了错误处理。[35]

快照是将一个分区中的所有对象复制到一个新的分区中的时间点。OSD可以使用写时拷贝技术实现空间效率高的拷贝,这样两个分区就可以共享快照之间没有变化的对象,或者OSD可以将数据物理地拷贝到新的分区中。该标准定义了克隆和快照,前者是可写的,后者是只读的。

集合是一种特殊的对象,包含其他对象的标识符。有一些操作可以从集合中添加和删除,还有一些操作可以获取或设置集合中所有对象的属性。集合也被用于错误报告。如果一个对象因为介质缺陷(即磁碟上的一个坏点)或OSD实现中的软件错误而损坏,它的标识符会被放入一个特殊的错误集合中。使用OSD的上级存储系统可以查询这个集合并在必要时采取纠正措施。

键值存储和对象存储之间的差异

不幸的是,对象存储和键-值存储之间的边界是模糊的,键值存储有时被宽泛地称为对象存储。[36]

传统的块存储接口使用一系列固定大小的块,这些块从0开始编号。数据必须是准确的固定大小,并且可以存储在一个特定的块中,该块由其逻辑块编号(LBN)识别。之后,人们可以通过指定其唯一的LBN来检索该数据块。

在键值存储中,数据是由一个键而不是LBN来识别的。一个键可能是“cat” 或“olive”或“42”。它可以是一个任意长度的任意字节序列。数据(在这里称为值)不需要有固定的大小,也可以是任意长度的任意字节序列。人们通过向数据存储提交密钥和数据(值)来存储数据,随后可以通过提交密钥来检索数据。这个概念在编程语言中可以看到。Python称其为字典,Perl称其为散列,Java和C++称其为map(映射),等等。一些数据存储也实现了键值存储,如Memcached、Redis和CouchDB。

对象存储在两个方面与键值存储相似。首先,对象的标识符或URL(相当于键)可以是一个任意的字符串。[37] 第二,数据可以是任意大小的。

然而,键值存储和对象存储之间有几个关键的区别。首先,对象存储还允许人们将一组有限的属性(元数据)与每一个数据联络起来。一个键、值和一组属性的组合被称为一个对象。其次,对象存储为大量的数据(几百兆字节甚至几千兆字节)进行了优化,而对于键值存储来说,价值预计相对较小(千兆字节)。最后,对象存储通常提供较弱的一致性保证,如最终一致性,而键值存储提供强一致性英语strong consistency

参见

参考文献

  1. ^ Porter De Leon, Yadin; Tony Piscopo. Object Storage versus Block Storage: Understanding the Technology Differences. Druva.com. 14 August 2014 [19 January 2015]. (原始内容存档于2022-01-23). 
  2. ^ Chandrasekaran, Arun, Dayley, Alan. Critical Capabilities for Object Storage. Gartner Research. 11 February 2014 [2021-11-19]. (原始内容存档于2016-01-14). 
  3. ^ Garth A. Gibson; Nagle D.; Amiri K.; Chan F.; Feinberg E.; Gobioff H.; Lee C.; Ozceri B.; Riedel E.; Rochberg D.; Zelenka J. File Server Scaling with Network-Attached Secure Disks (PDF). Proceedings of the ACM International Conference on Measurement and Modeling of Computer Systems (Sigmetrics ‘97). [27 October 2013]. (原始内容存档 (PDF)于2022-01-20). 
  4. ^ Factor, Michael; Meth, K.; Naor, D.; Rodeh, O.; Satran, J. Object Storage: The Future Building Block for Storage Systems. IBM Haifa Research Labs: 119–123. 2005. CiteSeerX 10.1.1.122.3959 . 
  5. ^ Gobioff, Howard; Gibson, Garth A.; Tygar, Doug. Security for Network Attached Storage Devices (CMU-CS-97-185). Parallel Data Laboratory. 1 October 1997 [7 November 2013]. (原始内容存档于2016-03-04). 
  6. ^ Sanjay Ghemawat; Howard Gobioff; Shun-Tak Leung. The Google File System (PDF). October 2003 [7 November 2013]. (原始内容存档 (PDF)于2009-12-14). 
  7. ^ Braam, Peter. Lustre: The intergalactic file system (PDF). [17 September 2013]. (原始内容存档 (PDF)于2017-12-01). 
  8. ^ OceanStore. [18 September 2013]. (原始内容存档于8 August 2012). 
  9. ^ Kubiatowicz, John; Wells, Chris; Zhao, Ben; Bindel, David; Chen, Yan; Czerwinski, Steven; Eaton, Patrick; Geels, Dennis; Gummadi, Ramakrishna; Rhea, Sean; Weatherspoon, Hakim. OceanStore: an architecture for global-scale persistent storage. Proceedings of the Ninth International Conference on Architectural Support for Programming Languages and Operating Systems - ASPLOS-IX. 2000: 190–201. doi:10.1145/378993.379239. 
  10. ^ Plank, James; Beck, Micah; Elwasif, Wael; Moore, Terry; Swany, Martin; Wolski, Rich. The Internet Backplane Protocol: Storage in the Network (PDF). Netstore 1999. October 1999 [27 January 2021]. (原始内容存档 (PDF)于2022-06-21). 
  11. ^ Object Storage: What, How and Why?, NSF (Networking Storage Forum), SNIA (Storage Networking Industry Association), Live Webcast页面存档备份,存于互联网档案馆) February 19, 2020
  12. ^ Anderson, D. Object based storage devices: a command set proposal (PDF). 1999 [2021-11-19]. S2CID 59781155. (原始内容存档 (PDF)于2022-01-21). 
  13. ^ Object Based Storage: A Vision, slide presentation, Dave Anderson and Seagate Technology, October 13, 1999 https://www.t10.org/ftp/t10/document.99/99-341r0.pdf页面存档备份,存于互联网档案馆
  14. ^ Crump, George. What Is Hybrid Storage?. [2020-02-16]. (原始内容存档于2019-09-05). 
  15. ^ Riedel, Erik; Sami Iren. Object Storage and Applications (PDF). February 2007 [3 November 2013]. (原始内容存档 (PDF)于2022-08-11). 
  16. ^ The Seagate Kinetic Open Storage Vision. Seagate. [3 November 2013]. (原始内容存档于2019-06-16). 
  17. ^ Gallagher, Sean. Seagate introduces a new drive interface: Ethernet. Arstechnica.com. 27 October 2013 [3 November 2013]. (原始内容存档于2022-06-21). 
  18. ^ Corbet, Jonathan. Linux and object storage devices. LWN.net. 4 November 2008 [8 November 2013]. (原始内容存档于2022-03-20). 
  19. ^ Dilger, Andreas. Lustre Future Development (PDF). IEEE MSST. [27 October 2013]. (原始内容 (PDF)存档于29 October 2013). 
  20. ^ Datadirect Networks to build world's fastest storage system for Titan, the world's most powerful supercomputer. [27 October 2013]. (原始内容存档于29 October 2013). 
  21. ^ EMC Marks Five Years of EMC Centera Innovation and Market Leadership. EMC. 18 April 2007 [3 November 2013]. (原始内容存档于2014-01-23). 
  22. ^ Hitachi Content Platform Supports Multiple Petabytes, Billions of Objects. Techvalidate.com. [19 September 2013]. (原始内容存档于24 September 2015). 
  23. ^ Robb, Drew. EMC World Continues Focus on Big Data, Cloud and Flash. Infostor. 11 May 2011 [19 September 2013]. (原始内容存档于2021-12-07). 
  24. ^ Hamilton, George. In it for the Long Run: EMC's Object Storage Leadership. [15 March 2014]. (原始内容存档于15 March 2014). 
  25. ^ Mellor, Chris. Los Alamos National Laboratory likes it, puts Scality's RING on it. The Register. 1 July 2014 [26 January 2015]. (原始内容存档于2020-01-07). 
  26. ^ Miller, Rich. Facebook Builds Exabyte Data Centers for Cold Storage. Datacenterknowledge.com. 13 January 2013 [6 November 2013]. (原始内容存档于2014-05-22). 
  27. ^ Leung, Leo. How much data does x store?. Techexpectations.org. 17 May 2014 [23 May 2014]. (原始内容存档于22 May 2014). 
  28. ^ Leung, Leo. Object storage already dominates our days (we just didn't notice). January 11, 2012 [27 October 2013]. (原始内容存档于29 September 2013). 
  29. ^ Harris, Derrick. Amazon S3 goes exponential, now stores 2 trillion objects. Gigaom. 18 April 2013 [17 September 2013]. (原始内容存档于2022-01-19). 
  30. ^ Wilhelm, Alex. Microsoft: Azure powers 299M Skype users, 50M Office Web Apps users, stores 8.5T objects. thenextweb.com. 27 June 2013 [18 September 2013]. (原始内容存档于2021-02-26). 
  31. ^ Nelson, Fritz. Microsoft Azure's 44 New Enhancements, 20 Trillion Objects. Tom's IT Pro. 4 April 2014 [3 September 2014]. (原始内容存档于6 May 2014). 
  32. ^ Calder, Brad. Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency (PDF). 23rd ACM Symposium on Operating Systems Principles (SOSP): Microsoft. [6 November 2013]. (原始内容存档 (PDF)于2017-10-13). 
  33. ^ Potnis, Amita. IDC MarketScape: Worldwide Object-Based Storage 2019 Vendor Assessment. idc.com. IDC. [16 Feb 2020]. (原始内容存档于2021-11-19). 
  34. ^ INCITS 400-2004. InterNational Committee for Information Technology Standards. [8 November 2013]. 
  35. ^ INCITS 458-2011. InterNational Committee for Information Technology Standards. 15 March 2011 [8 November 2013]. (原始内容存档于2016-03-09). 
  36. ^ 存档副本. [2021-11-19]. (原始内容存档于2015-02-21). 
  37. ^ OpenStack Foundation. Object Storage API overview. OpenStack Documentation. [9 June 2017]. (原始内容存档于2017-07-03).