cassandraに挑戦 その5 Thrift APIの解読
cassandraは、すごい機能がそろっているようなんですが、
いかんせん、ドキュメントが少ないような気がします。
さらに、まだ日本では流行っていないのか、日本語のドキュメントも
当然ながら少ない状態です。
こういうときは、コードを読むのが一番ですが、Javaは得意ではないので、
まずはPerlのコードをさがして読んでみました。
サンプルコード:
http://cpansearch.perl.org/src/LBROCARD/Net-Cassandra-0.34/examples/simple.pl
Thrift APIの仕様はこちらにまとまっているので、
この仕様とサンプルコードを突き合わせて、
なんとなーく理解を深めてみました。
あれこれコードをいじりながら、エラーメッセージを読みつつ、
わかったことなどのまとめは以下
以上。
いかんせん、ドキュメントが少ないような気がします。
さらに、まだ日本では流行っていないのか、日本語のドキュメントも
当然ながら少ない状態です。
こういうときは、コードを読むのが一番ですが、Javaは得意ではないので、
まずはPerlのコードをさがして読んでみました。
サンプルコード:
http://cpansearch.perl.org/src/LBROCARD/Net-Cassandra-0.34/examples/simple.pl
Thrift APIの仕様はこちらにまとまっているので、
この仕様とサンプルコードを突き合わせて、
なんとなーく理解を深めてみました。
あれこれコードをいじりながら、エラーメッセージを読みつつ、
わかったことなどのまとめは以下
- 今はcassandra-0.5.1を使っているが、0.5でdeplicateするAPIと、0.6で新規に追加されるものがあるので、早めに0.6にバージョンを上げよう
- getやget_sliceなどで、任意の範囲のKeyに対するデータを一発で取得できるが、取得する際に特定のnameだけのvalueを取得したかったが、できないっぽい → その後の調査で出来そうなことが判明
- keyrangeがstartからfinishまでのもので、かつ、レスポンスには"title" columnだけを含める、というようなレスポンスフィルタができない。すべてのcolumnの結果が返る → その後の調査で出来そうなことが判明
- column数が増えることによるレスポンスデータの肥大化をどうやって防ぐかが設計時の一番の課題になりそう
- 設計の正当性はベンチで取るしかないが、どうやってベンチをとるか
- どんなデータで、どのくらいどんな問い合わせ方をするか、が性能に直結しそう
- データを扱いたいclientから直接Thrift APIを叩かせるのは危険
- サービス仕様に応じて使いやすくwrapしたHTTP IFを作るべき
- このIFはJavaで実装するのがよさげ(あまり根拠はないが、cassandraに近い部分なので、Javaで書くのがいいかな、と)
以上。