web-dev-qa-db-ja.com

200万以上のファイルを効果的に処理

3つのレベルのサブディレクトリに約200万のファイルが保存されているファイルベースのDBがあります。

2/2/6253
2/2/6252
...

ファイルは30バイトから60KBまで変化します。 DB全体は読み取り専用です。 DBは約125ギガバイトの大きさです。

追加：すべてのファイルは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/
ubuntufilesystemsext4xfs
5
Worker

おそらくXFSを使用したいだけです。

それはあなたが求めているものにかなりの能力があり、仕事をします。

他のトレードオフを伴う可能性のある、あまり使用されていないファイルシステムでこれを複雑にする理由はありません。

参照してください： サブディレクトリの数はLinuxでのドライブの読み取り/書き込みパフォーマンスにどのように影響しますか？ および XFSでの高いディレクトリ対ファイル比の影響

より難解なものが必要な場合は、ファイルシステムを最上位に持つZFS zvolsが興味深い代替手段を提供する可能性があります（圧縮、整合性、および移植性の目的で）。

ここを参照してください： ext4と組み合わせた透過的な圧縮ファイルシステム

7
ewwhite

読み取り専用の場合、ISOファイルを使用しないのはなぜですか？ genisoimageまたはmkisofsを使用できます。

全体を圧縮したい場合は、圧縮率が非常に高い別の読み取り専用ファイルシステムであるsquashfsを使用することもできます。

2
shodanshok

小さなファイルの数を見て、SquashFSの使用を検討します。特に、十分に強力なCPUがある場合（PentiumIIIまたは1GHzARMがないことを意味します）。

保存されているデータの種類によっては、SquashFSはそのサイズを大幅に削減できるため、読み取り時のI/Oを削減できます。唯一の欠点は、読み取り時のCPU使用率です。一方、最新のCPUは、HDDやおそらくSSDよりもはるかに優れた速度で解凍できます。

別の利点として、スペース/帯域幅や転送後の解凍に費やす時間を節約できます。

いくつかのベンチマーク ISOおよび他の同様の手段と比較します。すべてのベンチマークと同様に、一粒の塩でそれを取り、より良いのは、あなた自身のものを偽造することです。 ;-)

編集：状況に応じて（そしてここで推測することを敢えてしないでください）圧縮なしのSquashFS（mksquashfs -noD）読み取り用のコードははるかに単純で、読み取り専用操作用に最適化されている必要があるため、ext4よりもパフォーマンスが優れている可能性があります。しかし、それはあなたのユースケースでベンチマークするのは本当にあなた次第です。もう1つの利点は、SquashFSイメージがデータよりも少し大きいことです。 Ext4では、常により大きなループデバイスを作成する必要があります。もちろん、不利な点は、データを変更する必要があるときに、かなり不快になることです。それはext4ではるかに簡単です。

2
Fox

これがあなたの目的に合っているかどうかはわかりませんが、tarで複数のファイルを結合することを検討しましたか？これにより、ファイルシステムの負荷とスペースの要件が軽減される可能性があり、データベースアプリケーションは、多数のtarライブラリの1つを使用して特定のファイルのデータを読み取ることができます。

アクセスパターンによっては、パフォーマンスが向上する場合もあります。

1
Simon