Immutable Indexing
Immutable Indexingは、一度書き込んだらそのデータに対して変更をしないユースケースに用います。例としては、ログデータをためていくようなケースを挙げることができると思います。
Immutable Indexingでは、クライアントサイドでインデックスを管理します。
Immutable Indexingでは、データの変更時にセカンダリインデックスに対してその変更を反映しません。
データに対して変更をしない前提で設計されているので、Mutable Indexingと比べて書き込み時のオーバヘッドが少ないという特徴があります。
Immutable Indexingを使いたい場合は、以下のように、テーブル作成時にIMMUTABLE_ROWS=trueをつけるだけです。その他は、Mutable Indexingと同様です。
0: jdbc:phoenix:localhost> CREATE TABLE TBL2 ( . . . . . . . . . . . . .> COL1 VARCHAR NOT NULL PRIMARY KEY, . . . . . . . . . . . . .> COL2 VARCHAR . . . . . . . . . . . . .> ) IMMUTABLE_ROWS=true;
セカンダリインデックスの整合性について
ここで、セカンダリインデックスの整合性について簡単に説明します。
HBaseでは、Row単位のトランザクションしかないことは何度も説明していますが、Phoenixではセカンダリインデックスを別Tableに保存しているので、セカンダリインデックスと実データがずれてしまう可能性があるように思えます。
Phoenixでは、最初に説明したコプロセッサを用いることで、WALの書き込みに成功した後にセカンダリインデックスを作成しています。
順番としては、必ずセカンダリインデックスが作成された後に実データが作成されます。この間に、小さな時間差がありますが、Phoenixではこの時間差は問題ないものとしています。
実際に各クエリでは、セカンダリインデックスか実データのどちらかにしかScanをしないので、問題ないように思います。また、障害時にHBaseはWALからデータを復旧する処理を行います。
Phoenixは、ここでもコプロセッサを用いて、データ復旧と同時にセカンダリインデックスも復旧します。このようにすることで、セカンダリインデックスと実データの整合性を担保しています。
まとめ
前回から引き続き、Phoenixについて紹介してきました。Phoenixを使うことで、SQLを用いてHBaseをRDBのように扱えることがお分かりいただけたと思います。
Phoenixには、シーケンスやビュー（両方とも3.0 releaseから）など、今回紹介していない機能もあります。興味のある方は、冒頭にも書きましたが以下のWebサイトもご覧いただければと思います。
次回は、本連載の最後のテーマとして、HBaseでトランザクションを扱うことができるomidというライブラリを紹介したいと思います。
また、株式会社サイバーエージェントでは、Hadoop/HBaseエンジニアを募集しています。ご興味のある方はこちらからエントリーしていただければと思います。エンジニア>R&Dエンジニア>R&Dエンジニアを選択しエントリーしていただければ幸いです。
