HTablePool

HBaseの0.20と0.89.20100621を見比べていて、HTablePoolというクラスの存在に気付いた。（最初、新規クラスと勘違いしたが、0.20にもちゃんと有った＾＾；）

HTableインスタンスをプールして使い回すものらしいけど、ということは、HTableはスレッドセーフではないということ？
と思って改めてHTableのJavadocを見たら、「書き込みに関してはスレッドセーフではない」と明記されていた（意訳なので解釈を間違っている可能性も…）。
確かにput()の実装を見ると、フィールドのArrayListに単純にadd()してたりするので、明らかにスレッドセーフではない＾＾；

逆にget()やgetScanner()はスレッドセーフであると解釈できる。
スキャンはScan関連インスタンスをメソッド内で作成しているだけなのでたぶん大丈夫、get()はコネクションクラスのメソッドを呼んでいるので、ぱっと見ただけでは判断できないが、たぶん大丈夫なのだろう。

じゃぁHTableを継承しているTransactionalTableはどうなんだろう？と思ったが、Javadocには何も書かれていない…。
put()とかはHTableのものをそのまま使うと同様にアウトだろうけれども、トランザクション用のput()は独自実装だから大丈夫な可能性もある…？
まぁ、「スレッドセーフである」と明示されていない以上は、「スレッドセーフでない」と仮定してプログラミングするのが常道ではあるのだが…。

HBase Shell 0.89.20100621

HBase0.89.20100621のHBase Shellをいじってみた。

まず、helpが強化されている。
help一発で全コマンドが表示されるのではなく、引数としてコマンド名やグループ名が指定できるようになった。
また、（引数なしのコマンド以外では）コマンド名だけを入力して実行することで、そのコマンドのhelpが表示される。

また、tools系のコマンドが増えている。
自分は詳しくないのでよく分からないけれども、リージョン操作系が増えているようなので、HBaseの監視やチューニングには重要なのかも？

それから、データ操作系のコマンドも多少変わっている。
使用方法自体はそんなに変わらない（中には省略的な文法が加わったものもある）が、出力されるメッセージが変更になっていたりする。

あと、HBase0.20.3で試した時にはけっこうバグがあったが、その辺りはきっちり修正されている。（久しぶりに自分で書いたページを見るまで、バグがあった事なんてすっかり忘れていたけれども＾＾；）

HBase 0.20.5と0.89.20100621

HBaseの新バージョンが出たので、変更点を調査。
といってもプログラミングするのに関係ありそうな箇所だけで、内部実装の変更点についてはノータッチ。

HBase0.20.4→0.20.5は、それほど大したことは無い。
util.BytesのtoStringBinary()が互換性の無い変更だそうだけど、影響のある人っているのかなぁ。

対して、0.20.5→0.89の変更点はさすがに多い！
ソースを比較しただけで実行もしていないけれど、クラスやメソッドが廃止になっているので、旧来のソース（プログラミング方法）そのままではコンパイルエラーになることも多そう。
特にBatchUpdateやCell・RowResultが無くなっているので、Cascadingも動かなくなっちゃうよ。
逆に追加になったクラスやメソッドもあるので、今後要調査。

あと、0.89ではcontribが無い。
メソッドに増減があるので、今までのをそのまま入れられないからかな？
トランザクションとか、ちゃんと入ってくれるだろうか。

Cassandra0.6.3

Apache Cassandraの0.6.3が出たので、ちょっとだけ確認。

使う人（プログラミングする人）から見て大きいのは、Read時のConsistencyLevel.ALLが使えるようになったのと、batch_mutate()（とDeletion）で行削除が出来るようになったことかな～。（Cassandra0.6.2では、削除対象のカラム名を全て指定しないといけなかった）

CASSANDRA-1042は、いまだ直らず…Fix予定バージョンが0.6.4になってる(苦笑)

あと、予想に反してcassandra-cli.batが直ってない…誰もCLIなんか使っていないということなのか、律儀に環境変数CASSANDRA_HOMEを指定しているから気付かないということなのか。

対ヴォルデモート Hadoop戦 勝利！

Voldemort（DB）では、読込専用のストア（テーブル）を作ることが出来る。
で、そのストア用のデータは、Hadoopを使って作成する。

このデータ作成の実験に先週は失敗した（Voldemortに負けた）が、やっと上手くいった。
要するにVoldemort起動シェル（voldemort-server.sh）で組み込んでいるHadoopのバージョン（0.18）と実際に稼動していたHadoopのバージョン（0.20）が異なっていたのがいけなかったらしい。
コンパイル時点ならまだしも、実行時に違ってちゃ、確かにダメかもしれない…(苦笑)
（publicメソッドやクラスの増減のことを考えると、コンパイル時点でもバージョンを合わせるべきではある）

DBがどの言語で実装されているかなんて、基本的にはどうでもいいはずだけど、何か障害があった時には知ってる言語（見るのに慣れている言語・環境）でないと調査しづらい面があるんだな～という事を改めて認識。

---

ところでVoldemortの身辺調査をしていてちょっと見えてきたのは、
Voldemortは上から下まで自分で全部やっている（DBとして全部作りこんでいる）というわけではなく、足元は他人に任せてフロントエンド（前面）に力を入れている感じ。
つまりバックエンドで各ノード（コンピューター）上に実際にデータを保存するにはBerkeleyDBやMySQLといった既存のRDBを利用、あるいはメモリー上にキャッシュするといった方法をとる。
フロントエンドとしてKVSをネットワーク上に分散させたり、読込専用ストアを定義してみたりといった機能をVoldemort自身が提供している。

CassandraやHBaseがファイルシステムへのアクセスも（一応）自分でやっているのとは対照的な考え方で、興味深い。