filesystems - 永続性: ディレクトリ ツリーとして保存されたデータ ツリー

Question

永続化のためにメモリ内ツリー構造をディレクトリツリーとして保存することの実用性について疑問に思っていました。私の場合、彼のターゲットファイルシステムは ZFS であり、構造が作成されると、複数のプロセスからまれにアクセスされます。

データ ツリーの永続化メカニズムとしてディレクトリ ツリーを使用することのパフォーマンスは?

Answer 1

ツリーを読み書きするために、ノードごとにファイルシステムを数回呼び出します。これは、メモリ イメージをスキャンするために考案できる正常なコードよりもはるかにコストがかかります。

それが賢明なアプローチであるかどうかは、予想される使用パターンによって異なります。コードの通常の呼び出しで、ツリー構造全体を読み取ることが期待される場合は、それを処理してから完全に書き出す必要があります。単一のファイルにマーシャリングする方がよいでしょう。ただし、ツリーの大部分を読み取ることなく、少数のノードのみを読み取り/作業/変更することが予想される場合、ディレクトリ構造をたどる場合と、単一のファイルに格納されたツリーをトラバースするために複数のシーク/読み取りを実行する場合のパフォーマンスの違い単純化/明確化/車輪の再発明を避けるために、前者を実行する価値があるかもしれません。さらに、複数のプロセスがこれを同時に実行している場合、ノードとサブツリーのロックは、ディレクトリベースのアプローチではるかに簡単になります。

一部の一般的に使用されるファイル システムでは、ディレクトリ エントリを開く時間は、ディレクトリ内のエントリの総数に依存することに注意してください。

編集: サイトの CGI バックエンドの ext3 で同様のことを行いました。車輪を再発明しないことで、プロトタイピングがより迅速になり、メンテナンスがより簡単になり、読み取り/書き込み/ロックはかなりうまくスケーリングされましたが、非常に頻繁に (1 秒あたり数百単位) 変更されるディレクトリ構造自体は、実際のストレージではうまく機能しませんでした。最終的に、ディレクトリ エントリが非常に頻繁に追加/削除されるディレクトリ ツリーのセクションが tmpfs ボリュームになるように、物事を再構築しました。再起動後。私は ZFS の経験がほとんどなく、意図した使用パターンがわからないため、これが問題になるかどうかはわかりません。非常に頻繁に使用されるサイトでこれを行う場合、代わりに独自の名前付きロック ライブラリを展開することになるでしょう。

Answer 2

ほとんどのファイルシステムは、開いているファイルへのアクセス用に最適化されているため、ファイルの開閉にはかなりの時間がかかります。ツリーの各リーフが小さい場合、構造全体の読み取り/書き込みに必要以上の時間がかかります。

また、ほとんどのファイルシステムには最小限の割り当てブロックがあり、通常は約 2 ～ 8KB です。葉がそれよりもはるかに小さい場合、多くのスペースが無駄になります。

要するに、葉が小さければ小さいほど、アイデアは悪くなります。

Answer 3

考えられる問題:

• ディスクスペースの使用が非効率になる可能性があります (多くのファイルシステムでは、ディレクトリはファイルであり、ディスク上のブロック全体を占有します...)
• 多くのファイルシステムアクセスを行うため、読み取り/書き込みが遅くなります
• ファイル システムによって、各アイテム名の長さおよび/または名前に使用できる文字に制限が課される場合があります。
• 他のプロセスがデータを破損したり、かなりのロック コストが必要になったりするのは簡単です。
• ソリッドステート「ディスク」を使用する場合、他の方法よりも多くの書き込みが発生し、メディアの寿命が短くなる可能性があります

結論：それは価値がないかもしれません。

Answer 4

私が正しく理解している場合、ファイルシステムのコード内表現を提供するツリー構造を構築することについて話しているので、ツリー構造を読み込んでいる開始時にオーバーヘッドが発生すると思われますが、その後のルックアップツリーのトラバーサルは、毎回ディスク ストレージにアクセスするよりも高速になる可能性があります。