2010年9月18日土曜日

redis その3

一目で分かるRedis



一目で分かる Grails から Redis へのマッピング



ただし, 実際には今のところキーに非欧米文字は使えないようで, 適当なエスケープ/エンコードが必要です
投稿者 時刻:

2010年9月12日日曜日

redis その2

さて, 淡々といきますよ.

redis本体をダウンロード, $make; $make test します.

Grailsプロジェクトを作り, GORM for redisプラグインをインストールします.

maven経由でいろいろなjarが付いてきます.
  • grails-datastore-gorm-redis-1.0.0.M1.jar
  • grails-datastore-gorm-1.0.0.M1.jar
  • spring-datastore-web-1.0.0.M1.jar
  • spring-datastore-core-1.0.0.M1.jar
  • spring-datastore-redis-1.0.0.M1.jar
  • jedis-1.0.0-RC4.jar
最後のjedisは, Javaのredisクライアントですが, その他はバージョン番号から見て, このGORM for redisの一味 (inconsequentialってやつですかい?) のようです.

さて, 何はともあれ, redisにつなぐGrailsアプリケーションを作ってみます. 取りあえず, grails側, redis側共にいっさい手は入れず, デフォルトのまま, grailsのintegration testを動かすことにします.

redisは $ ./redis-server で走り始めます. 5秒ごとのハートビートが鬱陶しいですが, 動かし始めると最初は役に立ちます.

ドメイン・クラスはこんな単純なもの. 関連も何も持ちませんが, 姓, 名についてインデクスを貼ってみました.

class Person {
static mapWith = "redis"
String surname
String surnameKana
String forename
String forenameKana
Date dateOfBirth
Boolean gender

static mapping = {
surname index:true
forename index:true
}
}

見て分かるとおり, Hibernateと共存した上で, このドメイン・クラスについてはredisを使うようにしています.

さて, 適当に1万件ほど作って, save()してみましょう. 20秒ほどで終了. なるほど.

と思いきや, この後に count()しようとすると, その時点で200秒 (!!) ほど待たされます. その間, redis側ではせっせとファイルに書き込んでいるようです. (redisではない) どこかにキャッシュされていただけなのですかね.

最初から1万件を一件ごとに save(flush:true) してみると, 230秒. だいたい理屈は合ってます:-) ちなみにこの時点でDBファイルの大きさは3MBほどになっています.

うーん. じゃあ今度は同様に10万件ほど書き込んでみると...

... 何時間か動いた挙げ句落ちました orz

そろそろ, 自分の手が何をやっているか, 頭が理解していないとやばい気がしてきました. GORM for redisにもまだまずいところはありそうですが, まずはredisについてもう少し掘ってみましょうか...
投稿者 時刻:

2010年9月11日土曜日

redis その1

ここ十数年, あらゆるデータ・ストレージがSQLに偏っていくのを苦々しく見ていた山田です.

80年代前半はSQLもまだ成熟していませんでしたが, リレーショナルなデータベースの理論には面白いところもありました. BSD版UNIXには, UCBで作られたIngresが付いてきましたよね. Ingresはその後, いろいろあってPostgreSQLへとつながっていくわけですが, 当時はRDBMSを本番のデータ・ストレージに使うなんてとんでもない! という (今とはまったく逆の) 雰囲気でした.

問題はリレーショナルなモデルそのものというよりは, SQLとか, 「データ中心モデリング」などという考え方にあるというのは, 後々に分かってくることです.

当時メイン・フレームやミニコンはともかく, Unixなどで何をデータ・ストレージに使っていたかというと, ファイル・システム (それ以前のファイル・システムに較べて, Unixのそれはそれなりに良くできていたのです) やBerkley DB (これはその後ライセンスが難しくなり, 使いにくかった) だったわけです. Berkley DBはいわゆるkey-value storeですね. 今はオラクルのものになってしまいましたが...

その後オブジェクトの時代になります. オブジェクトにはオブジェクトの容れ物 (OODB) があり, とても面白く, ある面では使いにくかった. その1つにGemStoneがあり, これは今vmwareに買収されて, 新しい局面を迎えています.

OODBは広く普及することはなく, ORマッパが広まっていきます. 中でもその初期に, NeXTが提供していたEOF (Enterprise Object Framework) は, 今のような, 単純にクラスと表を対応付けるだけのものとは微妙に違って, 表をオブジェクト的に活用する, (癖はあるものの) 興味深いORマッパでした.

当時は, 大量の不定型なデータを扱うようなものを作っていたので, 「全部オブジェクト・ネットワークのまま, メモリに入れとけばいいじゃん」とか, 「RDBMSったって, 巨大な表が1つだけあればいいんだよ」とか, 「所詮はみんなハッシュ表なんだから, そんなストレージを作ろうよ」とか言っては, DBAといわれる人たちに白眼視されていたわけです.

さて, 時は流れ, noSQLと言われるものがもてはやされる時代になりました. 温故知新. すべてのものをRDBMSに入れようとするアーキテクチャとか, DOAなどという馬鹿なものは消えてしまえばいいのにと心から思っている今日この頃です.

そこでRedisという, vmwareがサポートするオープン・ソースなkey-value storeが2.0になり, Grailsでもサポートされたのを機に, 何回かに分けて見ていこうと思います.

とりあえず, Grailsのプラグイン GORM for Redis のユーザ・ガイドを訳してみました.


ごく短いものですが, これを見るだけでRedis, 及びそのGrailsへの統合がおよそどのようなものか, 見当が付くと思います.

この後, Redis本体を調べつつ, プラグインのコードを読んだり, Grailsで実際的なモデルやコードを書きながら, 「表」じゃない, データ・モデルを探っていこうと思います. Redis本体に直接言及するわけではなく, 外堀から征くのがうちらしいやり方だ:-)

投稿者 時刻:
登録: 投稿 (Atom)