Comparison of Transactional Libraries for HBase

Comparison of Transactional
Libraries for HBase
Toshihiro Suzuki
Solutions Engineer, Hortonworks
© Hortonworks Inc. 2011 – 2015. All Rights Reserved

2 © Hortonworks Inc. 2011 – 2016. All Rights Reserved
⾃⼰紹介
鈴⽊俊裕(すずきとしひろ)
Ã Solutions Engineer, Hortonworks
Ã 7⽉からHortonworksにジョイン
Ã 前職は⼤⼿Web企業
– Hadoop/Hiveを⽤いたログ解析基盤の開発・運⽤(5年)
– HBaseを⽤いたソーシャルグラフDB(3年)
Ã 著書「HBase徹底⼊⾨」
Ã 最近はScalaを勉強しようと思っている
Ã Twitter: @brfrn169

アジェンダ
Ã 背景
– トランザクションについて
– HBaseについて
– HBaseにおけるトランザクションについて
Ã Tephraについて
Ã Omidについて
Ã Tephra vs Omid
– 機能
– ベンチマーク
Ã まとめ

背景

トランザクション処理とは
Ã トランザクション
– データに対する⼀連の操作を⼀つにまとめた単位のこと
Ã ⼀般的なOLTPでは、複数のトランザクションが同時並⾏で処
理される
Ã 複数のトランザクションが整合性を守って⾛るように管理す
る機構が必要
– RDBMSでは標準的に⼊っている機構

Ã 例
– ⼝座Aから⼝座Bに1,000ドル移動させたいという銀⾏のトランザ
クション
• (1)⼝座Aに1000ドル以上⼊っていたら、(2)⼝座Aから-1000ドル、(3)
⼝座Bに+1000ドル
• 起こりうる不整合ケースの例
– 引き落としが成功して、⼊⾦が失敗した場合
– 同時に上記のトランザクションが発⽣し、(1)を同時に実⾏してし
まった場合に⼝座Aの残⾦がマイナスになる可能性
» ⼝座Aの残⾦が1000ドルだった場合
• T1: (1) ok (2) A – 1000 (3) B + 1000
• T2: (1)ok (2) A – 1000 (3) B + 1000
» 結果として⼝座Aの残⾦は-1000ドルになってしまう

Ã ACIDというトランザクションが満たすべき技術要件
– Atomicity
• 結果がAll-or-Nothingとなること
– Consistency
• ⼀貫性を守ること
– Isolation
• 過程が他のトランザクションから⾒えないこと
– Durability
• (障害が発⽣したとしても)結果が永続化されること

なぜトランザクション管理機構が必要なのか
Ã アプリケーションの開発を容易にする
– すべてのクライアントが整合性のとれたデータを⾒ることを保証
– 同時に実⾏される更新からデータを保護
– 更新が失敗した時などのハンドリング
– インデックスとデータの整合性も保証
Ã 逆にトランザクション管理機構がなかったら上記の保証を全
てアプリケーションでやる必要がある

なぜトランザクション管理機構が必要なのか
Ã アプリケーションの開発を容易にする
– すべてのクライアントが整合性のとれたデータを⾒ることを保証
– 同時に実⾏される更新からデータを保護
– 更新が失敗した時などのハンドリング
– インデックスとデータの整合性も保証
Ã 逆にトランザクション管理機構がなかったら上記の保証を全
てアプリケーションでやる必要がある
HBaseでこれを実現するためのライブラリを調査した

HBaseについて
Ã Googleの「Bigtable」のオープンソースクローン
Ã いわゆる「NoSQL」の⼀つ
Ã ペタバイトスケールの分散ストレージ
– ⾼可⽤性
– スケーラブル
– 低レイテンシー
Ã よく使われるユースケース
– ユーザのセッションDB
– オブジェクトストア/メッセージストア
– センサー系のアプリケーションのストレージ
– グラフデータのためのストレージ

HBaseのアーキテクチャ
Master
RegionServer RegionServer RegionServer
HDFS
Zookeeper
Client

HBaseのアーキテクチャ
Ã TableのデータはRegionに分割
– RegionはいずれかのRegionServer
に割り当てられる
Ã RegionServerがダウンした場合
は割り当てられていたRegionは
フェイルオーバされる
Ã サイズが⼤きくなったRegionは分
割することが可能
Region1
RegionServers
Region2
Region3
Region4
Region4
Region6

HBaseのデータモデル
Ã 分散ソートマップ
– (row key, column, timestamp) -> value
• columnはcolumn familyとcolumn qualifierで構成される
• row key, columnでソートされている
• timestampはバージョンを表している
– Regionはrow keyの範囲で分割される
row key column timestamp value
row1 cf:col1 1000 value2

HBaseにおけるトランザクションについて
Ã Row内の更新はアトミックに⾏われる
– 複数columnを同時に変更しても途中の状態が⾒えることはない
– IncrementやCASも可能
Ã Region内のバッチ処理もアトミックに⾏うことが可能
Ã 複数Regionにまたがる更新をアトミックに⾏うことはできない
Ã 複数Tableにまたがる更新もアトミックに⾏うことはできない
Ã 複数RPCの更新もアトミックに⾏うことはできない

HBaseにおけるトランザクションについて
Ã Row内の更新はアトミックに⾏われる
– 複数columnを同時に変更しても途中の状態が⾒えることはない
– IncrementやCASも可能
Ã Region内のバッチ処理もアトミックに⾏うことが可能
Ã 複数Regionにまたがる更新をアトミックに⾏うことはできない
Ã 複数Tableにまたがる更新もアトミックに⾏うことはできない
Ã 複数RPCの更新もアトミックに⾏うことはできない
HBaseは限定されたトランザクション管理機構しかない

HBase上でトランザクションを実現しているライブラリ
Ã Tephra
Ã Omid
Ã Trafodion
Ã Themis

Tephraについて

Tephra
Ã Apache Incubatorプロジェクト
Ã Snapshot Isolationを実現
– Multi Version Concurrency Control
– Optimistic Concurrency Control
Ã Phoenixのトランザクション機能を実現するために⽤いられ
ている

Snapshot Isolation
Ã 分離レベルの⼀つ
Ã 以下の性質を持つ
– トランザクションは⼀貫性のあるデータベースのスナップショッ
ト(トランザクション開始時に存在していた最後にコミットされた
値)を読む
– トランザクションの更新がスナップショット以降に他のトランザ
クションがコミットした更新と競合しない場合に限りトランザク
ションが成功する

Multi Version Concurrency Control
Ã トランザクションを開始時点のスナップショットを読むとい
うやり⽅なので複数バージョンが存在できなければならない
Ã HBaseのバージョン(timestamp)を利⽤した実装
Ã トランザクション内すべての更新は同じバージョン(トランザ
クションID)を使って書き込まれる
Ã トランザクション内の読み込みは、コミットされてないトラ
ンザクションを除外する
– データ取得時にtimestampの範囲を指定する
Ã ⾃分のコミットされていない更新は⾒える

Optimistic Concurrency Control
Ã いわゆる楽観ロック
Ã トランザクションの開始時には特に排他制御を⾏わず、コ
ミット時に競合の検出を⾏うやり⽅
Ã 対照的なやり⽅としてはPessimistic Concurrency Control
– いわゆる悲観ロック
– トランザクション開始時に排他制御(主にロック等)を⾏う⽅法
Ã メリット
– Tableやrowに対するロックのコストの回避
– デットロックやロックエスカレーションの回避
– 短いトランザクションにおいてコストが低くなる

Tephraのアーキテクチャ
Client 1
Client 2
・
・
・
Client N
HBase
Zookeeper
Tx Server
(active)
Tx Server
(stanby)
TransactionProcessor
Coprocessor

トランザクションのライフサイクル
start tx
in progress
Client Tx serverRPC API
do work
try commit
try abort
start tx
check conflicts
complete
invalid
start
commit
none
abort
invalidate
timeout
rollback
failed
failed
succeeded

トランザクションの流れ
Client 1
Tx Server
write = 1002
read = 1001
Client 2
row
key
column time
stamp
value
row cf:col 1001 10
HBase

Client 1
Tx Server
write = 1002
read = 1001
write = 1002
read = 1001
Client 2
start
row
key
column time
stamp
value
row cf:col 1001 10
HBase

Client 1
Tx Server
write = 1003
read = 1001
inprogress=[1002]
write = 1002
read = 1001
Client 2
start
row
key
column time
stamp
value
row cf:col 1001 10
HBase

Client 1
Tx Server
write = 1003
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
HBase
write = 1002
read = 1001
Client 2
increment

Client 1
Tx Server
write = 1003
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
HBase
write = 1002
read = 1001
Client 2
increment

Client 1
Tx Server
write = 1003
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
HBase
write = 1002
read = 1001
Client 2
start
write = 1003
read = 1001
exclude=[1002]

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002, 1003]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
HBase
write = 1002
read = 1001
Client 2
start
write = 1003
read = 1001
exclude=[1002]

Client 1
Tx Server
write = 1004
read = 1001
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
write = 1003
read = 1001
exclude=[1002]
increment

Client 1
Tx Server
write = 1004
read = 1001
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
write = 1003
read = 1001
exclude=[1002]
commit

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
write = 1003
read = 1001
exclude=[1002]
commit

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
commit

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
conflict!

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
rollback

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
rollback

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
abort

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
abort

Client 1
Tx Server
write = 1004
read = 1003
inprogress=[]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
abort

Client 1
Tx Server
write = 1005
read = 1003
inprogress=[]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1003 11
HBase
Client 2
write = 1004
read = 1003
start

Client 1
Tx Server
write = 1005
read = 1003
inprogress=[]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1003 11
HBase
Client 2
write = 1004
read = 1003
read

トランザクションの流れ(ロールバックに失敗した時)
Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
conflict!

Client 1
Tx Server
write = 1004
read = 1001
inprogress=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
rollback

Client 1
Tx Server
write = 1004
read = 1003
inprogress=[]
invalid=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
write = 1002
read = 1001
Client 2
invalidate

Client 1
Tx Server
write = 1005
read = 1003
inprogress=[]
invalid=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
Client 2
start
write = 1004
read = 1003
exclude=[1002]

Client 1
Tx Server
write = 1005
read = 1003
inprogress=[]
invalid=[1002]
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col 1002 11
row cf:col 1003 11
HBase
Client 2
read
write = 1004
read = 1003
exclude=[1002]
invisible!

トランザクションの流れのポイント
Ã Transaction Server
– トランザクションIDを管理
• Writeポインタ、Readポインタ
– トランザクションの状態を管理
• in-progress, committed, invalid
Ã トランザクション開始時にクライアントは以下を受け取る
– Writeポインタ: HBaseへ書き込むtimestamp
– Readポインタ: HBaseから読み込む上限のtimestamp
– Excludes: 読み込まないtimestamp
Ã 競合の検出はTransaction Serverが⾏う
Ã 競合が検出されたらクライアントがロールバックする

Omidについて

Omid
Ã Apache Incubatorプロジェクト
Ã Snapshot Isolation
– Multi Version Concurrency Control
– Lock-free
Ã HiveのMetastoreの実装に⽤いられている
Ã Yahooの本番環境で使われている

Omidのアーキテクチャ
Transactional
Client
HBase
The Server Oracle /
Timestamp Oracle
Commit
Table
App Table /
Shadow Cells
Compactor
(Coprocessor)

Client 1
row
key
column time
stamp
value
row cf:col 1001 10
row cf:col_sc 1001 1002
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table

Client 1
row
key
column time
stamp
value
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
shadow cell
Commit Table
commit time

Client 1
row
key
column time
stamp
value
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1003
begin

Client 1
row
key
column time
stamp
value
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
begin
start time = 1003

Client 1
row
key
column time
stamp
value
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
increment
start time = 1003

Client 1
row
key
column time
stamp
value
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
increment
start time = 1003
取得したいcellに対応す
る(timestampが一致する)
shadow cellを取得

Client 1
row
key
column time
stamp
value
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
increment
start time = 1003
そのshadow cellのvalue (1002)
よりstart time(1003)が大きいの
でスナップショットに入れること
ができる

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
increment
start time = 1003

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004commit
start time = 1003

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
start time = 1003
競合の検出
何もなければ…
commit

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
1003 1004
TSO/TO
Client 2
App Table
Commit Table
start time = 1003
timestamp = 1005
Commit Tableへ
書き込み

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
1003 1004
TSO/TO
Client 2
App Table
Commit Table
start time = 1003
commit time = 1004
timestamp = 1005
commit time

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
1003 1004
TSO/TO
Client 2
App Table
Commit Table
start time = 1003
commit time = 1004
timestamp = 1005
shadow cellの書き込み

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
start time = 1003
commit time = 1004
timestamp = 1005
Commit Table
から削除

トランザクションの流れ(競合が発⽣した時)
Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
increment
start time = 1003

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1004
start time = 1003
begin

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
begin
start time = 1004

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
increment

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
increment
取得したいcellに対応する
shadow cellが存在しない

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
increment
Commit Tableに存在する
かも確認する

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
increment
Commit Tableにも存在しな
いのでスナップショットに入
れることはできない

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
increment
取得したいcellに対応する
shadow cellが存在する

Client 1
row
key
column time
stamp
value
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
そのshadow cellのvalue (1002)
よりstart time(1004)が大きいの
でスナップショットに入れること
ができる
increment

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
increment

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1005
start time = 1003
start time = 1004
commit
競合の検出
何もなければ…

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
1004 1005
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1006
start time = 1003
start time = 1004
Commit Tableへ
書き込み

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
1004 1005
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1006
start time = 1003
start time = 1004
commit time = 1005
commit time

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
1004 1005
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1006
start time = 1003
start time = 1004
commit time = 1005
shadow cellの書き込み

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1006
start time = 1003
start time = 1004
commit time = 1005
Commit Table
から削除

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1006
start time = 1003
commit

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1006
start time = 1003
commit
競合発生！

Client 1
row
key
column time
stamp
value
row cf:col 1004 11
row cf:col 1003 11
row cf:col 1001 10
start
time
commit
time
TSO/TO
Client 2
App Table
Commit Table
timestamp = 1006
トランザクション
はabortされ
rollbackする

トランザクションの流れのポイント
Ã トランザクション開始時にTSO/TOからstart timeを受け取
る
– それがトランザクションを表すトラザクションIDとなる
– 読み込みにも書き込みにも使われる
Ã Shadow Cell
– そのデータがコミットされているかどうかの判定
– どのtimestmapにコミットされたか(commit time)
Ã 競合の検出はTSO/TOで⾏われる
Ã 競合が検出されたらクライアントはロールバックを⾏う

Tephra vs Omid

TephraとOmidの⽐較表
Tephra Omid
バージョン 0.7.1 0.8.2.0
プロジェクト Apache Incubator Apache Incubator
実装言語 Java Java
分離レベル Snapshot Isolation Snapshot Isolation
実装 MVCC + OCC MVCC + lock-free
API Java API (Phoenix経由でJDBC, REST等) Java API
対応している操作 get, put, delete, exists, scan, batch get, put, delete, scan
HA 対応対応
Read Only Transaction 非対応対応
大きなユースケース Phoenix Hive Metastore
ドキュメント
(個人的な感想)
△ △

ベンチマーク
Ã ※結果はあくまでも参考値です。環境や設定、ワークロード
によって結果は⼤きく変わる可能性があります。もしこれら
のライブラリを使う場合は別途検証することをお勧めします
Ã 環境
– Master × 1 CPU 4core, Memory 8GB
– RegionServer × 3 CPU 4core, Memory 8GB
– Transaction Server, TSO × 1 CPU 4core, Memory 8GB
– 負荷を掛けるサーバ × 1 CPU 4core, Memory 8GB

ベンチマーク
Ã ワークロード
– トランザクション開始
– 1000個のRowの中からランダムに選択
– 選択したRowに対してGet
– 選択したRowに対してPut
– トランザクション終了
– 100スレッドで上記ワークロードを30分間実⾏
• HBase直接(ライブラリなし)、Tephra、 Omid
– 競合は3〜15%位発⽣していた

ベンチマーク
Ã 結果 HBase直接スループット (req/sec)
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
0
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
720
750
780
810
840
870
900
930
960
990
1020
1050
1080
1110
1140
1170
1200
1230
1260
1290
1320
1350
1380
1410
1440
1470
1500
1530
1560
1590
1620
1650
1680
1710
1740
1770
1800
hbase throughput (req/sec)

ベンチマーク
Ã 結果 HBase直接レイテンシ (ms)
0
5
10
15
20
25
30
35
40
45
50
0
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
720
750
780
810
840
870
900
930
960
990
1020
1050
1080
1110
1140
1170
1200
1230
1260
1290
1320
1350
1380
1410
1440
1470
1500
1530
1560
1590
1620
1650
1680
1710
1740
1770
1800
hbase latency (ms)
mean p50 p75 p95 p98 p99

ベンチマーク
Ã 結果 Tephra スループット (req/sec)
0
200
400
600
800
1000
1200
1400
1600
0
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
720
750
780
810
840
870
900
930
960
990
1020
1050
1080
1110
1140
1170
1200
1230
1260
1290
1320
1350
1380
1410
1440
1470
1500
1530
1560
1590
1620
1650
1680
1710
1740
1770
1800
tephra throughput (req/sec)

ベンチマーク
Ã 結果 Tephra レイテンシ (ms)
0
20
40
60
80
100
120
140
0
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
720
750
780
810
840
870
900
930
960
990
1020
1050
1080
1110
1140
1170
1200
1230
1260
1290
1320
1350
1380
1410
1440
1470
1500
1530
1560
1590
1620
1650
1680
1710
1740
1770
1800
tephra latency (ms)
mean p50 p75 p95 p98 p99

ベンチマーク
Ã 結果 Omid スループット (req/sec)
0
500
1000
1500
2000
2500
0
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
720
750
780
810
840
870
900
930
960
990
1020
1050
1080
1110
1140
1170
1200
1230
1260
1290
1320
1350
1380
1410
1440
1470
1500
1530
1560
1590
1620
1650
1680
1710
1740
1770
1800
omid throughput (req/sec)

ベンチマーク
Ã 結果 Omid レイテンシ (ms)
0
20
40
60
80
100
120
140
160
180
200
0
30
60
90
120
150
180
210
240
270
300
330
360
390
420
450
480
510
540
570
600
630
660
690
720
750
780
810
840
870
900
930
960
990
1020
1050
1080
1110
1140
1170
1200
1230
1260
1290
1320
1350
1380
1410
1440
1470
1500
1530
1560
1590
1620
1650
1680
1710
1740
1770
1800
omid latency (ms)
mean p50 p75 p95 p98 p99

ベンチマーク
Ã 考察
– HBase直接と⽐較して、Tephra, Omidを使うとスループットが数
分の1まで遅くなる
– TephraとOmidを⽐較すると若⼲Omidの⽅がパフォーマンスが良
かった
• 今回はパフォーマンスチューニングまではできていないので、今後やっ
てみたい
– TephraのTransaction Serverと⽐較して、OmidのTSOの⽅が負
荷が⾼かった

まとめ

まとめ
Ã HBase上でトランザクションを実現するライブラリについて
解説
– Tephra
– Omid
Ã Tephra vs Omid
– 機能の違い
– 簡単なベンチマーク

Thank You

Comparison of Transactional Libraries for HBase

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Comparison of Transactional Libraries for HBase (20)

More from DataWorks Summit/Hadoop Summit (20)

Comparison of Transactional Libraries for HBase