S3プレフィックスが正確に何であるか、そしてそれがAmazonのプレフィックスとどのように相互作用するかを知っている人はいるだろうかと思いました。公開された S3 レート制限:
Amazon S3 は、高いリクエストレートに合わせて自動的にスケールします。たとえば、アプリケーションはバケット内のプレフィックスごとに 1 秒あたり少なくとも 3,500 件の PUT/POST/DELETE リクエストと 5,500 件の GET リクエストを達成できます。バケット内のプレフィックスの数に制限はありません。
それは非常に明確ですが、プレフィックスとは何なのかよくわかりません。
プレフィックスには区切り文字が必要ですか?
すべてのファイルを「ルート」レベル（完全にフラットで、プレフィックスや区切り文字がない）に保存するバケットがある場合、それは単一の「プレフィックス」としてカウントされ、上記のレート制限の対象になりますか？
私の解釈の仕方アマゾンのドキュメントこれは事実であり、フラット構造は単一の「プレフィックス」と見なされると思われます。(つまり、上記の公開されたレート制限の対象となります)
バケット (管理者が作成) に次のオブジェクト キーを持つ 4 つのオブジェクトがあるとします。
開発/プロジェクト1.xls
財務/ステートメント1.pdf
プライベート/税務書類.pdf
s3-dg.pdf
s3-dg.pdf キーにはプレフィックスがないため、そのオブジェクトはバケットのルート レベルに直接表示されます。Development/ フォルダを開くと、その中に Projects.xlsx オブジェクトが表示されます。
上記の例では、s3-dg.pdf は、他の各プレフィックス (Development/Finance/Private) とは異なるレート制限 (5500 GET リクエスト/秒) の対象になりますか?
さらに混乱しているのは、Amazon が最初の N バイトをパーティション キーとして使用し、高カーディナリティ プレフィックスの使用を推奨しているというブログをいくつか読んだのですが、それが「フラット ファイル構造」のバケットとどのように相互作用するのかよくわからないことです。
ベストアンサー1
おっしゃる通り、発表内容は矛盾しているようです。正しく書かれていないだけで、情報は正しいです。要するに、
- 各プレフィックスは1秒あたり最大3,500/5,500リクエストを達成できるため、多くの目的において予測複数のプレフィックスを使用する必要がないことです。
- プレフィックスは、オブジェクトの場所のパス全体 (最後の '/' まで) と見なされ、最初の 6 ～ 8 文字のみでハッシュ化されなくなりました。したがって、1 秒あたりの最大リクエスト数を 2 倍にするには、任意の 2 つの「フォルダー」間でデータを分割するだけで十分です。(リクエストが 2 つに均等に分割されている場合)
参考までに、私の説明要求に対する AWS サポートからの回答を以下に示します。
こんにちは、オーレン。
AWS サポートにお問い合わせいただきありがとうございます。
S3 リクエスト レートのパフォーマンスが向上しているという AWS の投稿をお読みになり、この発表に関して追加の質問があるとのことですが、
このアップグレードの前は、S3 は 1 秒あたり 100 件の PUT/LIST/DELETE リクエストと 1 秒あたり 300 件の GET リクエストをサポートしていました。より高いパフォーマンスを実現するには、ランダム ハッシュ/プレフィックス スキーマを実装する必要がありました。昨年から、リクエスト レート制限は 1 秒あたり 3,500 件の PUT/POST/DELETE リクエストと 5,500 件の GET リクエストに増加しました。この増加は、多くの場合、プレフィックスをランダム化することなく、アプリケーションが 503 SlowDown エラーを軽減するのに十分です。
ただし、新しい制限が十分でない場合は、プレフィックスを使用する必要があります。プレフィックスの文字数は固定ではありません。プレフィックスは、バケット名とオブジェクト名の間にある任意の文字列です。例:
- バケット/フォルダ1/サブ1/ファイル
- バケット/フォルダ1/サブ2/ファイル
- バケット/1/ファイル
- バケット/2/ファイル
オブジェクト「file」のプレフィックスは、、、、になります
/folder1/sub1/。/folder1/sub2/この/1/例/2/では、読み取りを 4 つのプレフィックスすべてに均等に分散すると、1 秒あたり 22,000 件のリクエストを達成できます。