現在までに30,000以上のファイルと20GB以上のこのようなシステムが大量生産されています...
Column | Type | Modifiers
-------------+-----------------------------+----------------------------------------------------------
File_ID | integer | not null default nextval('"ACRM"."File_pseq"'::regclass)
CreateDate | timestamp(6) with time zone | not null default now()
FileName | character varying(255) | not null default NULL::character varying
ContentType | character varying(128) | not null default NULL::character varying
Size | integer | not null
Hash | character varying(40) | not null
Indexes:
"File_pkey" PRIMARY KEY, btree ("File_ID")
ファイルは、ファイル名として整数File_IDを使用して単一のディレクトリに保存されます。私たちは問題なく30,000を超えています。私は問題なくより高くテストしました。
これは、ファイルシステムとしてext3を備えたRHEL5x86_64を使用しています。
もう一度このようにしますか？いいえ。再設計についていくつか考えさせてください。
-
データベースは依然としてファイルに関する情報の「マスターソース」です。
-
各ファイルはsha1（）ハッシュされ、そのハッシュに基づいてファイルシステム階層に保存されます：
/FileData/ab/cd/abcd4548293827394723984723432987.jpg -
データベースは、各ファイルにメタ情報を保存することに関して少し賢いです。これは3つのテーブルシステムになります：
File：名前、日付、IP、所有者、Blob（sha1）へのポインターなどの情報を格納します
File_Meta：ファイルのタイプに応じて、キーと値のペアをファイルに保存します。これには、Image_Widthなどの情報が含まれる場合があります...
Blob：sha1への参照とそのサイズを格納します。
このシステムは、ハッシュによって参照されるデータを保存することにより、ファイルの内容を重複排除します（複数のファイルが同じファイルデータを参照する可能性があります）。 rsyncを使用してファイルデータベースをバックアップ同期するのは非常に簡単です。
また、多くのファイルを含む特定のディレクトリの制限がなくなります。
ファイル拡張子は、一意のファイルハッシュの一部として保存されます。たとえば、空のファイルのハッシュがabcd8765の場合 ...空の.txt ファイルと空の.php ファイルは同じハッシュを参照します。むしろ、abcd8765.phpを参照する必要があります およびabcd8765.txt 。なぜですか？
Apacheなどは、ファイル拡張子に基づいてコンテンツタイプとキャッシュルールを自動的に選択するように構成できます。有効な名前とファイルの内容を反映する拡張子でファイルを保存することが重要です。
ご覧のとおり、このシステムはnginxを介してファイル配信を委任することで、パフォーマンスを大幅に向上させることができます。 http://wiki.nginx.org/XSendfile を参照してください 。
これが何らかの形で役立つことを願っています。気をつけて。