LAMPオンラインストアを開発しています。これにより、管理者はアイテムごとに複数の画像をアップロードできます。
私の懸念は-すぐに20000個のアイテムがあり、約60000個の画像があることです。
質問:
Linuxのファイルやディレクトリの最大数はいくつですか?
この状況に対処する通常の方法は何ですか(ベストプラクティス)。
私のアイデアは、一意のIDに基づいて各アイテムのディレクトリを作成することでしたが、メインのploadsディレクトリにはまだ20000個のディレクトリがあり、古いアイテムが無期限に成長するため除去される。
助けてくれてありがとう。
ext [234]ファイルシステムでは、iノードの最大数が固定されています。すべてのファイルまたはディレクトリには1つのiノードが必要です。 df -i
で現在のカウントと制限を確認できます。たとえば、デフォルト設定で作成された15GB ext3ファイルシステムでは:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda 1933312 134815 1798497 7% /
これ以上のディレクトリには特に制限はありません。ただし、すべてのファイルまたはディレクトリには少なくとも1つのファイルシステムブロック(通常は4KB)が必要であることに注意してください。ただし、ディレクトリが1つのアイテムのみで構成されている場合も同様です。
ただし、ご覧のとおり、80,000個のiノードが問題になることはほとんどありません。 dir_index
オプション(tune2fs
で有効化)を使用すると、大きなディレクトリでのルックアップは大したことではありません。ただし、多くの管理ツール(ls
やrm
など)は、ファイルが多すぎるディレクトリを扱うのに苦労する可能性があることに注意してください。そのため、ファイルを分割して、特定のディレクトリに数百から数千を超えるアイテムが含まれないようにすることをお勧めします。これを行う簡単な方法は、使用しているIDをハッシュ化し、最初の数桁の16進数を中間ディレクトリとして使用することです。
たとえば、アイテムID 12345があり、'DEADBEEF02842.......'
へのハッシュがあるとします。 /storage/root/d/e/12345
の下にファイルを保存できます。これで、各ディレクトリのファイル数が1/256に削減されました。
サーバーのファイルシステムで_dir_index
_機能がオンになっている場合(機能のチェックとオンの詳細についてはtune2fs(8)
を参照)、パフォーマンスが低下する前に100,000個以上のファイルをディレクトリに合理的に保存できます。 (_dir_index
_は、数年前からほとんどのディストリビューションで新しいファイルシステムのデフォルトでした。したがって、デフォルトではこの機能を持たないoldファイルシステムのみです。)
ただし、ディレクトリ内のファイル数を16または256分の1に減らすために別のディレクトリレベルを追加すると、カーネルの最大サイズargv
をオーバーランさせずに_ls *
_などの動作が大幅に向上する可能性があります。
通常、これは次のような方法で行われます。
_/a/a1111
/a/a1112
...
/b/b1111
...
/c/c6565
...
_
つまり、名前から計算できる機能に基づいて、パスに文字または数字を追加します。 (ファイル名の_md5sum
_または_sha1sum
_の最初の2文字は1つの一般的なアプローチですが、一意のオブジェクトIDがある場合は、_'a'+ id % 16
_を使用するディレクトリを簡単に決定できます)
60000は何もありません、20000も同様です。ただし、これらへのアクセスを高速化するために、これらの20000を何らかの方法でグループ化する必要があります。ディレクトリの番号を取得し、それを100、500、1000などで割ることにより、100または1000のグループになります。
たとえば、ファイルに番号があるプロジェクトがあります。私はそれらを1000年代にグループ化しますので、
id/1/1332
id/3/3256
id/12/12334
id/350/350934
実際にはハード制限がある場合があります-一部のシステムには32ビットのiノードがあるため、ファイルシステムごとに2 ^ 32の数に制限されます。
一般的な回答に加えて(基本的には「それほど気にしない」、「ファイルシステムを調整する」、「それぞれ数千個のファイルを含むサブディレクトリでディレクトリを整理する」):
個々の画像が小さい場合(数キロバイト未満など)、フォルダに入れる代わりに、データベースに入れることもできます(MySQLで [〜#〜] blob [〜# 〜] )またはおそらく [〜#〜] gdbm [〜#〜] インデックス付きファイル内。その場合、小さなアイテムはそれぞれiノードを消費しません(多くのファイルシステムでは、各iノードは少なくとも数キロバイトを必要とします)。いくつかのしきい値でそれを行うこともできます(たとえば、4kバイトより大きい画像を個々のファイルに入れ、小さい画像をデータベースまたはGDBMファイルに入れます)。もちろん、データのバックアップを忘れないでください(そしてバックアップの状態を定義してください)。
年は2014年です。この回答を追加するために、私は時間をさかのぼります。大小のファイルがたくさんありますか? Amazon S3およびDreamObjectsのようなCephに基づくその他の代替手段を使用できます。この場合、ディレクトリの制限はありません。
これが誰かがすべての選択肢から決定するのに役立つことを願っています。