* データディレクトリの分散によるオーバーヘッド [#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};
- ベンチマークは必要だと思います。ファイルの配置はファイルシステムがどうアロケートするかの知識が必要です。あと、一つ気になるのですがディレクトリの生成削除で危険なこととはなんでしょうか？ -- [[Cue]] &new{2005-09-23 (金) 21:14:38};
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
