DEIM2011(http://db-event.jpn.org/deim2011/)で発表したスライドです。次回の発表からは”選択できる”から”両立させる”に変わるのでお楽しみに!!

1. C3-3 読み出し性能と書き込み性能を選択可能なクラウドストレージ 中村俊介 首藤一幸 東京工業大学

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

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

4. C3-3 永続型クラウドストレージの設計書き込み性能重視 vs. 読み出し性能重視 既存の永続型クラウドストレージは write/read片方の性能に偏っている 同じデータストアで様々なワークロードに対応したい Cassandraの特徴を持った読み出し性能重視クラウドストレージ => 他のソフトウェアとの組合せ・自分で新たに実装が現状

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

7. DataのPrimary Node

9. Google Bigtable由来のストレージエンジン~読み出し~ C3-3 指定されたkeyに対して, Memtable上の最新value SSTable上の複数の古いvalueをマージ 読み出し性能は犠牲になる 複数回のDisk I/O CompactionやIndex, Bloom Filterで性能の劣化をカバー Cassandraノード Map <key,ColumnFamily> read Memtable Memory Disk 複数回の Disk Random I/O が必要 SSTable CommitLog <k, CF1> <key, CF2> <key, CF3>

10. C3-3 MyCassandra~Cassandra with Modular Storage Engines~ 東京工業大学情報理工学研究科数理・計算科学専攻 中村俊介 Cassandraのストレージエンジンを差し替え可能に Cassandraの分散のしくみ/データモデルはそのまま 様々なワークロードに適した分散データストアを構築可能 InnoDB MyISAM Memory MySQL: 用途によってストレージエンジンが差し替え可能なRDBMS MyCassandra: 用途によってストレージエンジンが差し替え可能なクラウドストレージ

11. MyCassandra: 実装 C3-3 東京工業大学情報理工学研究科数理・計算科学専攻 中村俊介 リクエスト受理と各ストレージエンジンとの間にStorage Engine Interfaceを配置 ストレージエンジンの追加 JDBCなど汎用的なドライバを用いて以下を実装 Connection / Put / Get

12. 性能評価 C3-3 ストレージエンジンの選択によって、読み出し/書き込み性能重視を切り替えられることを確認する 測定手段 YCSB (Yahoo! Cloud Serving Benchmark) [SOCC ’10] ストレージエンジン Bigtable (original), MySQL (InnoDB), Redis (オンメモリKVS) ベンチマーク内容 MyCassandra×6台、YCSB Client×1台用意 1KBのvalues(100[Bytes]×10[columns])+keyから成るレコードを2,400万件ロード 測定するワークロードでメモリ上キャッシュのウォームアップ YCSBの各ワークロードを実行 YCSB Statでスループットとクエリ種類別のレイテンシを計測

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

14. レイテンシ: Bigtable vs. MySQL C3-3 (Original) Write: BigtableがMySQLの41.4% (オンメモリKVS) Better 0% 50% 100% 5% Read: MySQLがBigtableの36.3% Better 0% 50% 95% 100% (ms)

15. C3-3 スループット: Bigtable vs. MySQL QPS for Read-Heavy: MySQLがBigTableの2.35倍 QPS for Write-Heavy: BigtableがMySQLの5.32倍 (original) (オンメモリ) Better 0:100 50:50 5:95 100:0 想定通り、ストレージエンジンの入れ替えで、書き込み/読み出し性能の性質が大きく変わる (query/sec) Write Heavy Read Heavy

16. まとめと今後の課題 C3-3 クラウドストレージのread/write性能はストレージエンジンに大きく依存することを実証・評価 同一システム上でストレージエンジンの選択によりWorkloadに適したクラウドストレージに 課題 MyCassandra Cluster: 異なるストレージエンジンの組み合わせによるread/write性能の両立

17. 関連研究 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

19. ワークロードに応じて足回りを変更可能

21. MyCassandra: Storage Engine Interface 【予備2】 各ストレージのJava APIを用いて初期化(DBの接続)とput / get関数を実装するだけ

23. R: 読み出し性能重視

24. RW: メモリベースClient Client Proxy Proxy Write Read RW RW R R W W W W 非同期で整合性をチェック R RW R RW ２ノードの書き込みACKを確認して成功とみなす 整合性をチェックして 結果を返す 非同期書き込み R RW R RW W W W W R R RW RW data担当ノード ストレージの異なるノードを組み合わせてクラスタを構成 異なるストレージノードにレプリカを配置 参照は読み出し性能重視 / 更新は書き込み性能重視に同期的に その他のレプリカには非同期でクエリを実行 非集中分散の為、互いのストレージ情報を定期的に交換し合う

25. MyCassandra Clusterの課題 【予備5】 レプリカの一貫性 Quorum Protocol W(書き込み合意数) + R(読み出し合意数) > N(全レプリカ数) 例: W = R = N/2 + 1 これを満たすにはread/write両方を同期的に行うノードが必要 =>両方速いメモリベースのストレージエンジンを使う 書いてすぐ読むような場合 書き込みの全体の整合性がとれず、読み出しは書き込み性能重視の結果待ち => クライアント側の引数で制御(優先度付きキュー) Network Proximityとの両立 読み出し先のプライマリノード選択 同一ラック/DC内の書き込み性能重視ノード 別ラック/DC内の読み出し性能重視ノード ストレージ依存のアクセスによる負荷不均一 =>各ホストに異なるストレージのノードを複数配置