Wikiの設計に関する動的なやりとり

future 852 @future_ta

@zetamatta まあ取りあえず、「自分で書け」と突っ込んでおこう

ζ @zetamatta

@future_ta まぁ、自分で書くのはいいんだけれども、憶測に基いた記述や古い内容は消して欲しいと思う吉宗であった。

future 852 @future_ta

@zetamatta なるほど、そういうことか。まあ読む人も更新日時を見て、大体記事の信頼度を判断するでしょうし、それほど心配は要らないだろうけど…。最新版に対応した似た様なサイトが無いと狂うしかも知れないね。

future 852 @future_ta

Pukiwikiだけど、PHPだけで簡単にWikiを作れる良いソフトだと思うんだけど、常にPHPを発行し続ける時点で、当初の設計思想を間違えたという印象。Wikiの性質上、閲覧≫編集なんだし、閲覧時の不要なPHPの発行によりサイトに負荷がかかり続けてしまう。

future 852 @future_ta

これがポータルサイトの様に、ユーザー管理をする場合は仕方が無い気はするが、Wikiでそれは必要無い。基本部分は静的HTMLで、カウンタ等一部動的に変化する所のみ動的生成、と言う風にした方が良い気がする。Wifkyがそんな感じだった気がするけど…、違ったっけ？

ζ @zetamatta

@future_ta wifky は、むしろ思いっきり動的ですよ（笑）。本来「静的」であるべき画像発信時まで Perl が動いてますからね。

ζ @zetamatta

@future_ta Wiki で静的は HTML を生成するものは、むしろ少数派ではないかと。静的な HTML だと、ページのサイドバーに「最近更新されたページのリスト」とかを出したり、制約が増えますからね。逆に言うと、そういうの諦めれば済むだけの話かも。

future 852 @future_ta

@zetamatta その辺りを考慮しても、もう少し何とかならないかなと。最近更新されたページにしても、最初に表示される時だけ動的生成、以後は静的表示で行けるはず。常に動的に生成する必要のあるコンテンツって、特にWikiの場合ほとんど無いと思うんだけど…、その辺りどうなんだろう？

future 852 @future_ta

この前やったPukiwikiの静的HTML化では、編集時にスクリプトに飛んで、保存時静的HTMLを自動生成して戻る、という処理をしてたんだが、常に動的生成が必要な部分まで対応出来てなかった。最初からそう言う設計思想で作られたエンジンがあればもっと上手く行くんじゃ無いかと…。

heno @_heno

こんにちは。wikiのUIである「ページの存在を動的に調べて描画する」挙動が、動的前提の設計を促しがちです。また、他ページをincludeするような機能も同様です。これらをもっとうまくやりたいと思われるのはその通りだと思います。 @future_ta @zetamatta

ζ @zetamatta

@_heno そうですね。静的で生成すると、リンク切れの判別とかも出来なかったりしますね。

future 852 @future_ta

Wikiに関しては、小中規模(～10,000PV/日)は動的生成、～大規模(100,000PV/日)は静的生成、それ以上はDB連携タイプを使うべきだと感じてる。小規模の場合使い勝手優先、大規模になるとサー負荷軽減やミラーを考慮、それ以上は同期と負荷分散の観点からこうなるかと。

future 852 @future_ta

正直この辺りは感覚的な物でしか無いんだけど、長年この業界に足突っ込んでると「なんか変」という感じることがあって、落とし穴を避けるたりするときには結構重要。

ζ @zetamatta

@future_ta でも、Wikipedia の WikiEngine「MediaWiki」は動的だと思うんだが。

future 852 @future_ta

@zetamatta アレは超大規模なのでDB連携タイプかと。負荷分散を考慮すると、複数サーバーでの編集に対応しつつ同期処理をしないと駄目なので、DBを使わないと多分対応出来ないんじゃないかと。

future 852 @future_ta

たぶん静的HTMLが有効なのは、単サーバーかつ数万PV/日ぐらいのアクセスがあるサイト。想定としては、かなり人気のある個人管理のWikiサイトという感じ？ある意味需要がピンポイント過ぎて、誰も作らないのかも…。

ζ @zetamatta

@future_ta いや、DB を否定してるんじゃなくて、動的だよってことなんだが

future 852 @future_ta

@zetamatta 言いたいことは解った。ただ、なんか私の中では、何となくDBタイプと動的生成タイプは違うという認識なんだ…。実際の所内部ではどうなってるんだろう？整形済みのデータをDBに格納しているのか、取り出し時に処理をしているのかで大分違う気がする。

ζ @zetamatta

@future_ta 取り出し時に整形するのが原則だと思うが、毎回整形していてはコストがかかるから、キャッシュデータを別途持たせてるとかしてるんじゃなかろーか。おそらくハイブリッド？【この辺はあくまで想像】

future 852 @future_ta

@zetamatta まあ、複数台で負荷分散することを考えると、少しぐらいのコストはマシンの台数で押し切ることが出来る気はする。この辺りの超大規模システムの設計思想って、実際に携わってる人に聞かないと解らないんだよね…

ζ @zetamatta

@future_ta なんか「はてな」の中の人が、そういう本書いてなかったっけ？ 一応買ったけど、大阪に置きっぱなしだ。はてなダイアリーなんて、作りは Wiki と同じはずだからね。(自動キーワードリンクなんか)

future 852 @future_ta

@zetamatta 良いことを聞いた。今度読んでみる。

heno @_heno

ホスティングサイト上のPHPだけで実現する場合、大まかにはタスク(ロード)を分割統治するスケジューラーのようなもの、gcのようなもの、セッションをまたいで資源管理するカーネル然としたものが必要だろうと思っています。誰か作らないかな? @future_ta @zetamatta

Penn Station @pswiki

@zetamatta @future_ta MediaWikiでは様々なレベルでキャッシュ・メカニズムが駆使されていて、ファイル・キャッシュの利用も可能のようです。 http://t.co/oHkmRJc http://t.co/Lb7iQJm