まず、以前の回答と会話から、問題が発生するまで、何十億もの行について心配する必要はありません。まったく新しいサービスを設計しているだけの場合は、何十億もの画像をすぐに管理する方法について心配する必要はないでしょう。数十億のファイルを処理できる高可用性、低遅延のサービスに対処しようとすることは、世界の最高のエンジニアの一部が設計と実装に何年もかかる可能性がある設計上の課題です。
おそらく、数桁低い焦点を当てて、数百万または数千万のレコード、または今後1、2年で管理する必要のある現実的なレベルのオブジェクトをどのように処理するかを考えてください。この場合、たとえば、適切に設計されたインデックスを使用したMySQLインストールで、応答パターンが良好で、頻繁に要求されるキャッシュをキャッシュできる場合は特に、応答時間が長い数百万行のテーブルに対するクエリを処理できない理由はありません。ファイルメタデータ。
リレーショナルデータベースがファイルメタデータを格納するための最良の方法であるかどうかに関しては、実際には、格納するデータの階層とアクセスパターン(つまり、データの検索方法)によって異なります。 )。あなたは、ファイルがどのように編成されるかについての非常に基本的な例を示し、各画像が複数の解像度で保存される組織構造があるかもしれないことを提案しました。
アプリケーションは、画像のすべての解像度オプションを理解し、いくつかの基準に基づいて提供するのに最適なものを決定する必要がありますか、それとも取得しようとしている正確な画像を常に知っていますか?
最初のケースでは、メタデータにNoSQLタイプのストレージが必要な場合があります。これにより、画像グループを検索し、アプリケーションロジックを使用して、グループから最適な画像ファイルを選択できます。後者の場合、ファイルメタデータを取得するために、リレーショナルデータベース、またはSimpleDBなどの高可用性キーバリューストアを使用する方が適切な場合があります。
また、実際に画像を提供することに関しては、Cloudfrontを実際に使用してS3ファイルを提供することを検討することをお勧めします。これにより、レイテンシーの利点も得られます。
S3の「フォルダー」に関する質問に関しては、S3には実際にはフォルダーがないことを理解することが重要です。人々は一般に、バケット内のファイルの階層的なグループ化を提案するために、フォルダのような命名スキームでファイルに名前を付けていますが、実際には、物理的なディレクトリ構造も、ディレクトリ構造に通常関連付けられていること(すべてのファイルをリストするなど)を実行する機能もありません。ディレクトリ)。すべてのファイルはバケットレベルでのみ存在します。
次のfiles
表があります(SQLまたはバリアントを使用している場合)。
file_id folder_id file_path
1 1 http://s3.aws.amazon.com/my-bucket/folder1/img1a.jpg
2 1 http://s3.aws.amazon.com/my-bucket/folder1/img1b.jpg
3 2 http://s3.aws.amazon.com/my-bucket/folder2/img2a.jpg
4 2 http://s3.aws.amazon.com/my-bucket/folder2/img2b.jpg
ここで、file_idは自動インクリメントフィールドを持つ主キーであり、folder_idはインデックスを持つint列であり、特定のフォルダー内のすべてのファイルを簡単に検索する方法を提供します。