ここ数カ月、RoRを使って開発してみてるけど(その前はphp)、やっぱり色々と重厚すぎるので、ちょっとしたWebアプリには向いてない気がしている。
で、Sinatraを試してみたんだけどなかなかいい感じ。後発だけあってRoRをかなり意識した上で無駄を削ぎ落した感じ。「無駄」というと怒られるか。
今回はSinatraとMongoDBの繋ぎの部分に MongoMapper を使ってみた。ruby + mongoDBで、rubyからmongoDBを使う場合、まだまだ「デファクト」と呼べるような物はないみたい。いくつか同じような物が開発中のよう。その中からMongoMapperを選んだのは最低限の機能ありそう＋開発が活発ってぐらい。ただ、最近twitterでmongoidってのがあるというのを知って、少し試してみたけどそっちの方がいいかもしれない。MongoMapperはヘタにActiveRecordを意識しすぎている感じがする。
SinatraからMongoMapperを使うのに特に難しいところはない。gemで両方インストールして後はドキュメントにある使い方をするだけ。たとえば、このブログで使ってる一番シンプルなクラスだと、
class User
include MongoMapper::Document
key :login, String, :required => true, :unique => true
key :name, String, :required => true
timestamps!
endこれだけで、後はActiveRecordっぽく使える。
例：
% irb19 -r app.rb
>> u = User.create!(:login=>'masatomo', :name=>'Masatomo Nakano')
=> #<User _id: 4b4b9e89a90e088f03000001, login: "masatomo", name: "Masatomo Nakano", created_at: 2010-01-11 21:56:25 UTC, updated_at: 2010-01-11 21:56:25 UTC>
>> u.name = 'Masatomo, updated'
=> "Masatomo, updated"
>> u.save!
=> true
=>
% irb19 -r app.rb
>> u = User.find_by_login('masatomo')
=> #<User _id: 4b4b9e89a90e088f03000001, login: "masatomo", name: "Masatomo, updated", created_at: 2010-01-11 21:56:25 UTC, updated_at: 2010-01-11 21:56:40 UTC>
>>みたいな感じでMongoDBを特に意識せずに使える。
mongoDBに限ったことではないけど、RDBMSを使う場合と違って新しいフィールドを追加した場合にもUserクラスだけ拡張すればいい。特に開発序盤ではこれがすごく楽。
そんなわけで、arpnetworksのVPSでFreeBSDを使っているんだけど、メモリもSwapも少なめなので、大きめのものをコンパイルするとメモリ不足で止まってしまったりする。そういうときに一時的にswapを増やすメモ。
ファイルを作って、それをswaponするだけ。この例では180M増やしてる。
作成:
$ dd if=/dev/zero of=/tmp/swap_ext bs=1024k count=180
$ sudo mdconfig -a -t vnode -f /tmp/swap_ext -n 0
（このコマンドの後、"0"とか表示されるのが、これが次のコマンドの/dev/mdの後の数字になる）
$ sudo swapon /dev/md0削除:
$ sudo swapoff /dev/md0
$ sudo mdconfig -d -u 0
$ sudo rm /tmp/swap_ext
コメントはDISQUS側に保存されるので、コメント回りでめんどくさいspam対策とかセキュリティ的なこととかをほぼ丸投げ出来る。設置もDISQUSに提供されるJavascriptを貼るだけなので簡単。簡単なCSSとかの変更はできる。コメント入力周りは日本語も選べるみたい。本格的にやるなら自前で持ちたいところだけど、どうせコメントなんて滅多に来ないし、これで十分。DISQUSに登録してない人もanonymousでコメントの投稿はできるんで、その辺も心配しなくて良さそう。
Webサービスとして見ると、仕組としては単純だけど、permanent linkさえあればブログだけではなく、どんなものにもコメント機能を付けられる、ってのはなかなか面白いと思った。
それと、一度くらい触ってみた方がいいかなと思って、Google AdSense もつけてみた。こっちもJavascript貼るだけ。便利な世の中ですねぇ。
まだ UK£0.00 なので誰かクリックしてみてください！
普通にRDBMSをデータベースとして使っているのだが、最近の流行りに乗ってKey-Value型のデータベースもちょっと見てる。
そんな中、少し前にCouchDBで遊んでたときに書いたメモ。ほんとにメモだけど公開してみよう。
最初の一歩
色々ググったりブログ見たりするより、とりあえず http://books.couchdb.org/relax/ を読むのオススメ。日本語翻訳が始まってるようです（私は参加してないですけど）。
CouchDBの魅力
最近あちこちでCouchDBの紹介を見るのでいまさら感はあるけど、その中でも自分が特にいいなと感じるCouchDBの魅力は、
スキーマレス
これはKey-Value型DBでは当然の機能っぽいけど、RDBMSと違いテーブルのカラム情報をDB側にあらかじめ持っておく必要がない。なんでも格納できる。このため、テーブルの情報みたいのをアプリケーション側だけに持たせられり。RoRとかで言うとMigrationスクリプトをしこしこ書く必要がない。もちろんデータ移行/更新が必要な場合は別だけど。
柔軟なViewとインデックス
Key-Value型ですが、Valueを検索KeyとしてViewを定義するとかも簡単にできる。また、作ったViewはデータの更新にあわせてインデックスが張られる。たとえば、複数ユーザが同一のViewの情報を欲しい場合にもView自体は同じ実体を見るので２度目からは非常に早いはず。また、データ追加/更新時にはすべてのViewが作り直されるわけではなく、変更になった部分だけ自動的に更新される（でもこのため？にViewはB treeで格納できるように作らないといけないので、そこがちょっと難しい）。このためデータの更新が激しい場面でも向いてそう。
マルチマスタな非同期レプリケーションが標準装備
レプリケーションが簡単にできる。また非同期かつマルチマスタなので書き込み時のスケーラビリティも高そう。もちろんデータの衝突後の処理はプログラマ側が書かないといけないけど。
制限
データを分割して分散できない
大量なデータがあって、それを分割して複数のサーバに分散する、と言ったようなことは今のところできないっぽい。レプリケーションは単純にデータベース全体をコピーみたい。
Viewは何でも作れるわけではない
例外も色々あるが、RDBMSでいうテーブルを３つJoinみたいなことはできない。２つならできます。（全般に言えることですが、RDBMSのことはきれいさっぱり忘れて考えた方がいい。が、どうしてもRDBMS脳なんで比べてしまう。）
そんなわけで、
ちょっとまだアプリケーションで使うのは辛いという印象。特にViewを作るのに手間がかかりすぎる感がある。ちょっとしたアプリケーションを作るにもいちいちViewをいくつか作って、それを使ってさらにアプリケーション側も実装する、というのはいまどきのスピード感から言うとちょっときつい。
そんなわけでmongoDBに流れてしまった自分であったのでありました。
RSSリーダで読む