ComSys2010 WIP(work in progress)で発表した資料です。

1. 読み出し性能と書き込み性能を両立させるクラウドストレージ 中村俊介 首藤 一幸 東京工業大学

2. クラウドストレージ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, HadoopHbase, Hypertable, PNUTS, Scalaris, Dynomite, ThruDB, Neo4j, IBM ObjectGrid, Oracle Coherence, Velocity, …. 従来のRDBMSとの比較 主キーのみでのアクセスに制限 Transactionなどの高機能や複雑なデータ構造を扱わない 緩い一貫性 スケーラブルな設計

3. クラウドストレージとしてのRDBMS あらゆるワークロードにおいて新しいクラウドストレージが従来のRDBMSより優れているわけではない Read-HeavyなワークロードはMySQLの方が優れている Read-Heavyワークロードの参照遅延 Write-Heavyワークロードの更新遅延 NoSQL NoSQL MySQL Better Better KVS as MySQL MySQL KVS as MySQL YCSB, SOCC’10

4. クラウドストレージの設計Write-Optimized vs. Read-Optimized クラウドストレージは Write/Read片方の性能に偏っている 同じシステム内で不得意なワークロードも扱えるようにしたい Cassandraのような非集中型分散/Multi-mapなデータモデルでReadが早いものが欲しい => 現状: 新しい分散データストアの実装や他のソフトウェアと組合せたりと手間が生じる

5. 研究の概要 成果 同じクラウドストレージ内で書き込み性能と読み出し性能を選択可能にした Apache Cassandraに実装し、実証した 手法 分散データストアを分離 分散の仕組み + ストレージエンジン ストレージエンジンを別のものに選択可能に

7. DataのPrimary Node

9. MyCassandraCassandra with Modular Storage Engines 東京工業大学情報理工学研究科数理・計算科学専攻 中村俊介 Cassandraのストレージエンジンを差し替え可能に Cassandraの分散のしくみ/データモデルはそのまま ワークロードに適した分散データストアを同一システム内で構築

11. ストレージエンジン追加

12. JDBCなど汎用的なドライバ用いて以下を実装

13. インスタンス初期化(dbへのconnection)

15. ワークロードの種類 以下4種類を測定 Write Heavy Read Heavy (※) Zipfian分布: データ鮮度とは関係なく人気が持続 一部がヘッド / 大多数がテール

16. レイテンシ: SSTable vs. MySQL Read Latency: MySQLがSSTableの最大49.4%速い Write Latency: SSTableがMySQLの最大41.4%速い (Original) (ms) Better Read Heavy Write Heavy

17. スループット: SSTable vs. MySQL QPS for Read-Heavy: MySQLがSSTableの2.35倍 QPS for Write-Heavy: SSTableがMySQLの5.32倍 (original) Better (Query/Sec) Read Heavy Write Heavy

18. 評価 分散データストアのRead/Write性能はストレージエンジンに大きく依存 同一データストア上でストレージエンジンの選択によりWorkloadに適したデータストアに

19. 関連研究 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という観点はなかった

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

21. 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ノード) ストレージ依存のアクセスによる負荷不均一 =>各ホストに異なるストレージのノードを複数配置

22. 東京工業大学情報理工学研究科数理・計算科学専攻 中村俊介 ご清聴ありがとうございました