私は CentOS 5 と Plesk 9 (64 ビット) を使用しており、ユーザーが写真をアップロードするサイトを運営しています。64 ビット OS では、保存できるファイル数に制限はありますか? 気にしているのはパフォーマンスとファイルの提供だけです。4 つのディレクトリにファイルが散在するのは避けたいです。しかし、いつかは 20 万から 30 万枚の画像を保存できるようになることを期待しています。
答え1
あなたがいる場合ext3を使用する、私は見つけたこの引用(注意: スペイン語のサイトです)
「1 つのディレクトリには 32k (32768) のサブディレクトリという制限がありますが、これはおそらく学術的な興味のみの制限です。多くの人はそれほど多くのファイルを持っていないからです (ただし、巨大なメール サーバーではこの点を考慮する必要があります)。ext2 inode 仕様では、1 つのディレクトリに 100 兆を超えるファイルを配置できます。」
参考文献ext3はしない32Kの制限があり、これは経験的に証明されている。
a=0; i=1; while [ $a == 0 ]; do touch $i; a=$?; let i++; done
しかしそれはを持っているフォルダの32Kの制限は、次のようにテストできます。
a=0; i=1; while [ $a == 0 ]; do mkdir $i; a=$?; let i++; done
この（根拠のない）主張と言う
ReiserFS は、単一のディレクトリに数十万のファイルがあってもまったく問題ありません。 flabdablet - 2007 年 2 月 1 日
この質問姉妹サイト stackoverflow.com も役立つかもしれません。
一般的に：
- そこにははディレクトリの数の制限、
- あなたすべきファイル/ディレクトリは32K以下に抑えてください。できるさらに先へ進むと、
- 使用しているファイルシステムは重要です。
答え2
これは、使用しているファイルシステムに大きく依存します。ext3 の特定の古いバージョンは、この点でひどいものでした。そのため、btree が生まれました。Reiser は、このような大量のファイルを扱う場合、はるかにパフォーマンスに優れています。以前、GroupWise の不具合により、NetWare サーバーに Novell NSS ディレクトリがあり、そこに 250,000 個の 4kb ファイルがありましたが、まったく問題なく動作しました。ディレクトリの列挙は大変でしたが、そのディレクトリ内の特定のファイルにアクセスするのは、期待どおりの速さでした。これは 8 年前のことですから、現代の Linux ファイルシステムは、これを問題なく処理できると推測せざるを得ません。
答え3
これは、使用しているファイルシステムによって異なり、オペレーティング システムが 64 ビットかどうかによっても異なります。どのファイルシステムでも、ディレクトリの検索に使用されるアルゴリズムのビッグ O コストがコンピューターの性能を上回る時点が必ずあります。
ファイル階層を 2 層階層に分割できれば、長期的なスケーラビリティが向上します。
答え4
画像の数が数百を超える場合は、必ず次の 2 つの点を考慮してください。
- ハッシュ化されたファイル名を持つネストされた階層。
- ext3を使用していない
XFS、またはそれができない場合はReiserFSを使用して、2バイトのペアで分割された2つまたは3つの深さのディレクトリ階層を使用することをお勧めします。例：
11/2f/112f667c786eac323e300632b5b2a78d.jpg
49/2f/49ef6eb6169cc57d95218c842d3dee5c.jpg
0a/26/0a26f9f363f1d05b94ceb14ff5f27284.jpg
これにより、最初の数レベルに 256 個のディレクトリが作成され、合計 65535 個の個別のディレクトリに画像が分割されます (100 ～ 200,000 個以上の画像には十分すぎる数です)。これにより、処理速度が大幅に向上し、スケーラビリティも大幅に向上し、後々のメンテナンスも大幅に容易になります。