3 レベルのサブディレクトリに約 200 万個のファイルが保存されているファイルベースの DB があります。
2/2/6253
2/2/6252
...
ファイルのサイズは 30 バイトから 60 KB までです。DB 全体は読み取り専用です。DB のサイズは約 125 GB です。
追加した：すべてのファイルはzlib (python) によって圧縮されます
すべてをファイル システムを含む 1 つのファイルとして処理したいのですが、どのファイル システムを選択するのが最適ですか?
現時点では、次のスクリプトを使用しています。
dd if=/dev/zero of=/my_file.iso bs=1024K count=60000
mkfs.ext4 -f /my_file.iso
mount -o loop /my_file.iso /mnt/
答え1
おそらく、XFS だけを使いたいでしょう。
それはあなたが求めているものを十分に満たし、その役割を果たします。
他のトレードオフを伴う、あまり使用されていないファイルシステムでこれを複雑にする理由はありません。
参照してください：サブディレクトリの数は、Linux 上のドライブの読み取り/書き込みパフォーマンスにどのような影響を与えますか? そしてXFS におけるディレクトリ対ファイル比率の高さの影響
もっと難解なものがお望みなら、ファイルシステムを上にしたZFS zvolsが興味深い代替案となるかもしれません（圧縮、整合性、移植性のため）。
こちらをご覧ください:ext4 と組み合わせた透過的な圧縮ファイルシステム
答え2
小さなファイルの数を見ると、SquashFS の使用を検討します。特に、十分に強力な CPU (つまり、Pentium III や 1GHz ARM ではない) をお持ちの場合はそうです。
保存されているデータの種類に応じて、SquashFS はデータサイズを大幅に削減し、読み取り時の I/O を削減できます。唯一の欠点は、読み取り時の CPU 使用率です。一方、最新の CPU であれば、HDD やおそらく SSD をはるかに上回る速度で解凍できます。
もう 1 つの利点として、転送後の解凍にかかるスペースや帯域幅、および/または時間を節約できます。
いくつかのベンチマークISO や他の同様の手段と比較します。すべてのベンチマークと同様に、この結果は鵜呑みにせず、自分で偽造した方が良いでしょう。 ;-)
編集: 状況によっては (推測するつもりはありませんが)、圧縮なしの SquashFS ( mksquashfs -noD) の方が ext4 よりパフォーマンスが優れている可能性があります。読み取り用のコードがはるかに単純で、読み取り専用操作に最適化されているからです。ただし、これは実際に使用ケースでベンチマークするユーザー次第です。もう 1 つの利点は、SquashFS イメージがデータより少しだけ大きいことです。Ext4 では、常により大きなループ デバイスを作成する必要があります。欠点は、もちろん、データを変更する必要がある場合にかなり不便なことです。これは ext4 の方がはるかに簡単です。
答え3
読み取り専用の場合、ISO ファイルを使用しないのはなぜですか?genisoimageまたは を使用できますmkisofs。
全体を圧縮したい場合は、squashfs圧縮率が非常に高い別の読み取り専用ファイルシステムである を使用することもできます。
答え4
これが目的に合っているかどうかはわかりませんが、tar複数のファイルを結合することを検討しましたか? そうすれば、ファイルシステムの負荷とスペース要件が軽減される可能性があり、データベース アプリケーションは、多数のライブラリの 1 つを使用して特定のファイルのデータを読み取ることができますtar。
アクセス パターンによっては、パフォーマンスが向上する可能性もあります。