4

多数のキーを含む S3 バケットでは、REST API を介してキーを一覧表示するプロセスが非常に遅くなります。

  1. 一度にリストできるキーは 1000 個までです。
  2. (私が知る限り) 5001 番目のキーを特定する唯一の方法は、最初の 1000 個のキーをリストし、応答の次のマーカーに基づいて次のキーをリストし、5001 に到達するまで再帰することです。
  3. S3 REST API リクエストのレイテンシーは非常に高く、通常、1000 個のキーのリクエストには数秒かかります。

100 個の同時キー リスト REST 要求を作成しても個々の要求が遅くなることはないため、そうでなければ、このプロセスは並列化による最適化の機が熟します。しかし、私のアルゴリズムが「愚か」で、可能なキースペースを事前定義されたマーカーに分割するだけの場合 (たとえば、「」、「a」、「b」、「c」、「d」、「e」... ) すべてのキーが「images/」で始まるバケット内のキーの一覧表示は、実際には高速化されません。

したがって、S3 を実際に使用した経験のある人が、バケットのキー スペースをトラバースするより良い方法を知っているかどうか、または同時実行によるキー リストを改善するための適応型 (つまり、「愚かではない」) アルゴリズムを試したことがあるかどうか疑問に思っています。

4

1 に答える 1

1

おそらく、「バイナリ検索」アルゴリズムの何らかの形式が役立つでしょうか? EG は '' と 'm' のプレフィックスで始まり、途中までなどです。最終的に各キーを取得するのはせいぜい 2 回程度になると思います。'nextmarker' が既にある場合は、それ以上のキーを要求するのをやめます。

開始する数を選択するにはどうすればよいですか? おそらく各サイクルで細分化すると思います: '' を起動し、これらの結果が戻ってきたら、 '' 結果がさらに多くのキーを示している場合は、その検索で 'nextmarker' を起動し、さらに 'nextmarker' と 'z' の中間で新しい検索を起動します。 . 繰り返す。ハッシュのようなものを使用して、すべてのキーを一度だけ保存します。

すべてのリクエストが異なるスレッドなどで受信されるため、すべてのキーを追加するにはロックが必要になります。次に、そのロックを開いたままにして速度を落とさないようにするという問題があるため、使用している言語などによって異なります。

プロセスが S3 ファイルと同じリージョンの EC2 インスタンスで実行されている場合は、より高速に実行できる可能性があります。ファイルが米国の「標準」にあるとします。運が良ければ、Ruby と Ironworker のようなものを使用してそこにアクセスし、すべてのキーをダウンロードできます。完了すると、サーバーに投稿したり、すべてのキーのリストであるファイルを S3 上に作成したりできます。地域や言語によっては、独自の EC2 インスタンスを起動する必要がある場合があります。

EC2 インスタンスでは、リクエストごとに多くの帯域幅 (EC2 では料金が発生しません) があるため、S3 キーの一覧表示がはるかに高速であることがわかりました。S3 は非常にふわふわした XML である応答を gzip しません。そのため、ユーザーと S3 の間の帯域幅が重要です。

于 2012-01-10T14:02:50.863 に答える