ファイルシステムは多くの小さなファイルでパフォーマンスをシークします

StackOverflow https://stackoverflow.com/questions/432603

質問

XML APIによって配信される多くの小さなファイルを使用してサーバーを構築したいと考えています。ディレクトリやシーケンシャルファイルのブロックを何度も繰り返し処理することはありません。不連続なデータを探すためにたくさんのシークを行っています。

BSD UFSでのシーク時間は、個々のファイルのリクエストの時間とともに低下しますか？ファイルシステムのiノードの制限はパーティション/スライスのサイズに基づいていることを理解していますが、ハードドライブはデータの場所を検出する前に、すべてのファイル要求に対してiノードテーブルをステップスルーする必要があります。どのファイルシステムがシーク時間で最高のパフォーマンスを発揮しますか？

別の方法は、2〜4 GBの「blob」をセットアップすることです。ファイル内に含まれるファイルをソフトウェア内から検索する別のシステムがあります。ソフトウェアの「inodeテーブル」現在ログインしているユーザーなどに基づいて、配信用に最適化できます。これらの「inodeテーブル」 RAMにキャッシュされる可能性が高く、現在ログインしているユーザーにのみ関連するため、無駄なリソースが少なくなります。

これら2つのソリューションは、スケーラビリティとメンテナンスの観点からどこで評価されますか？ 2番目のソリューションを使用すると、どんなパフォーマンスの向上が期待できますか？

役に立ちましたか？

解決

最も明白で実績のある軽減手法は、ディレクトリ（およびパス名検索戦略）に適切な階層設計を使用し、それぞれのファイル数が少ないディレクトリを増やすことです。

他のヒント

dirhash とソフトアップデートを使用した最近のFreeBSDバージョンディレクトリごとに数万個のファイルで問題はありません。おそらく500.000ファイルほど北に行きたくないでしょう。例えば。 2.500.000ファイルのディレクトリを削除するには3日かかりました。

あなたの質問を正しく理解しているとはわかりませんが、多くのファイルを検索したい場合は、RAID0またはVFSファイルシステム上にレイアウトされたパーティション化されたmysqlテーブルを使用してみませんか？

編集：私の知る限り、1つのフォルダー内の多くのファイルは、ファイル、権限、および名前のより大きなリストを維持する必要があるため、任意の FS速度を低下させます。メモリ内のデータを検索し、非常に最適化された方法でシークします。

状況の詳細は参考になりますが、ファイルは存在しますか、それともアプリケーションによって作成されますか？リレーショナルデータベースの構造なしで任意のデータを保存する方法が必要な場合は、オブジェクトデータベース

所属していません StackOverflow
scroll top