* データディレクトリの分散によるオーバーヘッド [#tc068b72]

- ページ: [[BugTrack2]]
- 投稿者: [[Cue]]
- 優先順位: 低
- 状態: 提案
- カテゴリー: その他
- 投稿日: 2005-09-23 (金) 12:57:37
- バージョン: 

** メッセージ [#v3eed3e1]
1つのページが持つデータは機能別にディレクトリ分けされている為、例えばページ総数が1,000の場合は1,000のファイルを擁するディレクトリが複数存在する状態になり、以下のような影響が出る。

- ディレクトリ検索によるオーバーヘッドの増大
- ディスクキャッシュの利用効率低下
- (特にページ書き込み時の)シーク増加

このことは、フラグメントが発生し難くなるよう分散してディレクトリ・ファイルを配置するファイルシステム(ext2fs,NTFS等)でより顕著になる。

ページに関連するデータと関連しないデータを分けた上で、1つのページに関連するデータは%%一ヶ所に%%ページ毎のディレクトリに集約するよう配置して局所性を最大限に発揮させることが望ましい。
--------
- その方法を行うと、機能の一つに対し仕様変更が行われた場合にすべてのデータを書き換える必要が発生したり、それぞれのデータのうち一つが破損した場合にバックアップがバックアップとして機能しなくなったり、一つのデータの破損がページ全体に波及する可能性があります。また、ファイルによってはgzipで圧縮格納されており、どちらの格納方法で統一するのかなども問題になると思われますが…全体的にデメリットの方が大きいように感じます。 -- [[Ratbeta]] &new{2005-09-23 (金) 14:18:43};
-- ディレクトリに置く事を想定していたのですが1ファイルにまとめるように読めてしまいますね、訂正して書き換えました。 -- [[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/attach/pagename_attach1.bin <- 「一覧」と「ページ表示」以外は直接アクセス
  data/attach/pagename_attach2.bin <- 「一覧」と「ページ表示」以外は直接アクセス
 
  [再構成例]
  data/pagename/_wiki.txt
  data/pagename/_diff.txt
  data/pagename/_backup.gz
  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};

#comment


トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Site admin: PukiWiki Development Team

PukiWiki 1.5.4+ © 2001-2022 PukiWiki Development Team. Powered by PHP 5.6.40-0+deb8u12. HTML convert time: 0.097 sec.

OSDN