comparison of transactional libraries for hbase

ComparisonofTransactionalLibrariesforHBaseToshihiroSuzukiSolutionsEngineer,Hortonworks

©HortonworksInc.2011– 2015.AllRightsReserved

2 ©HortonworksInc.2011– 2016.AllRightsReserved

⾃⼰紹介

鈴⽊俊裕(すずきとしひろ)Ã 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 valuerow1 cf:col1 1000 value2row1 cf:col2 1200 value4row2 cf:col1 2000 value6row3 cf:col1 1000 value3row3 cf:col1 300 value1row3 cf:col2 1500 value5


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のアーキテクチャ

Client1

Client2

・・

・

ClientN

HBase

Zookeeper

Tx Server(active)

Tx Server(stanby)

TransactionProcessorCoprocessor


トランザクションのライフサイクル

starttx

inprogress

Client Tx serverRPCAPI

dowork

trycommit

tryabort

starttx

checkconflicts

complete

invalid

start

commit

noneabort

invalidate

timeout

rollback

failed

failed

succeeded


トランザクションの流れ

Client1

Tx Server

write=1002read=1001

Client2

rowkey

column timestamp

value

row cf:col 1001 10

HBase



Client1

Tx Server

write=1002read=1001

write=1002read=1001

Client2

start

rowkey

column timestamp

value

row cf:col 1001 10

HBase



Client1

Tx Server

write=1003read=1001

inprogress=[1002]

write=1002read=1001

Client2

start

rowkey

column timestamp

value

row cf:col 1001 10

HBase



Client1

Tx Server

write=1003read=1001

inprogress=[1002]

rowkey

column timestamp

value

row cf:col 1001 10

HBase

write=1002read=1001

Client2

increment



Client1

Tx Server

write=1003read=1001

inprogress=[1002]

rowkey

column timestamp

value

row cf:col 1001 10row cf:col 1002 11

HBase

write=1002read=1001

Client2

increment



Client1

Tx Server

write=1003read=1001

inprogress=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

start

write=1003read=1001

exclude=[1002]



Client1

Tx Server

write=1004read=1001

inprogress=[1002,1003]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

start

write=1003read=1001

exclude=[1002]



Client1

Tx Server

write=1004read=1001


rowkey

column timestamp

value

row cf:col 1001 10row cf:col 1002 11row cf:col 1003 11

HBase

write=1002read=1001

Client2

write=1003read=1001

exclude=[1002]

increment



Client1

Tx Server

write=1004read=1001


rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

write=1003read=1001

exclude=[1002]

commit



Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

write=1003read=1001

exclude=[1002]

commit



Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

commit



Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

conflict!



Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

rollback



Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value

row cf:col 1001 10

row cf:col 1003 11

HBase

write=1002read=1001

Client2

rollback



Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value

row cf:col 1001 10

row cf:col 1003 11

HBase

write=1002read=1001

Client2

abort



Client1

Tx Server

write=1004read=1001inprogress=[]

rowkey

column timestamp

value

row cf:col 1001 10

row cf:col 1003 11

HBase

write=1002read=1001

Client2

abort



Client1

Tx Server


rowkey

column timestamp

value

row cf:col 1001 10

row cf:col 1003 11

HBase

write=1002read=1001

Client2

abort



Client1

Tx Server


rowkey

column timestamp

value

row cf:col 1001 10

row cf:col 1003 11

HBase

Client2

write=1004read=1003

start



Client1

Tx Server


rowkey

column timestamp

value

row cf:col 1001 10

row cf:col 1003 11

HBase

Client2

write=1004read=1003

read


トランザクションの流れ(ロールバックに失敗した時)

Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

conflict!



Client1

Tx Server

write=1004read=1001

inprogress=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

rollback



Client1

Tx Server

write=1004read=1003inprogress=[]invalid=[1002]

rowkey

column timestamp

value


HBase

write=1002read=1001

Client2

invalidate



Client1

Tx Server


rowkey

column timestamp

value


HBase

Client2

start

write=1004read=1003

exclude=[1002]



Client1

Tx Server


rowkey

column timestamp

value


HBase

Client2 read

write=1004read=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のアーキテクチャ

TransactionalClient

HBase

TheServerOracle/TimestampOracle

CommitTable

AppTable/ShadowCells

Compactor(Coprocessor)



Client1

rowkey

column timestamp

value

row cf:col 1001 10row cf:col_sc 1001 1002

starttime

committime

TSO/TO

Client2

AppTable

CommitTable



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

shadowcell

CommitTable

committime



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1003begin



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004begin

starttime=1003



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004

increment

starttime=1003



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004

increment

starttime=1003取得したいcellに対応する(timestampが一致する)

shadowcellを取得



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004

increment

starttime=1003そのshadowcellのvalue (1002)よりstarttime(1003)が大きいのでスナップショットに入れること

ができる



Client1

rowkey

column timestamp

value

row cf:col 1003 11row cf:col 1001 10row cf:col_sc 1001 1002

starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004

increment

starttime=1003



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004commit

starttime=1003



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004

starttime=1003

競合の検出何もなければ…

commit



Client1

rowkey

column timestamp

value


starttime

committime

1003 1004

TSO/TO

Client2

AppTable

CommitTable

starttime=1003

timestamp=1005

CommitTableへ書き込み



Client1

rowkey

column timestamp

value


starttime

committime

1003 1004

TSO/TO

Client2

AppTable

CommitTable

starttime=1003committime=1004

timestamp=1005committime



Client1

rowkey

column timestamp

value

row cf:col 1003 11row cf:col 1001 10row cf:col_sc 1003 1004row cf:col_sc 1001 1002

starttime

committime

1003 1004

TSO/TO

Client2

AppTable

CommitTable


timestamp=1005

shadowcellの書き込み



Client1

rowkey

column timestamp

value

row cf:col 1003 11row cf:col 1001 10row cf:col_sc 1003 1004row cf:col_sc 1001 1002

starttime

committime

TSO/TO

Client2

AppTable

CommitTable


timestamp=1005

CommitTableから削除


トランザクションの流れ(競合が発⽣した時)

Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004

increment

starttime=1003



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1004

starttime=1003begin



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003begin

starttime=1004



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004

increment



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004

increment

取得したいcellに対応するshadowcellが存在しない



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004increment

CommitTableに存在するかも確認する



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004increment

CommitTableにも存在しないのでスナップショットに入れることはできない



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004

increment

取得したいcellに対応するshadowcellが存在する



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004

そのshadowcellのvalue (1002)よりstarttime(1004)が大きいのでスナップショットに入れること

ができる

increment



Client1

rowkey

column timestamp

value

row cf:col 1004 11row cf:col 1003 11row cf:col 1001 10row cf:col_sc 1001 1002

starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004

increment



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1005

starttime=1003

starttime=1004

commit

競合の検出何もなければ…



Client1

rowkey

column timestamp

value


starttime

committime

1004 1005

TSO/TO

Client2

AppTable

CommitTable

timestamp=1006

starttime=1003

starttime=1004

CommitTableへ書き込み



Client1

rowkey

column timestamp

value


starttime

committime

1004 1005

TSO/TO

Client2

AppTable

CommitTable

timestamp=1006

starttime=1003


committime



Client1

rowkey

column timestamp

value

row cf:col 1004 11row cf:col 1003 11row cf:col 1001 10row cf:col_sc 1004 1005row cf:col_sc 1001 1002

starttime

committime

1004 1005

TSO/TO

Client2

AppTable

CommitTable

timestamp=1006

starttime=1003


shadowcellの書き込み



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1006

starttime=1003


CommitTableから削除



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1006

starttime=1003

commit



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1006

starttime=1003

commit

競合発生！



Client1

rowkey

column timestamp

value


starttime

committime

TSO/TO

Client2

AppTable

CommitTable

timestamp=1006

トランザクションはabortされrollbackする


トランザクションの流れのポイントÃ トランザクション開始時にTSO/TOからstart timeを受け取

る– それがトランザクションを表すトラザクションIDとなる– 読み込みにも書き込みにも使われる

Ã Shadow Cell– そのデータがコミットされているかどうかの判定– どのtimestmapにコミットされたか(commit time)

Ã 競合の検出はTSO/TOで⾏われるÃ 競合が検出されたらクライアントはロールバックを⾏う


TephravsOmid


TephraとOmidの⽐較表

Tephra Omidバージョン 0.7.1 0.8.2.0プロジェクト ApacheIncubator ApacheIncubator実装言語 Java Java分離レベル SnapshotIsolation SnapshotIsolation実装 MVCC+OCC MVCC +lock-freeAPI JavaAPI(Phoenix経由でJDBC,REST等) JavaAPI

対応している操作 get,put,delete,exists,scan,batch get,put,delete,scanHA 対応対応

ReadOnlyTransaction 非対応対応

大きなユースケース Phoenix HiveMetastoreドキュメント

(個人的な感想)△ △


ベンチマーク

Ã ※結果はあくまでも参考値です。環境や設定、ワークロードによって結果は⼤きく変わる可能性があります。もしこれらのライブラリを使う場合は別途検証することをお勧めします

Ã 環境– 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

hbasethroughput(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

hbaselatency(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

tephrathroughput(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

tephralatency(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

omidthroughput(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

omidlatency(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– 機能の違い– 簡単なベンチマーク


ThankYou

comparison of transactional libraries for hbase

Technology