私たちは、任意のコレクションを圧縮してサービスとして提供できるという目的で、何百万ものテキストファイルをLinuxファイルシステムに保存しようとしています。キー/値データベースなどの他のソリューションを試してみましたが、並行性と並列性の要件のため、デフォルトのファイルシステムを使用するのが最善の選択でした。
最も簡単な方法は、すべてのファイルをフォルダに保存することです。
$ ls text_files/
1.txt
2.txt
3.txt
どのEXT4ファイルシステムで動作する必要がある、フォルダ内のファイル数に制限はありません。
2 つの FS プロセスは次のとおりです。
- Webからスクラップしてテキストファイルに書き込みます（フォルダ内のファイル数の影響を受けないでください）。
- ファイル名のリストに従って選択したファイルを圧縮します。
私の質問は、1つのフォルダに最大1000万のファイルを保存すると、上記のタスクのパフォーマンスや一般的なシステムパフォーマンスに影響しますか？ファイルを含むサブフォルダツリーを作成するのとは異なりますか？
ベストアンサー1
これはコメントベースの質問/回答に非常に近いですが、いくつかの事実と私の意見を提供しようとします。
- フォルダに多数のファイルがある場合、そのファイルを列挙しようとしているシェルベースの操作（例：）が
mv * /somewhere/elseワイルドカードを正常に拡張できないか、結果が大きすぎて使用できない可能性があります。 ls多数のファイルを列挙するには、少数のファイルを列挙するよりも時間がかかります。- ファイルシステムは単一のディレクトリで何百万ものファイルを処理できますが、人々は苦労する可能性があります。
1つの提案は、ファイル名を2、3、4つの文字単位に分割してサブディレクトリとして使用することです。たとえば、数値名を使用している場合は、左から右に分割するのではなく、右から左に分割して分布を均等にsomefilename.txt保存できます。例えばsom/efi/somefilename.txt。12345.txt345/12/12345.txt
等しいzip -j zipfile.zip path1/file1 path2/file2 ...。
Webサーバーがこれらのファイルを提供している場合（これが関連しているかどうかはわかりません）、Apache2の書き換え規則を使用して仮想ディレクトリのためにこの構造を隠すのは簡単です。 Nginxも同じだと思います。