3

ユーザーがファイルをアップロードおよびダウンロードできるようにするデータベース アプリケーションを作成しています。ファイルはファイル サーバーに保存され、ファイルを処理 (つまり、アップロードとダウンロード) するための PHP スクリプトを使用して Apache HTTP サーバーをセットアップしました。データベースには、ファイル自体ではなく、ファイルへのリンクのみが保存されます。私の質問は次のとおりです。ファイル サーバー上のファイルをどのように整理すればよいですか?

現在、現在の日付に基づいてディレクトリ構造を作成しており、現在の日付/時刻 (ミリ秒を含む) の MD5 ハッシュといくつかのランダムな文字を使用してファイルの名前を変更しています (つまり、「塩」を追加しています)。

\\yyyy\mm\dd\debb40da158040e4f3b93f9576840c07

これ (上記) はデータベースに保存されているリンクです (もちろん、ユーザーがファイルをダウンロードするときにファイルの名前を変更できるように、実際のファイル名もデータベースに保存しています。ユーザーは実際のファイルを見ることはありません。リンク）。

パフォーマンスの問題を回避するためにディレクトリ構造に使用yyyy\mm\ddし (同じディレクトリに多くのファイルがあると速度が低下する可能性があると言われています)、ファイルの名前を一意の文字列に変更して、ユーザーが同じ名前のファイルをアップロードするときの衝突を回避します。

この種の状況でファイルを保存する最善の方法について、他の意見を求めたいと思います。一部の開発者がファイル名を保持しているのを見てきましたが、ファイル情報テーブルの対応する行のデータベース ID を (接頭辞として) 追加しています。データベースファイル情報テーブルが破損または削除された場合、ファイルが何であるかを把握できます。

4

1 に答える 1

3

タイムスタンプ（アップロード日）を第1レベルのディレクトリとして使用し、ファイルの内容のmd5ハッシュを第2レベルとして使用する構造（ファイルの内容のハッシュにより、ファイルが一意であるか名前に依存しないことを保証します）、タイムスタンプを第3レベルとしてアップロードする（同じファイルの異なるバージョンを異なる時間にアップロードするため）、および第4レベルの実際のファイル名を持つファイル。e.g. <date timestamp>/<md5 of file contents>/<timestamp>/<filename>

このようにして、dir構造には次の情報が含まれます。

  • 特定の日にアップロードされたファイルのリスト
  • ファイル名に依存しない一意のファイル
  • バージョニング
  • その場でファイル名を変更する必要なしにファイル名を維持する

ファイルの内容がmd5ハッシュの場合の欠点は、ファイルが非常に大きい場合、生成にわずかなオーバーヘッドが発生することです。

さらなるアイデア

  • これが毎日ファイルをアップロードする多くのユーザーがいて、1年の各日に365のdirを作成することが確実なシステムである場合は、以前の形式（yyyy / mm/ddまたは単にyyyy/date）として日付を分割できます。ディレクトリに10kを超えるエントリのリストがある場合（およびサーバーベースのOSでは100kを超えて数百万まで）、パフォーマンスが低下しますが、低下に気付くまでに約25〜30年かかるはずです。単一の日付ディレクトリで移動します。

  • ファイルの内容のハッシュは、ファイル名の独立性を保証するための方法であり、内容のmd5を計算するための小さなオーバーヘッドが追加されますが、アップロード時間と比較すると取るに足らないものです。たとえば、100 mbのファイルは、接続速度に応じてアップロードにx時間かかります。アップロード後、md5sumを使用してファイルの内容をその場で計算するだけで、数秒追加されます（100 mbファイルの場合は5〜6） ）ユーザーが認識するアップロード時間まで。

  • さらに、ファイルの内容のmd5を（データベースにも保存していると仮定して）最初にアップロードされたファイルの信頼性を保護する署名として使用できます。

  • ファイルのバージョン管理が必要な場合、または異なる名前の同じファイルがアップロードされていないことを保証する場合を除いて、現在のシナリオのコンテキストでは、dir構造にタイムスタンプ（+ salt）は実際には必要ありません（そうしないと、最終的には同じファイルの内容の下に異なるファイル名を持つmd5は、指定された日のdirという名前です）。

  • md5文字列の長さを気にする理由がわかりません。パフォーマンスに影響を与えることはなく、md5はかなり普及しており、他の目的（ファイルの検証など）でも使用できるようにサポートされています。しかし、本当に長さを減らしたい場合は、http：//en.wikipedia.org/wiki/List_of_hash_functionsを見て、16ビットまたは8ビット、さらには4ビットのcrcを選択して実験してください（これも、どのように行っているかによって異なります）。それを使用するには、ファイルの内容またはファイル名とそれらの大きさ）。

  • 最後に、別の方法は<group>/<user_id>/<filehash>/<timestamp>/<filename>、グループがユーザーID1から<acceptable number of entries in a dir>たとえば、10000以下ですが、これは、サーバーでパフォーマンスを低下させるエントリの数を実験することで見つけることができます。制限に達すると、同じ構造の新しいグループを作成するスクリプトが作成されます。このようにして、繰り返し/類似の情報（日付、年、月、タイムスタンプなど）を回避し、許容可能な制限を自分で制御し、同じファイルを異なるユーザーがアップロードできるようにし、ファイルがファイルされているかどうかを通知するファイルハッシュを取得しますファイル名に関係なくアップロードされ、タイムスタンプを使用してバージョン管理が行われ、元の（または指定された）名前のファイルが終了ディレクトリに1つだけ取得されました。あなたがFaceBookであり、10億人のユーザーがいる場合、この構造を持ち、異なるサーバー間でディレクトリのグループのクラスターをホストすることができます。たとえば1000人のユーザーがいる小さなWebサイトがある場合は、グループビットも必要ありません。

于 2012-10-15T21:27:54.230 に答える