Hiroaki Sakuma
hiroa****@sakum*****
2005年 4月 2日 (土) 23:44:53 JST
佐久間です． > ただ、必ず無制限とすると設計が難しくなるのでおおよその数値を決めておいた > 方が良いと思います。たとえば、 > - 数百ページから数千ページでもそれほど性能が低下しないこと。 > - 初期のファイル長などは1万ページ程度を目安にする。 > - 最低100万ページは作れること。 > などです。（数値はてきとうです） > ここら辺は実際に運用している方のページ数とか、意見とかを参考にしたいですね。 はい．設計時にターゲットを想定することは必要ですよね． ただ，ファイルシステム，wwwサーバ，Perl，メモリなど，諸所の理由で自ずと制限 が出てくるでしょうから，アーキテクチャ的にこの制限より下で引っかからないよう にしておけば，他人のせいにできます(^^; 大学の入試のときに提出したレポートで，自分のソフトウェアとネットで配布されて いるソフトウェアのスケーラビリティのリサーチを行ったのですが，中にはとてもス ケーラビリティのことなど考慮されていないものもあったりしました． # 掲示板ソフトなのですが，10,000記事程度で止まってしまうものもありました 1人でWikiってる場合は数千数万というページ数は考えづらいですが，何かのソフト ウェアと連携させていたり，組織内などでグループウェア的に使ってると想像以上の スケールで動かしてる人も居るかもしれません． # そこまでサポートするべきか，という問題もありますが 現状のアルゴリズムでは，処理の時間でページ数に依存するところがないので，ファ イルシステム依存だと思います． ファイルシステムは，ディレクトリ構造の方が効率がよく，単一ディレクトリに大量 のファイルがある状態はあまり効率がよくないようです． # 詳しくは分かっていません 今のFSWikiのファイルの作り方だと，全てが同じディレクトリへ作られているので， ファイルシステムによっては急激に速度低下などが起こりそうな気もします 機械的に大量のファイルを作ったり，負荷を掛けれるベンチマークソフトを作って， 試してみたほうがよさそうですね． # スケーラビリティをFSWikiのウリにするとか？ > あと、後々の話になると思いますが、ページにもたせる付加情報も想定する一般 > 的な長さや上限を（後付けでも）明示した方が、DBを使ったものなどを作る時の > 指針になって良いと思います。 > ＃ちょと気が早いか。 RDBMSは拡張性で悩むことがあります． 独自形式だと，うまく作るとある程度上位互換性を保てる(HTMLとかHTTPなんかがい い例ですね)のですが，RDBMSではカラムを加えたり，DB構造を変える，というのが用 意じゃないです．一旦独自の形式に書き出して，新形式へ再度書き込む，という形を 取らないと，構造上は変更できてても，内部では非効率なデータの並びになってるこ とがあります． # MySQLなんかはDB自体に最適化するユーティリティが付いてます ===================== Sakuma,Hiroaki hiroa****@sakum*****
Fork