まだ重たいCMSをお使いですか?
毎秒1000リクエスト を捌く超高速CMS「adiary

2008/10/19(日)開発中

Ver2.1xの予定でしたが、メジャーバージョンアップになりそうです。本当はこれがVer2.0にする予定だったのですが、Ver1.44は成熟されてるとは言い難かったですから。

システムの奥深くにあちこち手を入れています。skeleton のタイプミスとか恥ずかしものから、スケルトンコンパイラとか。コンパイラの改修はほぼ終了し、今はユーザー承認モジュール(Auth*)を書き直してます。これ一番最初に書いたライブラリだったので、インターフェイスは問題ないものの実装が汚く、データファイルも独自形式。これをDBモジュールを使うように修正してます。*1

そんなことをやっているうちに、その下位ライブラリであるDBモジュールを書き直したくなり、Authを放置してDB_pseudo(擬似データベース。デフォルトで使用するテキストベースの独自DBです)の全面改修。気付いたら UNIQUE制約 や NOT NULL制約 がまともに動作するようになってたり(苦笑)*2

この手の独自DBモジュールというのは、壊れたときに対処に困るというのが最大の問題で*3、擬似DBはそこに気を遣った実装です。インデックスファイルとカラムひとつに対応する1ファイルから成ります。データベースはすべてテキストファイルで構成されていて、indexが壊れたときは、インデックスファイルを削除することでindexを自動再構築する機能が付いています。*4

さっきやっと擬似DBの修繕がほぼ完了したので、これからAuthの改修に戻るかというところなんですが、時間経ちすぎて、どこまで改修したのかもう忘れかけてる(笑)

*1 : DBモジュールがあとに開発されてるため、当時は使うという選択肢がなかった。逆に言うとAuth*がDB_pseudo*の下書きなっているため実装が綺麗になった。

*2 : SQL使えないだけで、"擬似"を取ってもいいんじゃないかって気がします。MySQLのMyISAMの実装がだいたいこのぐらいですし。参照制約はさすがに実装しませんでしたけど(MyISAMにもない)。

*3 : PerlのBDBだったかを使うと、飛んだときに巨大ファイルが1つだけ残るということが、昔よく聞きました。

*4 : 試しに data/db/#index.dat を削除してみるといいですよ。各カラムのデータを直接書き換えても、data/db/#index.dat を削除するだけでそのまま運用できたりします。