有人可以解释一下对象存储和文件存储有什么区别吗？
我在wiki上阅读了有关对象存储的信息，还阅读了http://www.dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf，还阅读了 amazons docs(S3)、openstack swift等等。但是有人可以给我一个例子来更好地理解吗？
所有的区别仅在于我们为“对象存储”对象添加了更多元数据？
例如，如何使用某种编程语言（例如 python）来存储像对象一样的图像？
谢谢。
IMO，对象存储与规模无关，因为有人可以构建一个能够存储大量文件的 FS，即使在单个目录中也是如此。
它也与访问方法无关。对文件系统中数据的 HTTP 访问已在许多著名的 NAS 系统中可用。
按 OID 存储/访问是一种无需为数据命名而处理数据的方法。它也可以在文件上完成。我相信有一个 NFS 协议扩展允许这样做。
我要强调一点：对象存储是一种（新的/不同的）“以对象为中心”的数据、访问和管理方式。
想想以下几点：
今天的快照是什么？它们是卷的时间点副本。拍摄快照时，卷中的所有文件也会被快照。不管大家喜不喜欢，不管大家是否需要。一个完整的卷快照可以使用（浪费？）大量空间，而只需要快照几个文件。
在对象存储系统中，您很少会看到卷的快照，对象将被快照，也许是自动的。这是对象版本控制。所有对象都不需要版本化，每个单独的对象都可以判断它是否被版本化。
如何保护文件/卷免受灾难？通常，在灾难恢复 (DR) 设置中，会设置整个卷/卷集以复制到 DR 站点。同样，这并不影响是否要复制单个文件。灾难防护的单位是体积。文件是小菜一碟。
在对象存储系统中，DR 不是以卷为中心的。对象元数据可以决定应该存在多少副本以及在哪里（地理位置/故障域）。
其他功能类似：
分层 - 基于其元数据放置在存储层/类中的对象，独立于其他不相关的对象。
生命 - 对象在层之间移动，更改副本数量等，单独而不是作为一个组。
身份验证 - 如果需要，可以从不同的身份验证域对单个对象进行身份验证。
如您所见，思想的变化在于，在对象存储中，一切都与对象有关。
将此与传统的思考和管理方式进行对比，并访问更大的容器，如卷（包含文件）不是对象存储。
上述特征及其以对象为中心的特性非常适合非结构化数据的要求，因此也很受关注。
如果一个存储系统在其思想上是以对象（或文件）为中心而不是以卷为中心（无论访问协议或规模如何），那么它就是一个对象存储系统。
文件存储和对象存储之间有一些非常根本的区别。
文件存储将自身呈现为具有目录、子目录和文件的文件系统层次结构。当文件数量不是很大时，它很棒并且工作得很好。当您确切知道文件的存储位置时，它也能很好地工作。
另一方面，对象存储通常通过。一个 RESTful API。没有文件系统的概念。相反，应用程序将通过将对象（文件 + 附加元数据）保存到对象存储中。PUT API 和对象存储会将对象保存在系统的某个位置。对象存储平台将为应用程序将存储在应用程序数据库中的该对象提供唯一的密钥（类似于代客票）。如果应用程序想要获取该对象，他们需要做的就是将密钥作为 GET API 的一部分提供，然后对象存储将获取该对象。
希望这现在很清楚。
披露 - 我为一家开发和销售大型文件系统和对象存储平台的供应商 (NetApp) 工作，我会尽量保持实现中立，但我的认知偏见可能会不知不觉地影响我的回答。
从访问、可编程性和实现的角度来看，存在许多差异，但是考虑到这可能主要由程序员而不是基础设施或存储人员阅读，我将在此重点关注这方面。
从外部/编程的角度来看，主要区别在于对象存储中的对象是作为一个完整单元创建、删除或更新的，您不能将数据附加到对象，也不能更新对象的一部分对象“就地”，但是您可以在保持相同对象 ID 的同时替换它。创建、读取、更新和删除对象通常是通过相对简单的 API 完成的，这些 API 几乎总是基于 REST 或基于 REST，并鼓励一种思维方式，即存储是可编程资源或可能作为多租户远程服务。虽然我知道大多数对象存储都支持对象内的字节范围读取，但总的来说，对象存储最初设计用于处理整个对象。对象存储 API 的良好示例是 Amazon S3（对象存储访问的默认标准）、OpenStack Swift 和 Azure Blob 服务 REST API 使用的那些。描述这些 API 背后的后端实现本身就是一本书。
另一方面，文件系统中的文件具有可应用于它们的更广泛的功能集，包括附加数据和更新数据。编程模型比对象存储更复杂，现在几乎总是通过“POSIX”风格的接口以编程方式访问，并且通常尝试最有效地利用 CPU 和内存，并鼓励文件系统是私有本地资源的心态. NFS 和 SMB 确实允许将文件系统作为多租户资源提供，但是这些通常会受到程序员的怀疑，因为尽管它们完全支持 POSIX，但与“本地”文件系统相比，它们有时在反应方式上存在细微差别语义。要更新本地文件系统中的文件，您可能会使用 API，例如https://www.classes.cs.uchicago.edu/archive/2017/winter/51081-1/LabFAQ/lab2/fileio.html或https://msdn.microsoft.com/en-us/library/mt794711( v=vs.85).aspx。谈论文件系统实现的相对优点，例如 NTFS、BTRFS、XFS、WAFL 和 ZFS，往往会导致一场几乎不值得任何人花时间的宗教战争，但如果你给我买啤酒，我会很乐意与你分享我的意见.
从用例的角度来看，如果您想保留大量照片、视频或二进制构建工件，那么对象存储通常是一个不错的选择。另一方面，如果您想将数据持久存储在二叉树中并在存储介质上更新该数据，那么对象存储根本无法工作，而使用文件系统会更好（您也可以为此使用原始块设备，但自 90 年代初以来我还没有看到有人这样做）
另一个很大的区别是文件系统被设计为强一致性，并且通常通过低到中等延迟（50 微秒 - 50 毫秒）的网络访问，而对象存储通常最终是一致的，并且分布在一个无共享的基础设施上，这些基础设施通过低延迟连接在一起。带宽高延迟广域网及其到第一个字节的时间有时可以以整秒的倍数来衡量。从对象存储执行大量小（4K - 16K）随机读取可能会导致挫败感和性能问题。
对象存储与文件系统的另一个主要好处是，您可以合理地确定您放入对象存储中的任何内容都会保留在那里，直到您再次请求它，并且只要您继续付费，它就永远不会耗尽空间每月收费。这些资源通常通过内置复制、版本控制、自动恢复等大规模运行，而且飓风哈维式的灾难会使数据消失（即使那样，您也可以轻松地选择在另一个位置制作另一个副本）。对于一个文件系统，尤其是您希望您或您的本地操作人员管理的文件系统，您必须希望一切都得到备份，并且当您无法更新数据时它不会意外填满并导致一切崩溃。
我试图简洁，但为了增加混淆，“文件系统”和“对象存储”这两个词被应用于与我上面使用的描述完全不同的东西，例如 NFS，网络文件系统实际上并不是一个文件系统，它是通过远程过程调用实现 posix 存储 API 的一种方式，而 VMware 的 VSAN 将其数据存储在他们称为“对象存储”的东西中，它允许对虚拟机映像进行高速就地更新。
简单的答案是对象访问存储系统或服务利用 API 和其他对象访问方法来存储、检索和查找数据，而不是传统的文件或 NAS。例如，对于文件或 NAS，您使用 NFS（网络文件系统）或 CIFS（例如 windows 文件共享）又名 SMB 又名 SAMBA 访问存储，其中文件具有名称/句柄以及由文件系统确定的关联元数据。
元数据包括关于创建、访问、修改和其他日期、权限、安全性、应用程序或文件类型或其他属性的信息。文件在大小以及每个文件系统的文件数量方面受到文件系统的限制。同样，文件系统在空间容量和文件系统中的文件数量方面受到其总大小或总大小的限制。
对象访问的不同之处在于，虽然文件或 NAS 前端或网关或插件可用于许多解决方案或服务，但主要访问是通过 API 进行的，其中对象可以是任意大小（最多为对象系统的最大值）具有可变大小的元数据（取决于对象系统/服务实现）。对于大多数对象存储系统/服务，您可以指定从几 KB 的用户定义元数据或 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 磁盘 (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 移入/移出的数据量。但是，通常可以安全地假设对象存储可以比文件系统（不使用全局名称空间、联合、文件虚拟化或其他技术）更具可扩展性（取决于实现）。
此外，在我的英特尔推荐读物 Cloud and Virtual Data Storage Networking (CRC Press) 一书中，您将找到有关云和对象存储的更多信息。
我将很快向 www.objectstorage.us 添加更多相关材料。
干杯
这个答案甚至没有解释任何关于差异的事情。
文件存储和对象存储之间有一些非常根本的区别。
文件存储将自身呈现为具有目录、子目录和文件的文件系统层次结构。当文件数量不是很大时，它很棒并且工作得很好。当您确切知道文件的存储位置时，它也能很好地工作。
另一方面，对象存储通常通过。一个 RESTful API。没有文件系统的概念。相反，应用程序将通过将对象（文件 + 附加元数据）保存到对象存储中。PUT API 和对象存储会将对象保存在系统的某个位置。对象存储平台将为应用程序将存储在应用程序数据库中的该对象提供唯一的密钥（类似于代客票）。如果应用程序想要获取该对象，他们需要做的就是将密钥作为 GET API 的一部分提供，然后对象存储将获取该对象。
这解释了其中很大一部分。但你争论元数据。
对象存储没有文件夹的意义，也没有任何使人易于组织的组织结构。当然，文件存储确实拥有所有这些文件夹，这些文件夹使人们可以轻松地组织和随机浏览......在文件数量达到天文数字的服务器环境中，文件夹只是浪费空间和时间。
你说的数据库？好吧，他们不是在谈论对象存储本身，而是在说您的 http 服务（php、webmail 等）在其数据库中具有唯一 ID，以引用可能具有人类可识别名称的文件。
元数据，你说这个文件存储在哪里？这就是元数据的用途。您的单个文件被分成一堆小块，分布在地理位置、服务器和硬盘驱动器之外。这些小片段还包含更多数据，它们包含其他数据片段的奇偶校验信息，甚至可能完全重复。
元数据用于定位该文件在不同地理位置、数据中心、服务器和硬盘驱动器上的每条数据，并用于从硬件故障中恢复任何被破坏的数据。它会自动执行此操作。它甚至可以流畅地移动这些碎片以实现更好的传播。它甚至会重新创建一个已经消失的片段并将其存储在一个新的好硬盘上。
这可能是一个简单的解释；但我认为它可能会帮助您更好地理解。我相信文件存储可以对元数据做同样的事情；但是文件存储是您可以像人一样组织的存储（文件夹，层次结构等），而对象存储没有层次结构，没有文件夹，只是一个平面存储容器。
对象存储 = 块存储 + 丰富的元数据 - 文件层次结构
块存储使用文件系统来指向存储内容的位置。对象存储使用标识符来指向内容及其上下文。这是我对阅读内容寻址与位置寻址的理解
块存储需要一个文件系统和结构，因此更大的文件系统会带来更多的开销。对象存储有很多关于文件的上下文，不需要文件层次结构。戴尔论文第 7 页上的解释清楚地表明了这一点。让我感到困扰的是，在硬盘本身的规模上没有解释。我发现硬盘本身总是使用块存储机制（尽管似乎正在更改为）（尽管似乎正在更改为）
可以在这里找到其他一些见解
实际上，您可以挂载存储桶/容器并从 Linux 访问对象或子文件夹（及其对象）。例如，我在 Ubuntu 上安装了 s3fs，我已经为我的一个 S3 存储桶设置了一个挂载点，并且能够执行常规的 cp、ls 和其他功能，就好像它是另一个文件系统一样。关键是获取软件工具，其中有很多允许您映射存储桶/容器并将其显示为挂载点。除了作为 NAS 之外，还有一些软件工具允许您通过 iSCSI 访问 S3 和其他存储桶/容器。
大多数拥有基于对象的解决方案的公司都根据性能/成本要求选择混合块/文件/对象存储。
从用例的角度来看：
最终，创建对象存储是为了解决爆炸性增长的非结构化数据，比结构化数据快得多。
例如，如果数据库是结构化数据，则非结构化数据将是 word doc 或 PDF。
如何在文件系统中搜索 10 亿个 PDF？（如果它甚至可以首先存储那么多）。
仅搜索 10 亿个文件的元数据的速度有多快？
对象存储目前更多地用于长期或存档、廉价和深度存储，以跟踪数据的更多细节。当搜索或挖掘非常大的数据集时，此元数据变得非常强大。有时，您甚至无需访问数据本身就可以从元数据中获得所需的信息。对象存储解决方案通常可以通过内置的地理故障转移自动复制。
问题是必须重新编写应用程序以使用对象访问方法而不是文件层次结构（从应用程序开发的角度来看这更简单）。这确实是数据存储理念的改变，从管理和使用的角度存储有关该数据的更多可操作信息。
快速示例可能是 MRI 扫描图像。在文件系统上，您有所有者/创建日期，但没有太多其他内容。如果它是一个对象，则 MRI 周围的所有信息都可以与它一起存储在元数据中，例如患者姓名、MRI 中心位置、请求的医生、保险公司等。
块/文件更适合性能比保留和成本更重要的本地访问或 OTLP。
例如，您不想等待几分钟来打开 Word 文档，但您可以等待几分钟来完成数据挖掘/商业智能流程。
另一个例子是法律搜索，您必须搜索从 5 年前到现在的所有内容。使用保留策略来减少活动数据集和成本，如果不从磁带恢复，您将如何做到这一点？
对象存储是替代磁带等长期归档方法的绝佳解决方案。
为块和文件设置复制和故障转移在企业中可能会变得非常昂贵，并且通常需要非常昂贵的软件和服务。
注意：在较低级别，对象存储访问通过 RESTful API 发生，这更像是一个 Web 请求，而不是访问路径末尾的文件。
这是一篇值得一读的好文章： https ://cloudian.com/blog/object-storage-vs-file-storage/ 引用自文章：
首先，对象存储克服了文件存储面临的许多限制。将文件存储视为仓库。当您第一次将一盒文件放在那里时，似乎您有足够的空间。但随着数据需求的增长，您会在不知不觉中将仓库填满。另一方面，对象存储就像仓库，只是没有屋顶。您可以无限地添加数据——没有限制。如果您主要检索较小的或单个文件，那么文件存储的性能会大放异彩，尤其是在数据量相对较少的情况下。但是，一旦开始缩放，您可能会开始想，“我将如何找到我需要的文件？” 在这种情况下，您可以将对象存储视为代客泊车，而文件存储更像是自助泊车（是的，另一个类比，但请耐心等待！）。当你把你的车开进一个小地方时，你就知道你的车在哪里。然而，想象一下那块土地要大一千倍——找到你的车会更难，对吧？因为对象存储具有可自定义的元数据，并且所有对象都存在于平面地址空间中，所以这类似于将您的钥匙交给代客。您的汽车将存放在某个地方，当您需要时，代客泊车会为您取车。取回您的汽车可能需要更长的时间，但您不必担心四处寻找它。您的汽车将存放在某个地方，当您需要时，代客泊车会为您取车。取回您的汽车可能需要更长的时间，但您不必担心四处寻找它。您的汽车将存放在某个地方，当您需要时，代客泊车会为您取车。取回您的汽车可能需要更长的时间，但您不必担心四处寻找它。