オブジェクトストレージとファイルストレージの違い
Object StorageとFile Storageの違いを教えてください。
私は 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 Service REST API。これらのAPIの背後にあるバックエンド実装を説明することは、それ自体が本になります。
一方、ファイルシステム内のファイルには、データの追加や所定の場所でのデータの更新など、ファイルシステムに適用できる広範な機能セットがあります。プログラミングモデルはオブジェクトストアよりも複雑であり、現在ではほとんど常に「POSIX」スタイルのインターフェイスを介してプログラムでアクセスされ、一般にCPUとメモリを最も効率的に使用しようとし、ファイルシステムがプライベートローカルリソースであるという考え方を奨励しています。 NFSおよびSMBは、マルチテナントリソースとしてファイルシステムを使用可能にしますが、これらは、 "と比較して反応に微妙な違いがあることがあるため、多くの場合、プログラマーによって疑われて扱われます。 POSIXセマンティクスの完全なサポートにもかかわらず、ローカル」ファイルシステム。ローカルファイルシステム内のファイルを更新するには、おそらく https://www.classes.cs.uchicago.edu/archive/2017/winter/のようなAPIを使用します。 51081-1/LabFAQ/lab2/fileio.html または https://msdn.Microsoft.com/en-us/library/mt794711（v = vs.85）.aspx 。Talking NTFS対BTRFS対XFS対WAFL対ZFSなどのファイルシステム実装の相対的なメリットについては、宗教的な戦争をもたらす傾向がありますが、誰かに時間をかける価値はほとんどありませんが、ビールを買ってくれたら喜んで私の意見を共有します。
ユースケースの観点から、大量の写真、ビデオ、またはバイナリビルドアーティファクトを保持したい場合、多くの場合、オブジェクトストアが適しています。一方、データをバイナリツリーに永続的に保存し、そのデータをストレージメディア上の所定の場所で更新したい場合は、オブジェクトストアが機能しないだけで、ファイルシステムを使用したほうがはるかに良いでしょう（また、そのために未加工のブロックデバイスを使用しますが、90年代前半から誰もそれを実行していません。
他の大きな違いは、ファイルシステムが非常に一貫性があるように設計されており、通常、低から中程度のレイテンシ（50マイクロ秒-50ミリ秒）ネットワーク経由でアクセスされるのに対して、オブジェクトストアは最終的に一貫性があり、低で一緒に接続された共有なしインフラストラクチャに分散される帯域幅高遅延のワイドエリアネットワークと最初のバイトまでの時間は、数秒の倍数で測定される場合があります。オブジェクトストアから小さな（4K-16K）ランダム読み取りを大量に実行すると、フラストレーションやパフォーマンスの問題が発生する可能性があります。
オブジェクトストアとファイルシステムのもう1つの主な利点は、オブジェクトストアに入れたものは、再度要求するまでそこに残り、支払いを続ける限りスペースがなくなることはないということです。月額料金。これらのリソースは通常、組み込みのレプリケーション、バージョン管理、自動リカバリなどを使用して大規模に実行され、ハリケーンハーベイスタイルの災害以外にデータが消失することはありません（それでも、別の場所に別のコピーを作成する簡単なオプションがあります）。ファイルシステム、特にあなたやあなたの地元の経営者が管理することを期待しているものでは、すべてがバックアップされ、誤っていっぱいにならず、データを更新できなくなったときにすべてが溶けないことを期待する必要があります。
私は簡潔にしようとしましたが、混乱を助長するために、「ファイルシステム」と「オブジェクトストア」という言葉は、上記で使用した説明とは異なるものに適用されます。たとえば、NFSネットワークファイルシステムは実際にはありませんファイルシステム、リモートプロシージャコールを介してposixストレージAPIを実装する方法、およびVMwareのVSANは、仮想マシンイメージのインプレース高速更新を可能にする「オブジェクトストア」と呼ばれるものにデータを格納します。
簡単な答えは、オブジェクトにアクセスするストレージシステムまたはサービスは、従来のファイルやNASとは対照的に、データを保存、取得、検索するためにAPIやその他のオブジェクトアクセス方法を利用するということです。たとえば、ファイルまたはNASの場合、NFS（ネットワークファイルシステム）またはCIFS（Windowsファイル共有など）を使用してストレージにアクセスします。別名SMB別名SAMBAで、ファイルには関連メタデータを持つ名前/ハンドルがあります）ファイルシステムによって決定されます。
メタデータには、作成日、アクセス日、変更日、その他の日付、権限、セキュリティ、アプリケーションまたはファイルの種類、またはその他の属性に関する情報が含まれます。ファイルは、ファイルシステムごとにサイズとファイルシステムごとのファイル数によって制限されます。同様に、ファイルシステムは、スペース容量とファイルシステム内のファイル数の点で、合計サイズまたは集約サイズによって制限されます。
オブジェクトアクセスは異なりますが、ファイルまたはNASフロントエンドまたはゲートウェイまたはプラグインは多くのソリューションまたはサービスで使用できますが、主なアクセスはオブジェクトが任意のサイズ（up （オブジェクトシステムの最大値まで）可変サイズのメタデータ（オブジェクトシステム/サービスの実装に依存）ほとんどのオブジェクトストレージシステム/サービスでは、数キロバイトのユーザー定義メタデータまたはGバイトからどこでも指定できます。 GBytesのメタデータを使用しますか？通常の情報に加えて、ポリシー、管理、他のコピーの場所、ビデオ、オーディオなどのサムネイルまたは小さなプレビュー用のデータを追加してください。
オブジェクトアクセスAPIまたはインターフェイスの例には、Amazon Webサービス（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に加えて）の両方を使用します。ウェブブラウザまたは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を介して入出力できるデータの量に関しては、まさにサービスと製品/サービス/ソフトウェアに依存します。ただし、オブジェクトストレージは、ファイルシステムよりもはるかにスケーラブルである（実装に応じて）（グローバルネームスペース、フェデレーション、ファイル仮想化、またはその他の手法を使用せずに）できると想定しても安全です。
また、Intel Recommended Readingである私の著書クラウドおよび仮想データストレージネットワーキング（CRC Press）には、クラウドおよびオブジェクトストレージに関する詳細情報が記載されています。
関連資料をwww.objectstorage.usにすぐに追加します。
乾杯gs
オブジェクトストレージ=ブロックストレージ+リッチメタデータ-ファイル階層
ブロックストレージは、ファイルシステムを使用して、コンテンツの保存場所を指定します。 Object Storageは、識別子を使用してコンテンツと彼のコンテキストを指し示します。これは私の読み方の理解です Content-addressed vs. location-addressed
Block Storageはファイルシステムと構造化を必要とするため、より大きなファイルシステムではオーバーヘッドが大きくなります。オブジェクトストレージにはファイルに関する多くのコンテキストがあり、ファイル階層は必要ありません。 Dell paper の7ページにある説明は、これを明確に示しています。ハードディスク自体は常にブロックストレージメカニズムを使用していることがわかりました（変更されているようですが）（変更されているようです）
いくつかの他の洞察を見つけることができます ここ
ああ、私はいくつかの答えに反対票を投じ、他の人にアカウントで賛成票を投じることができたらいいのにと思います。
この記事の執筆時点で最も票を集めた人は、違いについても何も説明していません。
ファイルストレージとオブジェクトストレージには、非常に基本的な違いがいくつかあります。
ファイルストレージは、ディレクトリ、サブディレクトリ、およびファイルを含むファイルシステム階層として表示されます。ファイルの数がそれほど多くない場合、それは素晴らしく、美しく機能します。また、ファイルの保存場所を正確に知っている場合にも機能します。
一方、オブジェクトストレージは通常、それ自体を介して提供されます。 RESTful API。ファイルシステムの概念はありません。代わりに、アプリケーションはオブジェクト（ファイル+追加のメタデータ）をオブジェクトストアに保存します。 PUT APIとオブジェクトストレージは、オブジェクトをシステムのどこかに保存します。オブジェクトストレージプラットフォームは、アプリケーションがアプリケーションデータベースに格納するオブジェクトの一意のキー（バレットチケットに類似）をアプリケーションに提供します。アプリケーションがそのオブジェクトを取得する場合、GET APIの一部としてキーを与えるだけで、オブジェクトはオブジェクトストレージによって取得されます。
これが明確になったことを願っています。
これにより、その大部分が説明されました。しかし、あなたはメタデータについて議論しました。以下は、この2日間に私が読んでいたものです。これは解決されていないので、投稿します。
オブジェクトストレージには、フォルダの感覚や、人間が簡単に整理できるようなあらゆる種類の組織構造がありません。もちろん、ファイルストレージには、人間が整理してシャッフルするのを簡単にするすべてのフォルダーがあります...と時間。
あなたが言うデータベース？さて、彼はオブジェクトストレージ自体のことを言っているのではなく、httpサービス（php、webmailなど）がデータベースに一意のIDを持ち、人間が認識できる名前を持つファイルを参照していると言っています。
メタデータ、このファイルはどこに保存されていますか？それがメタデータの目的です。単一のファイルが多数の小さな断片に分割され、地理的な場所、サーバー、ハードドライブに分散します。これらの小さな断片には、より多くのデータが含まれています。他のデータのパリティ情報、または完全な複製も含まれています。
メタデータは、さまざまな地理的場所、データセンター、サーバー、ハードドライブ上でそのファイルのすべてのデータを見つけるために使用されるほか、ハードウェア障害から破壊された部分を復元するために使用されます。これは自動的に行われます。これらの部分を流動的に動かして、より良い広がりをもたせます。なくなったピースを再作成し、新しい良いハードドライブに保存します。
これは簡単な説明かもしれません。しかし、理解を深めるのに役立つと思います。ファイルストレージはメタデータでも同じことができると思います。ファイルストレージは、人間（フォルダ、階層など）として整理できるストレージですが、オブジェクトストレージには階層、フォルダ、フラットストレージコンテナはありません。
オブジェクトベースのソリューションを使用するほとんどの企業では、パフォーマンス/コスト要件に基づいて選択されたブロック/ファイル/オブジェクトストレージが混在しています。
ユースケースの観点から：
最終的にオブジェクトストレージは、爆発的に成長している非構造化データに対処するために作成され、構造化データよりもはるかに高速です。
たとえば、データベースが構造化データである場合、非構造化はWord docまたはPDFになります。
ファイルシステムで10億個のPDFをどのように検索しますか？ （そもそもその数を保存できる場合）。
10億個のファイルのメタデータだけをどれだけ迅速に検索できますか？
現在、オブジェクトストレージは、長期またはアーカイブ用の安価で深層のストレージに使用されており、そのデータの詳細を追跡しています。非常に大きなデータセットを検索またはマイニングする場合、このメタデータは非常に強力になります。データ自体にアクセスしなくても、メタデータから必要なものを取得できる場合があります。通常、オブジェクトストレージソリューションは、地理的フェールオーバーを組み込みで自動的に複製できます。
問題は、ファイル階層ではなく、オブジェクトアクセスメソッドを使用するようにアプリケーションを書き直す必要があることです（アプリ開発の観点からは簡単です）。それは本当にデータストレージの哲学における変化であり、管理の観点および使用法からそのデータに関するより実用的な情報を保存することです。
簡単な例は、MRIスキャン画像です。ファイルシステムには、所有者/作成日がありますが、他にはあまりありません。オブジェクトである場合、MRIを取り巻く情報はすべて、患者名、MRIセンターの場所、要求元の医師、保険会社などのメタデータに一緒に保存できます。
ブロック/ファイルは、保持とコストよりもパフォーマンスが重要なローカルアクセスまたはOTLPにより適しています。
たとえば、Wordドキュメントが開くまで数分待たなくても、データマイニング/ビジネスインテリジェンスプロセスが完了するまで数分待つことができます。
もう1つの例は、5年前から現在までのすべてを検索する必要がある合法的な検索です。アクティブなデータセットとコストを削減するための保持ポリシーを設定したら、テープから復元せずにそれをどうすればよいでしょうか？
オブジェクトストレージは、テープなどの長期アーカイブ方法を置き換えるための優れたソリューションです。
ブロックとファイルのレプリケーションとフェールオーバーのセットアップは、企業で非常に高価になる可能性があり、通常は非常に高価なソフトウェアとサービスが必要です。
注：下位レベルでは、オブジェクトストレージアクセスはRESTful APIを介して行われます。RESTfulAPIは、パスの最後にあるファイルにアクセスするというよりも、Web要求に似ています。
実際には、バケット/コンテナをマウントし、Linuxからオブジェクトまたはサブフォルダー（およびそのオブジェクト）にアクセスできます。たとえば、Ubuntuにs3fsをインストールして、S3バケットの1つにマウントポイントをセットアップし、別のファイルシステムであるかのように通常のcp、ls、その他の機能を実行できるようにしました。重要なのは、バケット/コンテナをマップしてマウントポイントとして提示できるソフトウェアツールをたくさん入手することです。 NASに加えて、iSCSIを介してS3やその他のバケット/コンテナにアクセスできるソフトウェアツールもあります。
このリンクは、2つの違いを説明しています。 http://www.Dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf
このホワイトペーパーはオブジェクトストレージのアイデアを非常によく説明していると思います。ユーザーアプリケーションから（SCSI OSDの意味で）オブジェクトストレージデバイスを使用する標準的な方法を知りません。
オブジェクトストレージは、 Panasas のストレージアプライアンスなどの一部の大規模ストレージ製品で使用されています。ただし、これらのアプライアンスはファイルシステムをエンドユーザーにエクスポートします。 T10 OSDのアイデアが実際に勢いをとらなかったと言うのは私見です。
OSD標準に関連するアイデアは、 S や [〜＃〜] rados [〜＃〜] などのクラウドストレージシステムにあります。
読む価値のある良い記事を次に示します。 https://cloudian.com/blog/object-storage-vs-file-storage/ 記事から引用：
まず、オブジェクトストレージは、ファイルストレージが直面する多くの制限を克服します。ファイルストレージは倉庫と考えてください。最初にファイルのボックスをそこに入れたとき、十分なスペースがあるようです。しかし、データのニーズが大きくなると、気付かないうちにウェアハウスをいっぱいにしてしまいます。一方、オブジェクトストレージは、屋根がないことを除き、倉庫のようなものです。データを無限に追加し続けることができます。空が限界です。主に小さいファイルや個々のファイルを取得する場合、特に比較的データ量が少ない場合、ファイルストレージはパフォーマンスに優れています。ただし、スケーリングを開始すると、「必要なファイルをどのように見つけることができますか？」この場合、オブジェクトストレージは係員付き駐車場と考えることができますが、ファイルストレージはセルフパーキングに似ています（はい、もう1つの例えですが、私に耐えてください！）。車を小ロットに引き込むと、車がどこにあるかを正確に把握できます。しかし、そのロットが千倍大きかったと想像してください-あなたの車を見つけるのは難しいでしょう？オブジェクトストレージにはカスタマイズ可能なメタデータがあり、すべてのオブジェクトはフラットなアドレス空間に存在するため、鍵をバレットに引き渡すことに似ています。あなたの車はどこかに保管され、あなたがそれを必要とするとき、バレットはあなたのために車を手に入れます。車を取り戻すのに少し時間がかかるかもしれませんが、探し回る心配をする必要はありません。