* データディレクトリの分散によるオーバーヘッド [#tc068b72]
- ページ: [[BugTrack2]]
- 投稿者: [[Cue]]
- 優先順位: 低
- 状態: 提案
- 状態: 保留
- カテゴリー: その他
- 投稿日: 2005-09-23 (金) 12:57:37
- バージョン:
** メッセージ [#v3eed3e1]
１つのページが持つデータは機能別にディレクトリ分けされている為、例えばページ総数が1,000の場合は1,000のファイルを擁するディレクトリが複数存在する状態になり、以下のような影響が出る。
- ディレクトリ検索によるオーバーヘッドの増大
- ディスクキャッシュの利用効率低下
- (特にページ書き込み時の)シーク増加
このことは、フラグメントが発生し難くなるよう分散してディレクトリ・ファイルを配置するファイルシステム(ext2fs,NTFS等)でより顕著になる。
ページに関連するデータと関連しないデータを分けた上で、１つのページに関連するデータは%%一ヶ所に%%ページ毎のディレクトリに集約するよう配置して局所性を最大限に発揮させることが望ましい。
--------
- その方法を行うと、機能の一つに対し仕様変更が行われた場合にすべてのデータを書き換える必要が発生したり、それぞれのデータのうち一つが破損した場合にバックアップがバックアップとして機能しなくなったり、一つのデータの破損がページ全体に波及する可能性があります。また、ファイルによってはgzipで圧縮格納されており、どちらの格納方法で統一するのかなども問題になると思われますが…全体的にデメリットの方が大きいように感じます。 -- [[Ratbeta]] &new{2005-09-23 (金) 14:18:43};
-- ディレクトリに置く事を想定していたのですが１ファイルにまとめるように読めてしまいますね、訂正して書き換えました。 -- [[Cue]] &new{2005-09-23 (金) 14:55:11};
- うーむ、基本的な所から整理させて下さい。ファイルベースのWikiの基本コンセプトは「ディレクトリ内部をサーチせず、特定のパスにあるファイルへ直接アクセスすることで速度をかせぐ」という点にあります。「[A]ファイルパスからファイルの実体を引き当てる」までの負荷は最初やや大きいですが、二回目以降はOSやPHPのレベルでキャッシュされます。一方で、「[B]ディレクトリにあるものを一覧したり、ディレクトリの中から特定の条件にあう物を探す」処理は常に負担がかかり、キャッシュが使えません(特に複数のプロセスが読み書きするディレクトリの場合は)。 -- [[henoheno]] &new{2005-09-23 (金) 17:22:21};
-- 典型的な例としては、PukiWikiがページを表示する場合、「ページを描画する」部分は特定のファイルに数回程度直接アクセスするためコストがあまりかかりませんが、「ページに添付されているファイルの一覧を常に生成する」部分はattachディレクトリを探索するため、attachディレクトリに多数のファイルがある場合、常に負担の元になります。快適さが売りのツールとしてはこの潜在的なボトルネックは問題です。だから1.4.6以降はoffにできるようにしてあります(それと引き換えの危険性は、その時に触れた通り -- [[henoheno]] &new{2005-09-23 (金) 17:25:24};
[現在]
data/wiki/pagename.txt <- 「一覧」を表示する時以外は直接アクセス
data/diff/pagename.txt <- 直接アクセスのみ(deletedプラグインは一覧する)
data/backup/pagename.gz <- 「一覧」を表示する時以外は直接アクセス
data/counter/pagename.count <- 直接アクセスのみ
data/attach/pagename_attach1.bin <- 「一覧」と「ページ表示」以外は直接アクセス
data/attach/pagename_attach2.bin <- 「一覧」と「ページ表示」以外は直接アクセス
[再構成例]
data/pagename/_wiki.txt
data/pagename/_diff.txt
data/pagename/_backup.gz
data/pagename/_counter.txt
data/pagename/attach1.bin
data/pagename/attach2.bin
-- [[Cue]]さんの想像しているのは上に挙げた再構成例のような状態ですか？ 違う場合、そのレイアウトを示して下さい。 -- [[henoheno]] &new{2005-09-23 (金) 17:44:49};
- 私が想定しているのは再構成例で上げて頂いた形です。*.countもページ描画時に参照されるものなので含めてもいい気がしていますが*ref,*relは実際に調べていないので今は分かりません。&br;パスを指定したファイルアクセスはOSレベルで解決されるのでそれほど気にする必要はありませんが、それでも木構造を意識した構成はした方が良いと思うので「もし構成を変えることがあれば」程度の意味で取り上げさせてもらいました。 -- [[Cue]] &new{2005-09-23 (金) 19:27:47};
-- counterを足しておきましたが、意図が伝わればよいので別に他のメディア(例えばtrackback)があってもなくても大筋には関係ないと思われます -- [[henoheno]] &new{2005-09-23 (金) 20:26:19};
-- このような案であるのであれば、上で言われている分析が正しいかどうかは検討の余地があると思います。またメリットとデメリットが出切っていないようですね :) -- [[henoheno]] &new{2005-09-23 (金) 20:28:17};
--- 例えばディレクトリ数には変化がありますがファイル数に変化はありませんから、分散してディレクトリ・ファイルを配置するファイルシステム(略)で「より顕著になる」という部分が今ひとつ腑に落ちません。また同じ理由から「ディスクキャッシュの利用率低下」という項目は成立していないと思います -- [[henoheno]] &new{2005-09-23 (金) 20:34:36};
--- また上記構成例は「ページ名のrename」「ページに添付された添付ファイルの一覧生成」「ページ名と添付ファイルの長さに関する問題」などに効果のあるデータ構造だとは思いますが、「diff/backupの一覧生成」などのように、特定の種類のメディアだけを扱いたい時には不利に働くと思います。また、プログラムによる「ディレクトリを生成し、また完全に削除する」という、ちょっと危ない機能を実装しなくてはいけなくなります。 -- [[henoheno]] &new{2005-09-23 (金) 20:41:33};
-- 要はどちらの構成にもトレードオフがあって、仮に後者のアイデアを使う事になるのであれば、attachについてだけ採用するとバランスが取れたもの(構造)になると思いますがどうでしょうか? -- [[henoheno]] &new{2005-09-23 (金) 20:46:22};
--- たしかattachは、upkさんがattach/ページ名/ファイル名ってやってたような。 -- [[okkez]] &new{2005-09-23 (金) 20:51:21};
--- そうですね、attachの事だけ考えても同じ方向に行くと思います -- [[henoheno]] &new{2005-09-24 (土) 09:47:58};
- ベンチマークは必要だと思います。ファイルの配置はファイルシステムがどうアロケートするかの知識が必要です。あと、一つ気になるのですがディレクトリの生成削除で危険なこととはなんでしょうか？ -- [[Cue]] &new{2005-09-23 (金) 21:14:38};
-- うーむ、このBugTrackも途中経過ベースで進めてますね? (^^; ベンチマークはいろんな意味でまともに動くものができてから考える事で、一面的な良さを得るために使っても説得力を持たせられません。もちろん、その比較条件の公平さを証明できなければなりません(例えば[[BugTrack2/11]]を見て下さい)。そして自明な部分の自明な結果を見せてもインパクトはないのです・・・ -- [[henoheno]] &new{2005-09-24 (土) 23:31:57};
-- カーネルやドライバの様なプログラム(NUMAとか)ならいざしらず、アプリケーションプログラムは個々のファイルシステム実装を意識しすぎてはいけません。どの位までなら意識して良いのかというとUnixライクOSの規格である[[POSIX>osdev-j:POSIX]]で既定されているようなインターフェースまでです(PHPの関数として用意されているような奴らです)。その一方で、意識するならするでここで解りやすい図などを示した方が良いと思います。 -- [[henoheno]] &new{2005-09-24 (土) 23:32:57};
-- Web経由でディレクトリを生成削除する機能を持っていない環境に、それを組み込むという事は危険です。もちろんWeb経由でファイルを生成削除する機能を持っていない環境に、それを組み込むという事も危険です (^^; (この手の例題は[[BugTrack/771]]にあります)。ありがちな結末は「そんな機能があるらしいので使ってみました」「脆弱性がありましたごめんなさい」です。他に解りやすい例を挙げればWebベースの管理画面を提供する機能やツールの脆弱性もこれに入りますね -- [[henoheno]] &new{2005-09-24 (土) 23:34:20};
-- それはそれで楽しいだろうと思うので止めませんが、「データディレクトリの(極端な)集中によるオーバーヘッド」(このページのタイトルの逆)について考えてみて下さいねー ((あと現状の利点と構造の単純さについてもー)) -- [[henoheno]] &new{2005-09-24 (土) 23:38:58};
- 他所での事例ですが。[[plus!:質問箱/368]](ディレクトリ内のファイルが多すぎる) -- &new{2010-10-05 (火) 23:40:53};
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
