有人可以解释对象存储和文件存储之间有什么区别吗？
我在wiki上阅读了关于对象存储的内容，同时我阅读了http://www.dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf，我还阅读了amazons docs（S3），openstack swift等等。但有人能给我一个更好理解的例子吗？ / p>
所有不同之处仅在于“对象存储”对象我们添加了更多元数据吗？
例如如何使用某种编程语言（例如python）存储像对象这样的图像？
感谢。
答案 0 :(得分：16)
IMO，对象存储与规模无关，因为有人可以构建一个能够存储大量文件的FS，即使在一个目录中也是如此。
它也与访问方法无关。许多着名的NAS系统都提供对文件系统中数据的HTTP访问。
OID存储/访问是一种处理数据的方法，无需为命名而烦恼。它也可以在文件上完成。我相信有一个NFS协议扩展允许这样做。
我会集中思考：对象存储是一种（新的/不同的）“以对象为中心”的数据思考方式，它的访问和管理。
考虑以下几点：
今天的快照是什么？它们是卷的时间点副本。拍摄快照时，卷中的所有文件也会被捕捉。是否所有人都喜欢或不喜欢它们。对于完整的卷快照，可以使用大量空间（浪费？），而只需要捕捉少量文件。
在对象存储系统中，您很少会看到卷的快照，对象将被快照，可能是自动的。这是对象版本控制。不需要对所有对象进行版本控制，每个单独的对象都可以判断它是否已经过版本化。
如何保护文件/卷免受灾难影响？通常，在灾难恢复（DR）设置中，将设置整个卷/卷集以复制到DR站点。同样，这并不打算是否要复制单个文件。灾害保护的单位是数量。文件很小。
在对象存储系统中，DR不是以卷为中心的。对象元数据可以决定应该存在多少副本以及位置（地理位置/故障域）。
与其他功能类似：
分层 - 基于独立于其他无关对象的元数据放置在存储层/类中的对象。
生活 - 对象在各层之间移动，单独更改副本数等，而不是作为一个组。
身份验证 - 如果需要，可以从不同的身份验证域对单个对象进行身份验证。
正如您所看到的，思维的变化是在对象存储中，一切都与对象有关。
将此与传统的思维方式进行对比，管理和访问较大的容器（如卷（包含文件））不是对象存储。
上述特征及其以对象为中心的特征非常符合非结构化数据的要求，因而也符合其兴趣。
如果存储系统的思想是以对象（或文件）为中心而不是以卷为中心，（无论访问协议或规模如何），它都是一个对象存储系统。
答案 1 :(得分：12)
文件存储和对象存储之间存在一些非常根本的区别。
文件存储本身就是一个包含目录，子目录和文件的文件系统层次结构。当文件数量不是很大时，它很棒并且工作得很漂亮。当您确切知道文件的存储位置时，它也可以正常工作。
另一方面，对象存储通常通过自身呈现。 RESTful API。没有文件系统的概念。相反，应用程序会将对象（文件+附加元数据）保存到对象库。 PUT API和对象存储器会将对象保存在系统中的某个位置。对象存储平台将为应用程序提供应用程序将存储在应用程序数据库中的该对象的唯一密钥（类似于代客票证）。如果应用程序想要获取该对象，他们需要做的就是将密钥作为GET API的一部分提供，对象将由对象存储器提取。希望现在已经清楚了。
答案 2 :(得分：3)
简单的答案是，对象访问的存储系统或服务利用API和其他对象访问方法来存储，检索和查找数据，而不是传统的文件或NAS。例如，使用文件或NAS，您可以使用NFS（网络文件系统）或CIFS（例如Windows文件共享）（也称为SMB）SAMBA访问存储，其中文件具有名称/句柄以及由文件系统确定的关联元数据。
元数据包括有关创建，访问，修改和其他日期，权限，安全性，应用程序或文件类型或其他属性的信息。文件系统的大小以及每个文件系统的文件数受文件系统的限制。同样，文件系统受空间容量和文件系统中文件数量的总大小或聚合大小的限制。
对象访问的不同之处在于，虽然文件或NAS前端或网关或插件可用于许多解决方案或服务，但主要访问是通过API，其中对象可以是任意大小（最大为对象）系统）以及可变大小的元数据（取决于对象系统/服务实现）。对于大多数对象存储系统/服务，您可以指定几千字节的用户定义元数据或GBytes。您将使用GBytes的元数据？除了普通信息之外，还可以为策略，管理，其他副本所在位置添加更多数据，缩略图或视频，音频等的小型预览。
对象访问API或接口的一些示例包括Amazon Web Services（AWS）简单存储服务（S3）或其他基于HTTP和REST的SNIA CDMI。不同的解决方案还将支持IOS（例如iphone / ipad）访问，SOAP，Torrent，WebDav，JSON，XAM以及其他NFS / CIFS。此外，许多对象存储系统或服务支持python的编程绑定等。 API允许您基本上打开流，然后获取或放置，列表和API /系统支持的其他功能，以确定您将如何使用它。
例如，我使用Rackspace Cloud文件和Amazon S3（以及EBS和Glacier）来备份，存储和存档数据。我可以访问通过Web浏览器存储的对象或工具，包括Jungle disk（JD），这是我备份和同步文件。 JD处理对象管理并将数据移动到Rackspace以及Amazon。如果我倾向于，我也可以使用API进行一些编程，然后直接访问提供我的安全凭证的那些站点中的任何一个来处理我存储的对象。
这是我去年在荷兰做过的会话中的对象和云存储入门的链接，它有一些简单的对象和访问示例。 http://storageio.com/DownloadItems/Nijkerk_Nov2012/SIO_IndustryTrends_CloudObjectStorage.pdf
使用程序化绑定，您可以在程序中定义数据结构或对象，然后使用API或调用来存储，检索，列出数据，元数据访问等。如果有特定的对象存储系统，软件或者您希望与之合作或需要知道如何编程的服务，访问他们的网站，您应该通过示例找到他们的SDK或API信息。使用对象，一旦在服务或产品/系统上创建初始存储桶或容器，就可以随时创建和存储其他对象。
以下链接作为AWS S3 API /编程的示例： http://docs.aws.amazon.com/AmazonS3/latest/API/IntroductionAPI.html
理论上谈论的对象存储系统具有无限数量的对象或对象大小，实际上，大多数系统，解决方案，软件或服务受到他们测试或当前支持的限制，这可能是数十亿对象，对象大小为5GByte或更大。注意特定服务或产品的限制，以确定实际测试，支持的内容与体系结构可能或在webex或powerpoint上实现的内容。
它的服务和产品/服务/软件依赖于对象的数量，对象的大小，元数据的大小以及可以通过其API移入/移出的数据量。但是，通常可以安全地假设对象存储可以比文件系统（不使用全局名称空间，联合，文件虚拟化或其他技术）更具可伸缩性（取决于实现）。
同样在我的书“云和虚拟数据存储网络（CRC Press）”中，您可以找到有关云和对象存储的更多信息。
我将很快向www.objectstorage.us添加更多相关资料。
干杯gs
答案 3 :(得分：2)
对象存储=块存储 +丰富的元数据 - 文件层次结构
块存储使用文件系统指向存储内容的位置。 对象存储使用标识符指向内容及其上下文。 这是我对阅读Content-addressed vs. location-addressed
的理解块存储需要一个文件系统和结构，所以使用更大的文件系统会带来更多的开销。 对象存储有很多关于文件的上下文，不需要文件层次结构。 Dell paper的第7页上的解释清楚地表明了这一点。困扰我的是，在硬盘本身的规模上没有解释。 我发现硬盘本身总是使用块存储机制（虽然这似乎正在改变） （虽然这似乎正在改变）
可以找到其他一些见解here
答案 4 :(得分：1)
哦，我希望我可以投下一些答案，然后用帐户投票给别人。
在撰写本文时，投票率最高的人甚至没有解释任何有关差异的内容。
文件存储和对象存储之间存在一些非常根本的区别。
文件存储本身就是一个包含目录，子目录和文件的文件系统层次结构。当文件数量不是很大时，它很棒并且工作得很漂亮。当您确切知道文件的存储位置时，它也可以正常工作。
另一方面，对象存储通常通过自身呈现。 RESTful API。没有文件系统的概念。相反，应用程序会将对象（文件+附加元数据）保存到对象库。 PUT API和对象存储器会将对象保存在系统中的某个位置。对象存储平台将为应用程序提供应用程序将存储在应用程序数据库中的该对象的唯一密钥（类似于代客票证）。如果应用程序想要获取该对象，他们需要做的就是将密钥作为GET API的一部分提供，对象将由对象存储器提取。希望现在已经清楚了。
这解释了它的很大一部分;但你争论的是元数据。以下是我最近两天阅读的内容，由于这个问题尚未解决，我将发布。
对象存储没有任何文件夹感，也没有任何组织结构，使人们可以轻松组织。当然，文件存储确实拥有所有那些使人们可以轻松组织和随机播放的文件夹......在服务器环境中，文件数量是天文数字，文件夹只是浪费空间和时间。
你说的数据库？好吧，他不是在讨论对象存储本身，他说你的http服务（php，webmail等）在其数据库中有唯一的ID来引用一个可能具有人类可识别名称的文件。
元数据，你说这个文件存储在哪里？这就是元数据的用途。您将单个文件拆分为一堆小块，并分散在地理位置，服务器和硬盘驱动器之外。这些小块还包含更多数据，它们包含其他数据的奇偶校验信息，甚至可能是完全重复。
元数据用于在不同的地理位置，数据中心，服务器和硬盘驱动器上查找该文件的每个数据，以及用于从硬件故障中恢复任何被破坏的部分。它会自动执行此操作。它甚至可以流畅地移动这些碎片以获得更好的传播效果。它甚至会重新创建一个已经消失的部分并将其存储在新的良好硬盘上。
这可能是一个简单的解释;但我认为这可能有助于你更好地理解。我相信文件存储可以对元数据做同样的事情;但文件存储是一个存储，你可以组织为人（文件夹，层次结构等），而对象存储没有层次结构，没有文件夹，只有一个扁平的存储容器。
答案 5 :(得分：1)
大多数使用基于对象的解决方案的公司都会根据性能/成本要求选择块/文件/对象存储的混合。
从用例角度来看：
最终创建对象存储是为了解决爆炸式增长的非结构化数据，远远快于结构化数据。
例如，如果数据库是结构化数据，则非结构化将是单词doc或PDF。
如何在文件系统中搜索10亿个PDF？ （如果它甚至可以存储那么多的那些）。
您能多快搜索10亿个文件的元数据？
对象存储目前更多地用于长期或存档，廉价和深度存储，它可以跟踪数据的更多细节。在搜索或挖掘非常大的数据集时，此元数据变得非常强大。有时您甚至无需访问数据本身就可以从元数据中获取所需内容。对象存储解决方案通常可以通过内置的地理故障转移自动复制。
问题是必须重新编写应用程序才能使用对象访问方法而不是文件层次结构（从app dev角度来看，这更简单）。这实际上改变了数据存储的理念，并从管理角度和使用中存储了有关该数据的更多可操作信息。
快速示例可能是MRI扫描图像。在文件系统上，您拥有所有者/创建日期，但没有其他日期。如果它是一个物体，MRI周围的所有信息都可以与元数据一起存储，如患者姓名，MRI中心位置，请求博士，保险公司等。
块/文件更适合本地访问或OTLP，其中性能比保留和成本更重要。
例如，您不希望等待几分钟才能打开Word文档，但您可以等待几分钟以完成数据挖掘/商业智能流程。
另一个例子是合法搜索，你需要搜索从5年前到现在的所有内容。使用保留策略来减少活动数据集和成本，如果不从磁带恢复，您甚至会如何做到这一点？
对象存储是替换磁带等长期存档方法的绝佳解决方案。
为块和文件设置复制和故障转移在企业中可能会非常昂贵，并且通常需要非常昂贵的软件和服务。
注意：在较低级别，对象存储访问通过RESTful API进行，这更像是Web请求，而不是访问路径末尾的文件。
答案 6 :(得分：1)
实际上，您可以挂载存储桶/容器并从Linux访问对象或子文件夹（及其对象）。例如，我在Ubuntu上安装了s3fs，我已经为我的一个S3存储桶设置了挂载点，并且能够执行常规的cp，ls和其他功能，就像它是另一个文件系统一样。关键是获得有足够的软件工具，允许您映射桶/容器并将其作为挂载点呈现。除了NAS之外，还有一些软件工具允许您通过iSCSI访问S3和其他存储桶/容器。
答案 7 :(得分：0)
答案 8 :(得分：0)
我认为白皮书很好地解释了对象存储的想法。我不知道从用户应用程序使用对象存储设备（在SCSI OSD的意义上）的任何标准方法。
对象存储正在某些大型存储产品中使用，例如Panasas的存储设备。但是，这些设备然后将文件系统导出到最终用户。恕我直言，T10 OSD的想法从来没有真正抓住动力。
答案 9 :(得分：0)
这是一篇值得阅读的好文章： https://cloudian.com/blog/object-storage-vs-file-storage/ 从地上引述：
首先，对象存储克服了文件存储面临的许多限制。将文件存储视为仓库。当您第一次在其中放一盒文件时，似乎您有足够的空间。但是随着数据需求的增长，您会在不知不觉中将仓库填满。另一方面，对象存储就像仓库一样，除了没有屋顶。您可以无限地添加数据-天空是无限的。 如果您主要是检索较小的文件或单个文件，则文件存储将带来性能的提升，尤其是在数据量相对较少的情况下。但是，一旦开始扩展，您可能会开始怀疑：“我将如何找到所需的文件？” 在这种情况下，您可以将对象存储视为代客泊车，而文件存储更像是自泊车（是的，另一个类比，但请耐心等待！）。当您将汽车拖入一小部分时，您便会确切知道汽车的位置。但是，想像一下那是一千倍之多–很难找到你的车，对吧？ 由于对象存储具有可自定义的元数据，并且所有对象都位于一个固定的地址空间中，因此类似于将密钥移交给代客。您的汽车将存放在某个地方，当您需要时，代客将为您提供汽车。取回您的汽车可能会花费一些时间，但是您不必担心到处徘徊寻找它。