对象存储是一个相对较新并且在持续稳步增长的市场部分。对于新手而言，对象存储用于保存大量非结构化数据，其中每个“对象”实际上是一个没有特定格式的文件(也称二进制文件)。实际上，从小的对象(人类可读取文件)到媒体(音频和视频)或其它行业特定格式(石油&天然气，医学成像等)，对象存储可以保存任何类型的数据。

与传统存储相比，采用对象存储的好处良多。基于块的系统(例如光纤通道和iSCSI)无法很好地向外扩展，并且没有真正的了解所存储的数据。它们是以低延迟和高粒度提供内容的“哑”块设备。文件系统将一些结构放在数据上，将文件对象放入层级结构(文件夹/目录)然后将元数据附加到这些对象上。然而，元数据通常只是基于存储文件所需的信息(创建时间，时间更新，访问规则)存储文件。

对象存储更进一步消除了文件夹层次结构,具有高度可搜索的可扩展元数据。在规模方面，对象存储可以增加到多(即便不是上百)PB容量，通常对数据没有地域限制。因为对象存储平台提供了优于传统存储的形式，越来越多的企业开始采用它。基于块的存储阵列无法很好地扩展，且带有大量HDD和SSD的数据保护(例如RAID)的问题。基于文件的系统受到系统自身的可扩展性限制，无论是在对象计数、并发、并行访问或恢复时间方面，都能检验出文件系统结构的一致性。对象存储代表一种更简单、更可扩展的解决方案，通过标准的基于网络的协议可轻松访问。

对于寻求采用对象存储的IT企业来说，最大的挑战是如何选用平台以及如何评估供应商的产品。对象存储使用基于Web的协议，因此需要一定程度的编码才能使用。这方面正在发生改变，我们将在后面讨论。

从特性的角度来看，对象存储在诸多方面能使某个平台在适用性方面更加突出。接下来，我们对IT组织在对象存储平台中的寻找目标来做一下识别分类和描述。

1.可扩展性——大和小

正如我们已讨论的那样，对象存储的设计比诸如横向扩展型NAS那样的传统数据存储的可扩展性范围要更进一步。供应商产品具有多PB级容量，可以存储数十亿个对象。然而，实现高可扩展性不仅仅是简单地测量对象和数据量。注意事项包括：

a.对象大小。对象存储处理大/小对象方面的表现如何?处理小对象的方式是什么?

b.容量限制。容量是否真的有限制?容量增长是否需要添加更多的硬件或软件节点?可以简单地扩展存储吗?

c.分层和缓存。对象存储该如何管理数据分层?随着容量的增加，大量数据通常是不活跃的，并且存档到更廉价的介质上。在这一点上，分层能力成为关键。闪存介质还可用作缓存或分层时以提高性能。

d.元数据管理。随着对象存储的发展，元数据该如何管理?对象存储的容量大小是否影响搜索性能?

e.对象访问。随着对象存储的发展，针对对象的单独访问时间是否要增加(还是不希望增加)?

最后一点对于构建对象存储特别重要，为多个对象存储/检索请求的提供并行访问，例如CDN网络的后端系统服务。在一个对象存储中增加存储数量是不应增加检索时间的，更重要的是“到第一个字节的时间”，这是从接收点开始将对象回流到请求者所花费的时间要求。

当然，我们不应该忘记对象存储可能需要启动小的对象，不需要有几百TB或PB级初始容量。小的初级容量有助于降低进入并采用对象存储的障碍，随之而来的需求是，以最小的影响从小到大进行容量扩展。

2.数据保护

数据保护的概念涵盖了对象存储中的许多方面。与传统的主存储相比，对象存储可能用于长期保存数据，因此数据耐久性是一个重要因素。我们可以将耐久性视为需要确保由于一系列错误(包括硬件读取失败和数据损坏)而不损坏正在存储中的数据。

与25年前的设备相比，现代硬盘非常可靠。尽管如此，仍然会出现读取错误和其他瞬态问题。对象存储应执行一系列磁盘管理的功能，包括数据清理、CRC的损坏检验，以及对不一致数据的重建。这些后台任务代表了长期保持数据健康的重要性。

第二个要考虑的是对硬件故障的保护。当今，大多数的存储阵列将RAID(独立磁盘冗余阵列)作为一种从硬件故障导致的丢失中恢复数据的方法。随着数据量的上升，RAID在可扩展性方面出现问题。存储供应商已经实现了双重甚至三重奇偶校验，以防止载有大硬盘容量的多个驱动器发生故障。然而，延长驱动器重建时间对RAID对象存储中的大量数据而言是不切实际的。

替代方案是用纠删码的方式来保护数据。纠删码是对数据划分和变换为多个冗余片段的描述过程，恢复原始信息所需的最小计数。例如，编码方案可以将数据翻译成12条数据，重建原始数据所需的其中的任何8条数据。这12条数据可以分布在多个驱动器上，服务器/节点甚至在地理上提供高弹性。在12/8方案中，跨越三个位置分布数据意味着任何一个位置的丢失都是允许的。

对象存储应根据客户需要提供具有可变保护值的纠删码。由于纠删码有处理开销，因此RAID还可以用于保护较小的对象并改善访问性能。当数据在地理上分布时，重建对网络的影响变得尤其重要。因此，纠删码系统的具体实现(以及需要通过WAN检索数据)将直接影响恢复时间和客户SLA(服务水平协议)。当本地LAN延迟较高时，也会发生此问题——任何基于分布式网络的恢复都将一直受到网络性能的影响。快速恢复非常重要，因为不受保护的数据需要快速重新保护，以避免潜在的数据丢失。

3.搜索、索引和元数据

在对象存储中搜索和检索数据的能力是最关键的要求之一。与结构化数据(如数据库和文件系统)相比，对象存储将数据保存在平面层次结构中，只有少量的逻辑或物理分隔(例如存储段或池)。这意味着存储的每个对象都需要有大量的信息，以便于数据检索。

对象存储通常使用的两种方法的其中之一——终端用户设置对象的名称(可能看起来像标准文件名)，或者使用系统生成的对象ID(OID)存储和访问对象。对象ID通常是由象存储本身随机生成的长字符串和数字。

在使用OID的情况下，元数据很关键。对象存储用户还可以维护对象ID及其使用的单独数据库。元数据提供关于对象本身(系统元数据)的信息，例如对象大小、访问权限、创建对象的用户等。用户元数据的扩展是与对象存储信息相对应的，用于传递搜索和有索引能力的应用程序。

元数据的搜索性能应该与存储在对象存储自身的数据量相互独立，这是管理可扩展性的关键要求。

4.性能

目前，在我们讨论的需求中，性能是实现可扩展性，数据保护和搜索的一个主题。但在对象存储第一次开发时，性能理念却并非主要因素，因为很多对象存储只是用作长期存档或是备份数据库。随着越来越多的对象平台适用于更加活跃的数据——用作主动存档，或媒体及其他流式内容的资源库。

因此，我们需要对象存储平台提供高吞吐量，线性可扩展功能以及处理高级并发请求。在将对象平台用作CDN(内容交付网络)或其他软件即服务(SaaS)解决方案的后备存储时，对并发性的需求尤其重要。并发就意味着能够同时传输多个对象，每秒处理大量的单个数据请求。在衡量标准方面，通常基于IOPS和吞吐量。

5.安全性

和任何数据存储一样，安全是一个关键特性。在对象存储中，安全特性则涵盖了许多方面。

因为数据可能保存到对象存储区域，多租户变得非常重要。业务用户(企业中的独立部门或独立企业)都希望自己的数据与其他人访问的数据隔离开。这表示拥有了独立的安全凭证，并为每位客户提供了加密密钥。

对象存储通常是凭借HTTP调用对象存储本身提供的认证密钥来提供数据访问。因为数据可能通过公共互联网传输，这些密钥就是凭证，而非普通的用户/密码组合。管理凭证更大的任务是身份管理功能的部分，它还能够提供标准化平台集成，如LDAP和Microsoft Active Directory。

访问单个对象或存储段是通过访问控制列表进行分配，这些列表决定或单个或组级数据访问。许多对象存储会允许通过用于存储和检索数据，同样基于Web的REST接口来设置和管理访问控制。

除身份管理以外，不论在传输还是保存状态都必须要通过数据加密来提供安全性。通常在数据传输状态使用TLS(如HTTPS)实现数据保护。

而数据保存状态时，为了防止物理服务器或驱动器/设备直接访问，应对数据进行加密。加密的具体点或实现可取决于终端用户想要管理加密密钥的方式。数据可以在被添加到对象存储之前或同时被加密。

6.合规性&审计

合规性是数据安全的另一个方面，侧重于满足特定受控的行业(如医疗保健和金融)保存数据的监管要求。

通常，兼容系统需要能规定数据的不可变性，提供对象版本控制(以便可以追踪更改的数据)，实现对象锁定或WORM(一写多读)，再次用于不可变的数据。相比块系统和基于文件的系统，大多数对象存储不更新数据。这一点提供了一定程度的控制权，符合合规性要求。

审计与合规性互补，能对数据如何在对象存储系统中存储进行追踪。审计追踪还可以提供附加信息，例如层之间的数据迁移，内容校验和验证(确保无篡改)以及对单个数据对象存储段的所有访问。

7.部署模型

对象存储一直在走向软件定义存储(SDS)的前列。大型向外扩展型部署的本质意味着对象存储与商用硬件和供应商所提供软件的成本模式能够进行很好地协作。最终，我们看到许多基于纯软件的对象存储实现。

当然，商用硬件的采用无法满足所有的要求。很多潜在客户可能不情愿或无法管理采购和构建一个定制对象存储解决方案的过程，而宁愿从供应商那里拿到一个软硬件的组合解决方案。

在这种情况下，供应商为了满足客户需求要提供设备，可能会与已经进入客户数据中心的服务器和存储供应商合作。

为什么?因为支持模式，内部技术和部署蓝图都已经是基于首选硬件供应商的了。为了最大的灵活性，供应商可能提供以下三种选项：

纯软件——用作VSA(虚拟存储设备)或本地部署到硬件上。

设备——专用硬件设备，构建为一个白盒子或与要硬件提供商之一配合使用。

云——在公有云中作为一个实例部署。

每一个选项，客户应该希望完全的互操作性和一致的管理接口。

8.协议支持和标准

初期的对象存储是基于HTTP(S)协议，采用基于REST的API调用存储和检索数据。 HTTP的使用很灵活，可以在网络((局部或广域网)上的任何地方访问数据，然而，相比在横向扩展型文件系统中访问数据，为了使用对象存储，应用程序必须进行编码。

因此，供应商已经开始对其产品增加NFS和SMB支持，允许通过基于文件的标准协议来存储和检索数据。为了完全支持向外扩展型功能，其中还应包括支持并行文件系统。

扩展协议支持意味着数据采用了对象存储，现有应用程序能够轻松地进行移植或修改。而值得我们深思的是，与横向扩展型文件存储相比，对象存储的架构差异在于，它是通过使用模拟了文件存储的对象存储提供。

基本数据并不是用基于inode(索引节点)和目录架构进行存储，因此系统崩溃后，FSCK(文件系统扫描)的概念并不适用。与传统文件系统相比，这对(支持文件系统的)对象存储的可扩展性和性能有很大的影响。

协议支持还需要扩展到采用业界标准。对对象存储而言，这意味着要使用Amazon S3和Swift——两个已经获得广泛普及的“标准”。亚马逊凭借2006年发布的S3平台进入对象市场，因为S3 API经历了成长，成熟以及完善的过程，所以成为了许多供应商选择遵循的标准。Swift已经发展成OpenStack项目的对象存储组件。

9.成本

没有价格和总拥有成本讨论的对象存储，不是完整的对象存储。最显而易见的认证模式是基于容量的——向平台增加更多可用或原始容量，并以实际增量为认证支付更多的钱。供应商还可以选择针对每个节点收费，那么终端用户就要确保它们部署的硬件能够提供尽可能大的容量。

还有一个选择就是按功能收费，一些供应商看准了这个机会，构建了一个包含所有功能选项的收费结构。从终端用户的角度来看，这显然更具竞争力，但隐藏的额外成本可能是一个问题。

计算TCO(总拥有成本)提出了关于对象存储平台效率的一个有趣的问题。横向扩展节点设计采用计算，系统内存和磁盘或闪存存储来提供一定的用户容量。

一旦在白盒硬件上构建，软件的效率与构建解决方案的成本直接相关。到目前为止，没有实际的标准来对比对象存储的效率，这是需要行业发展的一个领域。

结论

以上就是对象存储的九大主要特征。供应商将以实现这些功能的方式来使其产品架构更具吸引力。