3

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

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

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

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

4

5 に答える 5

5

最も明白で実証済みの緩和手法は、ディレクトリに優れた階層設計 (およびパス名検索戦略) を使用し、ディレクトリを増やしてそれぞれのファイル数を減らすことです。

于 2009-01-11T21:02:21.770 に答える
3

dirhash と softupdates を備えた最近の FreeBSD バージョンでは、ディレクトリごとに数万のファイルがあっても問題はありませんでした。おそらく、500.000 ファイルかそこらを超えたくないでしょう。たとえば、2,500,000 個のファイルを含むディレクトリを削除するには、3 日かかりました。

于 2009-01-23T07:15:13.200 に答える
1

あなたの質問が正しく理解できているかどうかわかりませんが、たくさんのファイルをシークしたい場合は、RAID0 または VFS ファイルシステムに分割された mysql テーブルを使用してみませんか?

編集：私の知る限り、ファイル、権限、および名前のより大きなリストを維持する必要があるため、1つのフォルダーに多くのファイルがあると、FSの速度が低下します。データベースは、データのリストをメモリに保持し、非常に最適化された場所でシークするように設計されていますそれを通り抜けます。

于 2009-01-11T09:30:30.247 に答える
0

別のオプションとして、HTTP 経由でオブジェクトにアクセスする必要がある場合、またはアクセスできる場合は、小さな Web サーバーの前でワニスキャッシュを使用することです。最初はオブジェクトはディスクに保存されますが、varnish は特定のオブジェクトへの最初のアクセス後にメモリからオブジェクトを保存して提供します。

于 2009-01-11T21:00:00.310 に答える
0

ファイルが存在するか、それともアプリケーションによって作成されますか? リレーショナル データベースの構造を使用せずに任意のデータを格納する方法が必要な場合は、オブジェクト データベースを調べましたか?

于 2009-01-11T09:58:40.050 に答える