100 万枚の画像がある場合、それらをフォルダー/サブフォルダー階層に保存するか、すべてを直接バケットに (フォルダーなしで) ダンプする方がよいでしょうか?
すべての画像を階層のないバケットにダンプすると、LIST 操作が遅くなりますか?
その場でフォルダーとサブフォルダーを作成し、それらの ACL を設定する (プログラム的に言えば) 際に大きなオーバーヘッドはありますか?
100 万枚の画像がある場合、それらをフォルダー/サブフォルダー階層に保存するか、すべてを直接バケットに (フォルダーなしで) ダンプする方がよいでしょうか?
すべての画像を階層のないバケットにダンプすると、LIST 操作が遅くなりますか?
その場でフォルダーとサブフォルダーを作成し、それらの ACL を設定する (プログラム的に言えば) 際に大きなオーバーヘッドはありますか?
S3 は階層的な名前空間を尊重しません。各バケットには、キーからオブジェクトへの多数のマッピング (関連するメタデータ、ACL などと共に) が含まれているだけです。
オブジェクトのキーに「/」が含まれている場合でも、S3 はパスをプレーンな文字列として扱い、すべてのオブジェクトをフラットな名前空間に配置します。
私の経験では、オブジェクトの数が増えると LIST 操作に (直線的に) 時間がかかりますが、これはおそらく、Amazon サーバーで必要な I/O が増加し、クライアントにつながる兆候です。
ただし、ルックアップ時間はオブジェクト数によって増加するようには見えません - それはおそらく最終的にある種の O(1) ハッシュテーブル実装です - したがって、同じバケットに多くのオブジェクトを持つことは、通常の使用では小さなバケットと同じくらいパフォーマンスが良いはずです (つまりリストではありません)。
ACL に関しては、付与はバケットと個々のオブジェクトごとに設定できます。階層がないため、選択肢は 2 つしかありません。明らかに、何百万ものファイルがある場合、バケット全体の許可をできるだけ多く設定すると、管理者の頭痛の種が大幅に軽減されますが、権限を付与することしかできず、それらを取り消すことはできないことに注意してください。したがって、バケット全体の許可は、すべての ACL の最大のサブセットにする必要があります。その内容。
次の場合は、個別のバケットに分割することをお勧めします。
元の質問「S3 のディレクトリあたりの最大ファイル数」に対する回答は、無制限です。バケット内のオブジェクトに対する S3 制限も参照してください。
ルートと少なくとも 1 つのサブディレクトリを含むディレクトリ構造を使用します。ルート下のディレクトリとして「ドキュメントのインポート日」をよく使用します。これにより、バックアップの管理が少し簡単になります。使用しているファイル システムが何であれ、最終的にはファイル数の制限 (物理的な制限ではないにしても実用的な制限) に達することになります。複数のルートをサポートすることも考えられるかもしれません。