読み出し性能と書き込み性能を選択可能なクラウドストレージ

中村 俊介　 首藤 一幸

東京工業大学

C3-3

クラウドストレージ :RDBMS に代わる大規模な分散データストア

NoSQL, ｋ ey-value store, document-oriented DB例 : memcached, Google BigTable, Amazon Dynamo, Amazon SimpleDB,

Apache Cassandra, Voldemort, Ringo, Vpork, MongoDB, CouchDB, Tokyo Cabinet/Tokyo Tyrant, Flare, ROMA, kumofs, Kai, Redis, Hadoop Hbase, Hypertable, Yahoo! PNUTS, Scalaris, Dynomite, ThruDB, Neo4j, IBM ObjectGrid, Oracle Coherence, Velocity, ….

従来の RDBMS との比較 主キーのみでのアクセスに制限 Transaction などの高機能や複雑なデータ構造を扱わない 緩い一貫性 大規模なデータに対してスケールしやすい設計

C3-3

クラウドストレージとしての RDBMS

Read-Heavy なワークロードは MySQL の方が優れている

あらゆるワークロードにおいて新しいクラウドストレージが従来の RDBMS より優れているわけではない

　 Write-Heavy ワークロードの更新遅延

　 Read-Heavy ワークロードの参照遅延

YCSB, SOCC ’10MySQL

NoSQL

Better

KVS as MySQLNoSQL

KVS as MySQL

MySQL

Better

C3-3

永続型クラウドストレージの設計書き込み性能重視 vs. 読み出し性能重視

Bigtable, Cassandra, HBase

MySQL, Sherpa

書き込み Diff Sequential Key lookup Update

読み出し Diff Merge Single Read

性能 書き込み性能重視 読み出し性能重視ストレージエンジン

Bigtable 由来 MySQL

既存の永続型クラウドストレージはwrite/read 片方の性能に偏っている

同じデータストアで様々なワークロードに対応したいCassandra の特徴を持った読み出し性能重視クラウドストレージ=> 他のソフトウェアとの組合せ・自分で新たに実装が現状

C3-3

研究の概要

成果 同じクラウドストレージ内で書き込み性能と読み出

し性能を選択可能にした Apache Cassandra に実装し、実証した

手法 分散データストアを分離

分散の仕組み + ストレージエンジン ストレージエンジンを別のものに選択可能に

C3-3

Apache Cassandra

Facebook, Digg に導入されているクラウドストレージ 特徴

単一故障点の無い非集中型分散データストア 高速な書き込み処理 複数データセンターにまたがる数百ノードでの動作を想定

データの主キー Hash 値により、そのデータの担当ノードが一意に定まる

Consistent Hashing( 非集中分散アルゴリズム )

全ノードが全部やる• Request Proxy • Data の Primary Node• 別 Data の Secondary Node

C3-3

Google Bigtable 由来のストレージエンジン~ 書き込み ~

永続性を保ちつつ , 書き込み性能を重視 Bigtable: 行の差分を Disk には Sequential Write

Disk へのランダム I/O は発生しないので非常に高速 Always Writable

Disk に書かれた内容は Write-Lock が不要

Commit

Log

Memtable

SSTable

Map<key,ColumnFamil

y>

Sequential

MemoryDisk

write

Cassandra ノード

C3-3

Google Bigtable 由来のストレージエンジン~ 読み出し ~

指定された key に対して , Memtable 上の最新 value SSTable 上の複数の古い value をマージ

読み出し性能は犠牲になる 複数回の Disk I/O Compaction や Index, Bloom Filter で性能の劣化をカバー

Commit

Log

Memtable

SSTable

Map<key,ColumnFamil

y>read Memory

Disk 複数回のDisk Random

I/Oが必要

Cassandra ノード

<k, CF1><key, CF2><key, CF3>

C3-3

MyCassandra~Cassandra with Modular Storage Engines~

Cassandra のストレージエンジンを差し替え可能に Cassandra の分散のしくみ / データモデルはそのまま 様々なワークロードに適した分散データストアを構築可能

東京工業大学 情報理工学研究科 数理・計算科学専攻中村 俊介

InnoDB

MyISAM

Memory

MySQL: 用途によってストレージエンジンが差し替え可能な RDBMSMyCassandra: 用途によってストレージエンジンが差し替え可能なクラウドストレージ

C3-3

MyCassandra: 実装 リクエスト受理と各ストレージエンジンとの間に

Storage Engine Interface を配置 ストレージエンジンの追加

JDBC など汎用的なドライバを用いて以下を実装 Connection / Put / Get

東京工業大学 情報理工学研究科 数理・計算科学専攻中村 俊介

C3-3

性能評価

ストレージエンジンの選択によって、読み出し / 書き込み性能重視を切り替えられることを確認する

測定手段 YCSB (Yahoo! Cloud Serving Benchmark) [SOCC ’10]

ストレージエンジン Bigtable (original), MySQL (InnoDB), Redis ( オンメモリ KVS)

ベンチマーク内容1. MyCassandra×6 台、 YCSB Client×1 台用意2. 1KB の values(100[Bytes]×10[columns])+key から成るレ

コードを 2,400 万件ロード3. 測定するワークロードでメモリ上キャッシュのウォームアップ4. YCSB の各ワークロードを実行5. YCSB Stat でスループットとクエリ種類別のレイテンシを計測

C3-3

YCSB ワークロードの種類

以下 4 種類を測定Workload Applicati

on Example

OperationsRatio

Record Selection

Write-Only Log Read: 0%Write: 100%

Zipfian(※)Write-Heavy Session Store Read: 50%

Write: 50%

Read-Heavy Photo tagging Read: 95%Write: 5%

Read-Only Cache Read: 100%Write: 0%

WriteHeavy

ReadHeavy

(※) Zipfian 分布 : データ鮮度とは関係なく人気が持続 一部がヘッド / 大多数がテール

C3-3

0

0.5

1

1.5

2 Avg. Write-Latency BigtableMySQL

レイテンシ : Bigtable vs. MySQL

Write-Only Write-Heavy Read-Heavy Read-Only0

0.5

1

1.5

2

2.5

3 Avg. Read-Latency

(ms)

Better

Better

(Original)

Write: Bigtable が MySQLの 41.4%

Read: MySQL が Bigtableの 36.3%

0%

0%

100% 50% 5%

50% 95% 100%

( オンメモリ KVS)

C3-3

Write-Only Write-Heavy Read-Heavy Read-Only0

5000

10000

15000

20000

25000

30000

35000

40000Max. QPS for 40 Clients

BigtableMySQLRedis

スループット : Bigtable vs. MySQL

Read Heavy Write Heavy(query/sec)

Better

QPS for Write-Heavy: Bigtable が MySQLの 5.32倍

QPS for Read-Heavy: MySQL が BigTableの 2.35倍

(original)

100:0 50:50 5:95 0:100

( オンメモリ )

想定通り、ストレージエンジンの入れ替えで、

書き込み / 読み出し性能の性質が大きく変わる

C3-3

まとめと今後の課題 クラウドストレージの read/write 性能は

ストレージエンジンに大きく依存することを実証・評価

同一システム上でストレージエンジンの選択により Workload に適したクラウドストレージに

課題 MyCassandra Cluster: 異なるストレージエンジン

の組み合わせによる read/write 性能の両立

C3-3

関連研究 Modular なデータストア

Modular Data Storage with Anvil, SOSP ’09 １ノードの話で、分散環境を対象としていない

Cloudy: A Modular Cloud Storage System, VLDB ’10 実験評価はされていない

ストレージエンジンを選択可能なデータストア RDB: MySQL ストレージエンジン 分散データストア : Amazon Dynamo, SOSP ’07

全体の性能と永続化の対比はあったが、読み出し vs. 書き込みという観点はなかった

C3-3

Any Questions?

• モジュラーなクラウドストレージ• ワークロードに応じて足回りを変更可能• 組合せで両立も可能 (今後・評価済 )

東京工業大学 情報理工学研究科 数理・計算科学専攻中村 俊介

C3-3

Cassandra: 遅延の分布

Latency (msec)

リク

エス

ト数 Better

0 1000

Write vs. Read (YCSB Benchmark)

Read平均

6.16ms

Write平均

0.69ms

Latency (ms)

Write

Read

Average 0.69 6.16

95thPercentile

1.0 21.0

99thPercentile

2.0 51.0

Max 27,927

34,391

write と read を同比率のワークロードで 100 万件測定

レプリカ数 : 3データロード数 : 2,000 万件

10 100

【予備 1】

MyCassandra: Storage Engine Interface

各ストレージの Java API を用いて初期化 (DB の接続 ) と put / get関数を実装するだけ

【予備 2】

スループット : HDD vs. SSD

Writ

e-Onl

y

Writ

e-Hea

vy

Read-

Heavy

Read-

Only

05000

10000150002000025000300003500040000 Bigtable HDD

SSD

• HDD と SSD で性能の傾向は同じ HDD SSD

メーカー

Western digital 1TB

Crucial 128GB

Seek

200.6 ( 回 /sec)

8502.0 ( 回/sec)

(qps)

Writ

e-Onl

y

Writ

e-Hea

vy

Read-

Heavy

Read-

Only

0

5000

10000

15000

20000 MySQLHDDSSD

(qps)

【予備 3】

今後 : read/write 性能の両立~MyCassandra Cluster~

ストレージの異なるノードを組み合わせてクラスタを構成 異なるストレージノードにレプリカを配置 参照は読み出し性能重視 / 更新は書き込み性能重視に同期的に その他のレプリカには非同期でクエリを実行 非集中分散の為、互いのストレージ情報を定期的に交換し合う

W

R

R W

W

Client Read

整合性をチェックして 結果を返す

非同期で整合性をチェック

data 担当ノード

Proxy

RW

RW

R

RWR

W

W R

W

ProxyClientWrite

２ノードの書き込みACK を確認して成功とみなす

非同期書き込み

RW

R

W

RW

R

W

• W: 書き込み性能重視• R: 読み出し性能重視• RW: メモリベース

RW

RW

R

RW

【予備 4】

MyCassandra Cluster の課題

レプリカの一貫性 Quorum Protocol

W( 書き込み合意数 ) + R( 読み出し合意数 ) > N( 全レプリカ数 ) 例 : W = R = N/2 + 1

これを満たすには read/write両方を同期的に行うノードが必要=>両方速いメモリベースのストレージエンジンを使う 書いてすぐ読むような場合

書き込みの全体の整合性がとれず、読み出しは書き込み性能重視の結果待ち=> クライアント側の引数で制御 ( 優先度付きキュー )

Network Proximity との両立 読み出し先のプライマリノード選択

同一ラック /DC 内の書き込み性能重視ノード 別ラック /DC 内の読み出し性能重視ノード

ストレージ依存のアクセスによる負荷不均一=> 各ホストに異なるストレージのノードを複数配置

【予備 5】