というわけでサービスをリリースしてみたわけですが。今後の問題点とか。

自分の実用を兼ねてTumblr絡みでサービス2つをリリースしてみました。

Tumblr Tag Cloud Maker | Tumblrにタグクラウドを設置するスクリプト
Tumblr Thumnails | Tumblrのサムネイルを作成するスクリプト

どちらも今のところ特に問題なく動いているんですが、やっぱりかなり見切り発車で設計したのでだいぶ微妙なところもあります。インターフェイスを変更することはまず無いと思うんですが、このまま継続するにはちょっとなーと言うところもあるのでちょっと問題点を。

DBがSQLiteである

そんなにテーブル大きくならないだろ、と高をくくってたんですが…既に結構な行数になってます。執筆時点で16万行くらいかな。総Post数が1万を超えるユーザがゴロゴロしているというのはちょっと想定外でした。みんなTumblrがんがん使ってるのね。格納するデータは最小限にとどめてる(PostID、Tag、UserIDだけ。個別のデータはAPIで取得)ので、DBのサイズとしてもそれほど大きくないんですけど減ることもないわけなので。そのうち限界が来るなーという感じ。

どんなテキストを読んでみても『中小規模の開発に向いており?』とか書いてあって、じゃあその規模の限界って具体的にどの辺なのよとか思うわけですが、まぁそんな目安があるわけもなく(環境によって全然違うわけだし)、システムとしては早めにMySQLを準備して平行して動かしておいて、やばくなったら切り替える…みたいな方式で行こうかなと思ってます。まぁそんなのやる前から解ってたことだろっていう話もあるんですが、一度SQLiteである程度の規模のデータを扱ってみたかった(それもデータの一時保管とかじゃない形で)ので…。ある意味でSQLiteの耐久テストみたいなもんですかね?

幸い大量のSELECTを捌くことはあっても、大量のINSERTを捌くようなことは(バックグラウンドの更新作業を除けば)そうはないのでそうすぐに問題が出るとは思いませんが、ファイルロックしてもね…困るので。MySQLの方はさくらインターネットの共有サーバでも十分に快適に動くことが確認できてますしね(このサイトのアクセスログテーブルはもうすぐ300万行…RDBMSでログ管理なんかしちゃダメなのかしら。ざっくりとした表示するだけで複雑な解析なんかしないしユーザも僕だけだから別に良いかと思ってるんだけど)。



JSONPのライブラリ

JSONPの処理部分は、こちらの処理を使わせていただいています。

XML.com: JSON and the Dynamic Script Tag: Easy, XML-less Web Services for JavaScript

が、著作権表示が一般著作物に対してのものしかなく、とりあえずそれに従ってクレジットは残す形で使ってるんですが…やっぱり微妙。そんなに長いコードじゃないので、きちんと独自実装したいところです。



POSTの変更に弱い

コレはもうねぇ…どうしようもないよね。あくまでAPI経由で中間テーブルみたいなDBを作ってるだけなんだから、持ってもいない生データと同期させるのは難しい。出来ることは、定期的にチェックを行うことくらいだけど…それもなんかなぁ。別に同期じゃないしなぁ。とりあえず、保留。



負荷対策

今のところサムネイルの出力に関してはSmartyで、APIを通じて取得したPost情報(サムネイルのURLなど)はPEAR::Cache_Liteで管理してますがやっぱりファイルが溜まる一方で。何とかした方が良いなーとは思ってるんですが、レンタルサーバ(しかも共有)だとなぁ…限度ってもんがありますよね。



フレームワーク

すみません、勉強さぼりました!自前のフレームワークって言うか環境で適当に書いてますがこれどう考えても何か使った方が良さそうです。個人的にはSymfonyが馴染みがあるんですが、CakePHPでも使ってみようかなぁとか。



その他、CSSサンプルとか付いてた方が良いのかなーとも思いますが、まぁその辺は気が向いたらで。