あなたはTwitterのようなソーシャルネットワーキングサイト上のプロファイルの絵を見たとき、彼らは次のように画像ファイルを保存：クラウドストレージ/ CDNのファイル名をランダム化するのはなぜですか？
http://a1.twimg.com/profile_images/1082228637/a-smile_twitter_100.jpg
、あるいはどこかに私は考えることができる20110912.のみ直接的な利益のようなパスの日付のボットがあなたのストレージ内のすべてのファイルを直線的に流してダウンロードすることを防ぎます。他のメリットがありませんか？それをランダム化する最良の方法は何ですか？
私はAmazon S3を使用しているので、すべての静的コンテンツを1つのサブドメインに配信します。私の計画では、データベースに整数のIDを格納してから、URLをIDと連結して位置を形成するだけでした。
パブリックURLの識別子を暗号的にスクランブルする理由の1つは、ビジネスの成長率が常に公開されるわけではないということです。
新しいユーザーアカウントを作成するか画像をアップロードするだけで現在のIDを推測することができれば、外部のユーザーはこれを定期的に実行してIDの数を確認することで成長率（または上限）を計算できます経過時間中に使用した。
競合他社やビジネスアナリストが自力で推論できるようにする代わりに、情報が急激に増加しているかどうかにかかわらず、この情報のリリースを制御できるようにしたいと考えています。
オフラインの例は、請求書と小切手の番号です。あなたが定期的に請求を受けるか、会社から支払いを受けると、その期間に何通の請求書や小切手が書かれているかを見ることができます。
それはで書かれSkip32アルゴリズムの直接の翻訳です：
はここでカツオに基づいて2つの方法で暗号化を使用して32ビットのIDをスクランブル私は維持CPAN（Perlの）モジュールですグレッグ・ローズによってC：
このアプローチを使用すると、各32ビットIDが元のIDに戻すことができる（事実上ランダムな）対応する32ビット番号にマップされます。データベースに余分なものを保存する必要はありません。
URLに表示するために、スクランブルされたIDを8桁の16進数に変換します。
idsが429億（32ビット）に近づくと、さらに多くのURLをサポートするようにURL構造を拡張する必要がありますが、できるだけ短いURLを使用するのが好きです。
主に、名前の衝突を防止します。たとえば、複数の人が「IMG_0001.JPG」をアップロードすることがあります。また、1つのディレクトリ内のファイル数の制限を避け、複数のサーバーに画像を分割することもできます。TwitterやFacebookなどの巨大なサイトでは、
私はあなたが何を意味するのか理解していますが、TwitterはAmazon S3を使用しているので、サーバやディレクトリのコンセプトについて心配する必要はありません。 1つのディレクトリに1兆個のオブジェクトを格納することができ、それを心配する必要はありません。私の場合は、S3で対応するファイル名として機能するために、MySQLで自動インクリメント整数列を使用していますので、名前の衝突は問題ではありません。ボットがすべてのファイルを体系的にダウンロードするのを防ぐ良い方法があると思いますか？ – Adam
彼らは特定のディレクトリを探しているディレクトリにファイルをリストしたいのであれば、心配する必要はありません。 – ceejayoz
他の場所（データベース、JSONドキュメントなど）のファイルの場所に関するメタデータを格納する必要があります。私はTwitterがAmazon S3を使用しているという事実を知っています。もし本当にしたいのなら、彼らはa1.twimg.com/*の下にすべての画像を保存することができます。 Amazonのクラウドはハードウェアを扱うので、ディレクトリレベルで考える必要はありません。私は特にS3について質問しているので、シャーディングとクラスタリングはこの場合問題ではありません。 – Adam
URLを変更すると、古くなったアセットを無効にすることができます。
プライベート画像を保存するユーザーに許可する必要がある場合もあります。ユーザーのアカウント名/ ID /パスからのパス控除を使用すると、CDNにアセットを保存するとすぐにプライバシー設定が役に立たなくなります。
私はこの考え方が好きです。私は自分のid生成戦略を考え直さなければならないだろう。 – Adam