イベントドリブン型静的生成ブログツールの提案

動的生成のブログツールの魅力 ARTIFACT ―人工事実―
静的生成のブログツールの魅力 絵文録ことのは

Blogツールのコンテンツ生成はどうするのがいいのか話されている.詳しくは上記リンクを
参照してもらいたいが,おおざっぱに問題を整理すると下記のような感じ.

動的生成 → 変更に強いが常にDB参照なのでサーバの負荷がかかる.
静的生成 → サーバ負荷はちょろいが全データの再ジェネレートに時間かかる.
結論: 一長一短だからまぁ用途によって使い分けるのがいいのかもね.


たまたま似たような問題にぶつかっていろいろ考えていたところなので,私が行おうとしてる解決方法を紹介したい.考え漏れとかあるかもしれないので,ツッコミ大歓迎です.


本ブログの立場からはDBとくにMySQLやPostgreSQLのような重量級のDBMSから直接データをひくという解決はあり得ない*1.かといってデザインを変更するたびに100万単位であるエントリを作り直すのもいやというのも当然だ.


ここでそもそも全データを再ジェネレートを行う必要があるのかということを考えてみる.
そのページにアクセスがない限りはそのエントリはあってもなくてもいいわけで,このことから
考えると「アクセスがあったときに初めて静的ファイルを生成する」という戦略が考えられる.


具体的に下記のような感じ.

  1. アクセスがあったらファイルがあるかを確認して,なかったらDBからひいてファイルを作成して配信.
  2. 該当ファイルがあればそのまま配信
  3. エントリの更新があったら関連ファイル群を削除(1に戻る)
  4. デザインテンプレートのような全ファイルに関わる変更の時は全ファイルを削除(もしくはディレクトリごとmv)
  5. キャッシュのリフレッシュのために,たまに(一日一回程度?)全ファイルを削除.
  6. 手元に実ファイルがないと検索用のデータが作れないとかがあるなら,たまに全ファイルを再ジェネレート


3の「更新時には関連ファイルを消す」というのがキモで,事実上動的ファイルに近いことを行いつつ,静的ファイルの高速配信が確保ができるというのがわかると思う.なおデータをmemcachedみたいなのに置く方法も考えられるが,メモリに入りきらない可能性が高いのであまりオススメは出来ない感じだ.


というわけで,動的生成と静的生成のいいとこどりとも言える.イベントドリブン型静的生成ブログツールの提案をしてみた.
なお上記をやってくれるBlogツールがもしあったら教えてください:D

(おしまい)

yamaz的日常

最近朝の通勤で門前仲町から銀座/新橋くらいまで歩いてから渋谷に行っている.
朝の永代橋から勝どき橋方向への隅田川の眺めは非常にすがすがしく,やる気がモリモリ湧いてくる.

yamaz的日常(その2)

デジタル・テレビの新たな挑戦　−−ブロードバンドがテレビ/デジタル家電を変える - Tech-On!

非常に興味深いけど,結構お高い.どうするかなぁ.

*1:本ブログは最速配信を研究する立場なので,こう書いてます.実業務ではDBMS使うケースはもちろんあります.念のため