読み出し性能と書き込み性能を両立させるクラウドストレー

ジ

中村 俊介　 首藤　一幸東京工業大学

クラウドストレージRDBMS に代わる分散データスト

ア NoSQL, KeyValueStore, 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, PNUTS, Scalaris, Dynomite, ThruDB, Neo4j, IBM ObjectGrid, Oracle Coherence, Velocity, ….

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

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

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

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

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

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

YCSB, SOCC’10MySQL

NoSQL

Better

KVS as MySQLNoSQL

KVS as MySQL

MySQL

Better

クラウドストレージの設計Write-Optimized vs. Read-

Optimized

Apache Cassandra, Apache HBase

MySQL,Yahoo! Sherpa

Write Diff Sequential Key lookup Update

Read Diff Merge Single Read

性能 Write-Optimized Read-Optimized

Storage 　Engine

SSTable MySQL

クラウドストレージはWrite/Read 片方の性能に偏っている

同じシステム内で不得意なワークロードも扱えるようにしたい

Cassandra のような非集中型分散 /Multi-map なデータモデルで Read が早いものが欲しい=> 　現状 : 新しい分散データストアの実装や他のソフトウェアと組合せたりと手間が生じる

研究の概要 成果

同じクラウドストレージ内で書き込み性能と読み出し性能を選択可能にした

Apache Cassandra に実装し、実証した

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

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

NoSQLApache Cassandra

Facebook, Digg に導入されている NoSQL

特徴 単一故障点の無い非集中型分散データストア 高速な書き込み処理 複数 DC に跨る数百台ノード上で動作

Num of Replica=2

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

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

各ノードの役割• Request Proxy • Data の Primary Node• 別 Data の Succsessor Node

Cassandra書き込み重視な設計

SSTable: Row の差分を Disk に Sequential Write Disk へのランダム I/O は発生しないので非常に高速

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

<Key, CF>

　 Read は差分のマージ処理で複数回 Disk I/O が発生

MyCassandraCassandra with Modular Storage Engines

Cassandra のストレージエンジンを差し替え可能に

Cassandra の分散のしくみ / データモデルはそのまま

ワークロードに適した分散データストアを同一システム内で構築

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

MyCassandra 実装 Request 受理とストレージの間に Storage Engine Interface を配置 ストレージエンジン追加

JDBC など汎用的なドライバ用いて以下を実装インスタンス初期化 (db への connection) データの Put/Get 関数

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

性能評価 ストレージエンジンの選択によって、読み出し／書き出し性能

重視を切り替えられることを確認する

測定手段 YCSB(Yahoo! Cloud Serving Benchmark)

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

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

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

ワークロードの種類 以下 4 種類を測定

Workload Operations

Record Selection

App. Example

Update-Only Read: 0%Update: 100%

Zipfian(※) Log

Update-Heavy Read: 50%Update: 50%

Session Store

Read-Heavy Read: 95%Update: 5%

Photo tagging

Read-Only Read: 100%Update: 0%

Cache

WriteHeavy

ReadHeavy

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

レイテンシ : SSTable vs. MySQL

Update(W

-Only)

Update(W

-Heavy

)

Read(W-H

eavy)

Update(R

-Heavy

)

Read(R-H

eavy)

Read(R-O

nly)0

0.5

1

1.5

2

2.5

3 Avg. Latency for 5,000qps SSTable

MySQL

Redis

(ms)

Better

Read Heavy Write Heavy

Write Latency: SSTable が MySQL の最大41.4% 速い

Read Latency: MySQL が SSTable の最大49.4% 速い

(Original)

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

5000

10000

15000

20000

25000

30000

35000

40000Max. QPS for 40 Clients

SSTableMySQLRedis

スループット : SSTable vs. MySQL

Read Heavy Write Heavy(Query/Sec)

Better

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

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

(original)

評価 分散データストアの Read/Write 性能は

ストレージエンジンに大きく依存

同一データストア上でストレージエンジンの選択により Workload に適したデータストアに

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

Modular Data Storage with Anvil, SOSP ’09 １ノードの話である

Cloudy: A Modular Cloud Storage System, VLDB ’10 効果の実証はされていない

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

全体の性能と永続化の対比はあったが、 Read vs. Write という観点はなかった

今後MyCassandra

Cluster

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

MyCassandra Cluster課題

レプリカの一貫性 Quorum Protocol (W+R > N) を満たすには Read/Write の両方を同期的に

行うノードが必要=>両方速い Redis( オンメモリ KVS) を使う 書いてすぐ読むような場合

Redis と MySQL の整合性がとれていないと、 SSTable の結果待ち=> Cassandra は Consistent Level をクライアント側で決めるので、そこで調整=> 同一 Proxy 上なら全レプリカへの書き込み未完了フラグを用意

Network Proximity との両立 参照クエリ先のプライマリノード選択

( 同一ラック /DC 内の SSTable ノード ) OR ( 別ラック /DC 内の MySQL ノード )

ストレージ依存のアクセスによる負荷不均一

=> 各ホストに異なるストレージのノードを複数配置

ご清聴ありがとうございました

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