60000 は何でもなく、20000 も同様です。しかし、それらへのアクセスを高速化するために、これらの 20000 をグループ化する必要があります。おそらく、ディレクトリの数を 100、500、1000 などで割ることによって、100 または 1000 のグループになります。
たとえば、ファイルに番号が付いているプロジェクトがあります。それらを 1000 単位でグループ化するので、
id/1/1332
id/3/3256
id/12/12334
id/350/350934
実際には厳しい制限があるかもしれません - 一部のシステムには 32 ビットの inode があるため、ファイル システムあたりの数は 2^32 に制限されています。
サーバーのファイルシステムに dir_index がある場合 機能がオンになっている (tune2fs(8) を参照) 機能の確認と有効化の詳細については、1 つのディレクトリに 100,000 個以上のファイルを保存しても、パフォーマンスが低下することはありません。 (dir_index 数年前からほとんどのディストリビューションで新しいファイルシステムのデフォルトになっているため、古いに過ぎません。 デフォルトではこの機能がオンになっていないファイルシステムです。)
とはいえ、別のディレクトリ レベルを追加してディレクトリ内のファイル数を 16 分の 1 または 256 分の 1 に減らすと、ls * のような可能性が大幅に向上します。 カーネルの最大 argv をオーバーランすることなく動作 サイズ。
通常、これは次のような方法で行われます:
/a/a1111
/a/a1112
...
/b/b1111
...
/c/c6565
...
つまり、名前から計算できるいくつかの機能に基づいて、文字または数字をパスに追加します。 (md5sum の最初の 2 文字 または sha1sum ファイル名の変更は一般的なアプローチの 1 つですが、一意のオブジェクト ID がある場合は 'a'+ id % 16 使用するディレクトリを決定するのに十分簡単なメカニズムです。)
ext[234] ファイルシステムには、inode の最大数が固定されています。すべてのファイルまたはディレクトリには、1 つの inode が必要です。 df -i で現在のカウントと制限を確認できます .たとえば、デフォルト設定で作成された 15 GB の ext3 ファイルシステムの場合:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda 1933312 134815 1798497 7% /
これを超えるディレクトリには特に制限はありません。ただし、アイテムが 1 つしかないディレクトリであっても、すべてのファイルまたはディレクトリには少なくとも 1 つのファイル システム ブロック (通常は 4KB) が必要であることに注意してください。
ただし、ご覧のとおり、80,000 個の inode が問題になる可能性はほとんどありません。そして dir_index で オプション (tune2fs で有効化) ）、大きなディレクトリの検索はそれほど大したことではありません.ただし、多くの管理ツール (ls など) に注意してください。 または rm ) は、ファイルが多すぎるディレクトリを処理するのに苦労する可能性があります。そのため、特定のディレクトリに数百から数千のアイテムが含まれないように、ファイルを分割することをお勧めします。これを行う簡単な方法は、使用している ID をハッシュ化し、最初の数桁の 16 進数を中間ディレクトリとして使用することです。
たとえば、アイテム ID が 12345 で、'DEADBEEF02842.......' にハッシュされるとします。 .ファイルを /storage/root/d/e/12345 の下に保存する場合があります .これで、各ディレクトリ内のファイル数が 1/256 になりました。