0

わかりました、ある種の共有システム/サービスを開発中です。人々が独自のメディアをサーバーにアップロードできる場所。ビルドの大部分に PHP と mySQL を使用しており、現在は単一サーバー環境を使用しています。ただし、サイト/サービスを独自のサーバーに残して、今後6か月でメディアをサーバーのクラスターに移動する予定であるため、これをスケーラブルにする必要があります. とにかくそれはミュートポイントです。

私の目標、または希望は、アップロード時にファイルの名前を変更するときに別のファイルと衝突する可能性がほとんどない、非常にリスクの低い命名規則を考え出すことです。私はこれまでに多くの概念を読んできましたが、UUID (GUID) は私のすべてのニーズに最適な候補であることがわかりました。その可能性が非常に高いため、これまでに多くの共有イメージに到達できるとは思えませんでした。

私の問題は、UUID に適した v3 または v5 を生成する関数を考え出すことです (それらは同じであることは理解していますが、v5 は現在 UUID の標準に 100% 準拠していません)。UUIDとその制約についてほとんど知らないと、後で必要に応じて正規表現を試みるときに、それらを一意または有効にすることができます。実行可能な解決策を思い付くことができないようです。また、v3 と v5 のどちらを使用する必要があるかもわかりません。またはそのことについてはv4。そのため、目的のバージョンの UUID タイプを返す関数に関するアドバイスとヘルプを探しています。

今のところどこから始めればよいかわからないので、まだ何も試していません。そのため、これらのファイルを多くのフォルダーに保存して、大きなディレクトリ リストによる負荷を相殺するつもりです。そのため、衝突のリスクも軽減しています。また、これらの名前を DB に保存し、関連付けられたフォルダーやその他の情報を各画像に関連付けているため、名前を変更するファイルの UUID をランダムに生成するときに発生する別の問題があります。複数の DB にクエリを実行したくありません。そのため、実際には関数呼び出しごとにおそらく 5 つの UUID を返し、クエリに一致するものがあるかどうかを確認し、一致しない最初のものを悪用することをお勧めします。

とにかく、私はこれがたくさんの読書であることを知っています、私はそれにコードがないことを知っています、うまくいけば、あなたの多くが投票に終わらないことを願っています。最初からこれに取り組む方法を真剣に知りたいので、できるだけ手間をかけずに必要に応じてスケールアップできるようにします。

4

2 に答える 2

1

私の目標、または希望は、アップロード時にファイルの名前を変更するときに別のファイルと衝突する可能性がほとんどない、非常にリスクの低い命名規則を考え出すことです。私はこれまでに多くの概念を読んできましたが、UUID (GUID) は非常に多くの可能性を秘めているため、私のすべてのニーズに最適な候補であることがわかりました。

以下で構成される番号を作成できます (UUID として実装します)。

  • 日付 (YYYYMMDD)
  • サーバー (NNN)
  • その日にそのサーバーにアップロードされた画像のカウンター

この数は常に増加するため、競合が発生することはなく、最大 1,000 サーバーまで拡張できます。各サーバーで 1 日あたり最大 100 万枚の画像を取得するとします。これは約 43 ビットの情報です。UUID が推測されないように、他の 32 のランダム性を追加します (平均で 2^31 回未満の試行で)。さらにスケーリングできるように、50 奇数ビットが残っています。

または、数字を BCD に保存して、人間が読めるようにすることもできます。

20120917-0172-4123-8456-7890d0b931b9

画像 1234567890、ランダム d0b931b9、2012 年 9 月 17 日にサーバー 0172 にアップロードされた可能性があります。

スキームは、「ディレクトリ拡散」スキームとしても機能する可能性があります。画像に、たとえば 20120917-125-00001827-d0b931b9 にマップされる UUID があると、それはサーバー 125 を意味し、d0/b9 と呼ばれるディレクトリ構造に保存できます。 /31/b9/20120917-125-00001827.jpg.

命名規則によって一意性が保証され、ランダム ビットによってディレクトリ構造が「フラット」 (他のディレクトリよりもいっぱいになるディレクトリがなく、均等にいっぱいになる) であることが保証され、取得時間が最適化されます。

于 2012-09-17T22:36:04.607 に答える
1

auto_incrementいずれにせよ、データベース内の各ファイルへの参照を保存する場合は、MySQL ID を使用してファイルに名前を付けないのはなぜですか? DB をクラスターにスケーリングしても、ID は依然として一意です (PK であるため、一意である必要があります!)。UUID の生成などで貴重な CPU 時間を無駄にする必要はありません。これは UUID の目的ではありません。

私は最も簡単な方法を選びます(ただし、他の多くのシステムでそれを見てきました):

  1. ファイルをアップロードする
  2. アップロードが成功したら、DB 参照を挿入します (パスは によって決定され3.ます)。フェッチauto_incrementする$ID
  3. ファイルの名前を変更します${YEAR}/{$MONTH}/${DAY}/{$ID}
    (1日にアップロードされるファイルが多すぎる場合、より細かいパスが必要な場合は調整してください)
  4. 名前の変更に失敗した場合、DB 参照を削除してエラー メッセージを表示する
  5. ファイルシステム内の実際の実際のパスでDB参照を更新します
于 2012-09-17T22:36:35.190 に答える