質問

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

データツリーの永続化メカニズムとしてディレクトリツリーをどのように使用していますか?

役に立ちましたか?

解決

ツリーを読み書きするには、ノードごとにファイルシステムを数回呼び出します。これは、メモリイメージをウォークするために考案できる適切なコードよりもはるかに高価です。

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

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

編集:サイトのCGIバックエンド用にext3で同様のことをしました。ホイールを再発明しなかったため、プロトタイピングがより迅速になり、メンテナンスがより簡単になり、読み取り/書き込み/ロックが非常にうまくスケーリングされましたが、実際のストレージではディレクトリ構造自体への非常に頻繁な変更(毎秒数百件)が不十分でした;最後に、ディレクトリエントリが非常に頻繁に追加/削除されるディレクトリツリーのセクションがtmpfsボリュームになるように再構築しました-私にとっては、この状態のセットは、揮発性の低いストレージに格納された状態から(高価に)再構築できます再起動後。私はZFSの経験がほとんどなく、意図した使用パターンがわからないので、これが問題になるかどうかはわかりません。非常に頻繁に使用されるサイトでこれを実行している場合、代わりに独自の名前付きロックライブラリをロールバックします。

他のヒント

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

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

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

それが正しく理解できれば、ファイルシステムのコード内表現を提供するツリー構造の構築について話しているので、ツリー構造を読んでいる最初にオーバーヘッドが発生すると思われますが、しかし、その後のツリーのルックアップとトラバーサルは、毎回ディスクストレージにアクセスするよりも速いでしょう。

考えられる問題:

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

一番下の行:価値がないかもしれません。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top