_ [Hiki] HikiのバックエンドのMySQL化とFastCGI化 / Hiki avec MySQL et FastCGI

ひさしぶりにHikiをいじりました。

現状のHikiは、ページ本文を直接ファイルで保存して、ページの属性は別のファイルに保存して、ページの履歴はオプショナルでCVSとかSubversionで管理、という感じなのですが、まるごとMySQLで管理することにしました。

いざそういう方針で実装してみると、本文、属性、履歴がそれぞれ別の管理方法になっていたのに比べると、とてもすっきり。 ページの最新版と履歴とは、別テーブルにせずに同一テーブルにリビジョン付きで保存して最新を取ってくる、みたいにしたのですが、一見シンプルに見えて、SQLのクエリーがけっこうややこしいことになるので、パフォーマンスのためにも、これは分離したほうがよさそうです。

でもまあ、だいたい動くようになったので、fdiary.net wikifarm（の自分のところ）に試験的に実戦投入してみると、いろいろ問題が続出しました。

• 環境がSargeでMySQLが古すぎてそのままでは動かず → backports.orgの5.0系にアップデート
• mod_ruby環境で動かすとなぜかSegmentation Fault → いい機会なのでFastCGI化にチャレンジ
• FastCGIがいつも2回目のアクセスで落ちる → 1回目の途中に$SAFE=1になって、2回目で落ちると判明
• 現状のHikiが、複数の設定のWikiを共通のFastCGIプロセスでさばくのが困難な実装になっているのに気づく ← いまここ

最後の問題は、データ保存のバックエンドを切り替える際に、別のファイルに同一クラス名で定義してそれをrequireしているので、最初にrequireされた際のクラス定義がその後ずっと使いまわされる、という問題でした。 今回の問題は別としてもあまり気持ちよくないので、ここはあとで修正します。

さて、バックエンドをMySQLにして何がうれしいかというと、例えばSPAMをまとめて消すときに便利とか、障害対策がMySQLのノウハウで楽にできるとかでしょうか。 設定ファイルとか添付ファイルとかは、依然として直接ファイルに保存しているので、いきなり何も考えずにアプリケーションサーバを増やして負荷分散とかは無理だけど、そういうことも今後できなくはないでしょう。

ただ、個人的には完全にanonymousなwikiは管理コストの点でもう無理だと思っていて、SNSみたいなゆるい認証の上で「仲間内で使う」ような利用を目指してシフトしていく方がいいんじゃないかな、と感じています。

思えばそんなことを考えてRubyist SNSを作ろうとしたんだよなぁ、と遠い目になりながら、そういう自由ソフトウェアの開発をがしがしリードする勇者の出現をひそかに待っております。