TSOサーバのトランザクションの情報管理について
TSOサーバでは以下の情報を管理しています。
- 成功したトランザクションの開始時間とコミット時間
- 各Rowの最終コミット時間
- アボートされたトランザクションの開始時間
- LowWatermark
1は、Timestampから、そのトランザクションが成功したかどうかの判定する場合などに使われています。
2は、変更されたRowに対して競合がないかを確認するために使われる情報です。
3は、コミットが失敗した場合に、クライアント側でクリーンナップ処理が行われていないものを保持しています。
この情報は、クライアント側でコミットされていないデータを読み込まないようにするために使われます。クリーンナップ処理が完了したら削除されます。
4に関しては、上記の情報をすべてメモリに保持しておくためには、大きなメモリ容量が必要になってしまいます。
そこでOmidは、古いトランザクション情報に関しては削除します。4はメモリから削除されたトランザクション情報のTimestampになります。
4より以前に開始されたトランザクションは、情報が削除されてしまっているため、正しく実行することができないので、アボートさせるという処理を行います。
保持しておくトランザクション情報のメモリ量に関しては設定可能となっています。
また、1、3、4についてはクライアント側にもレプリケーションされます。
これにより、クライアントはそれらの情報に関してTSOサーバに問い合わせる必要がありません。
まとめ
今回は、本連載の最後のテーマとして、HBaseでトランザクションを扱うことのできる「Omid」というライブラリを紹介しました。ある程度のスケーラビリティを犠牲にする必要がありますが、それなりにパフォーマンスも出るようなので選択肢の一つになり得るのではないかと筆者は考えています。
本連載では、初めてHBaseを使う方を対象に、HBaseのアーキテクチャの説明やHBaseのデータモデリングの仕方、そしてHBaseを使ったライブラリを紹介しました。RDBと比較すると、データモデリングの仕方がかなり違っているので戸惑われた方もいると思います。筆者は、株式会社サイバーエージェントにおいて、実際にHBaseの運用をしています。まだ枯れた技術と呼ぶには至っていないと思いますが、それなりに安定していて、HBaseも実用段階にあると考えています。
現在、RDBやNoSQLなど、データベースソリューションがたくさんあります。HBaseを含めたNoSQLはRDBに比べて機能を制限した代わりに、スケーラビリティを確保し、大規模なデータに対して対応できるようにしたものです。それぞれの特徴を踏まえた上で適材適所で使っていくべきですが、HBaseを選定する際に本連載が参考となれば幸いです。
最後ですが、株式会社サイバーエージェントでは、Hadoop/HBaseエンジニアを募集しています。ご興味のある方はこちらからエントリーしていただければと思います。エンジニア>R&Dエンジニア>R&Dエンジニアを選択しエントリーしていただければ幸いです。
