传统上,Web 应用程序使用文件系统和数据库在后端存储用户数据。这很简单,结构化数据存储到数据库中,其他任何数据都存储到文件系统中。这很容易管理,因为很少有应用程序生成非结构化数据——大多数应用程序通过表单获取用户输入并将数据保存到数据库中。然而,现在时代正在发生变化,随着社交媒体、云存储、数据分析平台和其他计算范式的兴起,越来越多的非结构化数据正在被推送到互联网上。
背景
IDC 在 2014 年进行了一项研究,预测到 2020 年,全球创建和复制的非结构化数据将达到 44 泽字节,即每年 44 万亿千兆字节。这意味着比 2013 年的 4.4 泽字节增加了 10 倍。如果你觉得这有点多,想想这个——到 2015 年,非结构化数据已经占所有数字数据的 90% 了!

因此,与其他计算范式一样,存储系统也需要发展以适应这波席卷互联网的非结构化数据浪潮。但在我们继续之前,让我先为您定义非结构化数据。通常,无法组织到关系数据库中进行存储的数据被称为非结构化数据。您可以拥有文本或非文本的非结构化数据。文本文档、电子邮件、演示文稿等是非文本非结构化数据的示例。非文本非结构化数据的示例包括视频、图像、音频文件等。
为什么选择对象存储?
我们现在知道正在生成大量非结构化数据,并且需要以一种易于访问、安全可靠的方式对其进行处理。我们已经拥有自现代计算开始以来人们一直在使用的存储机制——文件系统。那么,为什么我们需要一个全新的存储范式呢?答案在于细节。让我们更深入地了解一下需求。
- 当我们谈论非结构化数据及其规模时,重要的是要了解用于存储数据的底层系统应该能够很好地扩展。但是扩展文件系统很困难。您不仅需要管理文件系统强加给您的(有时)不必要的元数据和层次结构,还需要处理其他事务,例如备份管理。
- 仅仅收集非结构化数据是不够的。您还需要应用一定程度的组织才能理解数据。文本分析、自动分类、自动标记等技术对于从您收集的所有非结构化数据中获取业务意义至关重要。具有固定布局的文件系统使实现这一点变得困难。
- 文件系统不是为 HTTP(S) 而设计的,而是为人类设计的。以编程方式共享和管理文件系统中的文件很困难(想想我们大多数人难以理解的狡猾的 C/C++ 文件处理技巧)。处理文件流和可能的边界情况容易出错,并且需要大量时间和精力。
为了绕过所有这些,需要一些新的东西。从头开始构想,并将新的需求放在首位。这导致了对象存储的出现。
对象存储
与文件系统中的文件不同,对象存储在一个扁平的结构中。只是一个对象的池——没有文件夹、目录或层次结构。您只需通过提供其对象 ID 来请求给定的对象。对象可以是本地对象,也可以是数千英里外的云服务器上的对象,但由于它们位于扁平的地址空间中,因此检索方式完全相同。
另一个重要的方面是元数据处理。对象存储在存储对象元数据时提供了极大的灵活性。这意味着元数据不仅限于存储系统认为重要的内容(想想文件系统中的固定元数据)。您可以手动添加任何类型或数量的元数据。例如,您可以分配诸如对象关联的应用程序类型;应用程序的重要性;您希望分配给对象的防护级别;您是否希望将此对象复制到另一个站点或站点;何时将此对象移动到不同级别的存储或不同的地理位置;何时删除此对象。等等,可能性是无限的。
通过 HTTP(S) 访问文件非常重要。只有当文件易于访问时,才能对其进行分析或其他技术处理。对象存储很好地处理了这一点。几乎所有提供对象存储的平台都提供了 REST API 来帮助您通过 HTTP(S) 访问文件。API 不仅有助于访问数据,还可以帮助您进行身份验证、获取文件属性和管理权限——您在文件系统中需要手动执行的所有操作。
结论
现在互联网上的大部分数据都是非结构化的,专家们预测这种趋势将继续以两位数的速度增长,因此必须正视这一挑战。非结构化数据不仅需要以易于访问的方式进行存储,还需要能够从随着时间推移收集的非结构化数据中获取业务意义。
对象存储承诺帮助您实现所有这些以及更多。凭借 HTTP(S) 访问、灵活的元数据和扁平的存储模型,它拥有处理非结构化数据浪潮所需的一切。
机会最初表现为挑战。只有当您拥有解决挑战的方案时,它才会成为您的机会。对象存储范式是您应对非结构化数据挑战的解决方案。将这个挑战转化为您的机会!