500,000 個のファイルを含むディレクトリがあります。できるだけ早くアクセスしたいと思います。アルゴリズムでは、それらを繰り返し開いたり閉じたりする必要があります (500,000 個のファイルを同時に開くことはできません)。
どうすればそれを効率的に行うことができますか？私は当初、inode をキャッシュしてその方法でファイルを開くことができると考えていましたが、*nix は inode (セキュリティなど) によってファイルを開く方法を提供していません。
もう 1 つのオプションは、それについて心配せずに、ディレクトリ内のファイル検索で FS が適切に機能することを期待することです。それが最良の選択肢である場合、どの FS が最適に機能するでしょうか。特定のファイル名パターンは、他のパターンよりも速く検索されますか? 例: 01234.txt と foo.txt
ところで、これはすべて Linux 上にあります。
ファイル システムがext3であると仮定すると、dir_index が有効になっている場合、ディレクトリはハッシュされた B ツリーでインデックス付けされます。これは、アプリにコーディングできるものと同じくらい多くのブーストを提供します。
ディレクトリがインデックス化されている場合、ファイルの命名規則は重要ではありません。
http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/
いくつかのアイデア：
a) ディレクトリ レイアウトを制御できる場合は、ファイルをサブディレクトリに配置します。
b）ファイルを移動できない場合は、別のファイルシステムを試すことができます.xfsは、多くのエントリを持つディレクトリに適していると思いますか?
これを行う従来の方法は、ハッシュされたサブディレクトリを使用することです。ファイル名がすべて均一に分散されたハッシュであり、16 進数でエンコードされていると仮定します。次に、ファイル名の最初の 2 文字に基づいて 256 個のディレクトリを作成できます (たとえば、ファイル 012345678 は 01/2345678 という名前になります)。1 つでは不十分な場合は、2 つ以上のレベルを使用できます。
ファイル名が均一に分散されている限り、これによりディレクトリのサイズが管理しやすくなり、ディレクトリに対する操作が高速になります。
十分なメモリがある場合は、ulimit を使用して、プロセスが一度に開くことができるファイルの最大数を増やすことができます。私は 100,000 ファイルで成功しました。500,000 でも同様に機能するはずです。
それができない場合は、dentry キャッシュにすべてのエントリを保存するのに十分なスペースがあることを確認してください。dentry キャッシュは、カーネルがファイル名に基づいてファイル アクセスを高速化するために使用するファイル名 -> inode マッピングです。膨大な数の異なるファイルにアクセスすると、dentry キャッシュの利点が効果的に失われ、パフォーマンスがさらに低下する可能性があります。Stock 2.6 カーネルには、一度に最大 256 * MB の RAM エントリを持つハッシュがあります。2GB のメモリがあれば、500,000 を少し超えるファイルまで問題ないはずです。
もちろん、適切なプロファイリングを実行して、これが本当にボトルネックを引き起こしているかどうかを判断してください。
もう 1 つの質問は、ファイル内のデータの量です。SQL バックエンドはオプションですか?