Cassandra修行 その2
「Cassandraというものがなんだかよく分からない」 〜 NoSQLについて、鳩山由紀夫
週末プロジェクトになりつつあるCassandra修行ですが、しょっぱなから躓いている。 （経験から言えば、躓いたらほっておいて先進めばいいだけなので、躓くのを言い訳に止まっている）
さて、
あるユーザーサービスを考えてみる。ユーザー毎にページをもたせたい(http://hogehoge.com/shn/ みたいに) また認証はパスワードとか面倒なのでOpenIDにしてみよう。
というのをCassandra(とLazyboy)でやるにはどうしたらいいのかしら。
MySQLだと
MySQLでやるならこんな感じのテーブルを用意しているはずだ。
CREATE TABLE Accounts (
account_id INTEGER NOT NULL PRIMARY KEY AUTO INCREMENT,
account VARCHAR(64) NOT NULL UNIQUE,
openid_identifier VARCHAR(255) NOT NULL UNIQUE
);
アカウント情報について、「アカウントから」と「OpenIDから」の2系統からアクセスされるので、その二つをUNIQUE INDEXにした。
Cassandraだと
Cassandraの場合はひとつのColumnFamilyについて一つの順序しか持てない。今回のアプリの場合、http://hogehoge.com/shn/からshnを引っ張ってくるケースが多そうなので、とりあえずアカウント名でソートされたColumnFamilyを用意するのか
<Keyspace Name="UserData">
<ColumnFamily CompareWith="BytesType" Name="Accounts"/>
</Keyspace>
{ // Accounts
"shn" : {
"openid_identifier": "http://glucose.jp/shn"
}, ...
}
て感じだろうか。さてOpenIDからアカウントを引っ張ってくる場合はどうするのだろう。新しくColumnFamilyを定義するか、
<Keyspace Name="UserData">
<ColumnFamily CompareWith="BytesType" Name="Accounts"/>
<ColumnFamily CompareWith="BytesType" Name="Identifiers"/>
</Keyspace>
{ // Identifiers
"http://glucose.jp/shn" : {
"account": "shn"
}, ...
}
Accountsの中に特殊なRow Key(__identifiers__的な)を定義してその中に突っ込むかの2通りが思いつく。
{ // Accounts
"shn" : {
"openid_identifier": "http://glucose.jp/shn"
},
"__identifiers__" : {
"http://glucose.jp/shn": "shn"
}, ...
}
どっちが良いのかな。API的にはどっちもgetを2回呼ぶ事になるのだと思うけど、データはどのノードに配置されるのだろうか。
他のものを見てみるとtwissandraの場合前者の方法だ。こっちのBlogの例題の場合後者に近い(ちょっと用途違うけど)。 Delicious clone in cassandraの例はどうやってデータひっぱってくるのかさっぱりわからない。
DataModel - Cassandraw Wikiによると
The row key is what determines what machine data is stored on. Thus, for each key you can have data from multiple column families associated with it. However, these are logically distinct, which is why the Thrift interface is oriented around accessing one ColumnFamily per key at a time. (TODO given this, is the following JSON more confusing than helpful?)
keyによってどのノードにデータが保持されるか決まるそうなので、後者の方法だと特定のマシンにOpenIDのindex情報が固まる事になる。ここらへん、例えば「インデックス用のCFは全ノードに配置したい！」とか邪な事を考えた場合に、カスタマイズしたReplicationStorategyを書けば良さそうなところがCassandraの強みかもしれん。
Lazyboyさん
PythonのCassandra高級インタフェースであるところのLazyboyさんはViewという仕組みがあるようだ。
Lazyboy's view classes provide a way to build secondary indexes into a column family. For example, you might create a view that has only Lazyboy authors from the Users table:
というわけで、IdentifiersというViewを定義してそこのappendしたら良いかな？とやってみたら
{ // Identifiers
"shn": "shn"
}
というCFができて泣いた。ViewのKeyを決定する関数が
def _record_key(self, record=None):
"""Return the column name for a given record."""
return record.key.key if record else str(uuid.uuid1())
となっているため、User(key=shn)を突っ込むとViewのkeyもshnになっちゃう… ソース読んでて思ったのだけど、このViewはタイムライン的な奴を実装するためにあるようなので、僕のやりたい事とはちょっとずれているな。
というわけで
というわけで、玉虫色のエントリになったCassandra修行二回目。 その他参考にしたりしたページ
のような奴で、複数の画像を一枚にまとめて、リクエスト回数、ファイルサイズを節約します。