読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
Download as PPTX, PDF2 likes1,902 views
DEIM2011(http://db-event.jpn.org/deim2011/)で発表したスライドです。次回の発表からは”選択できる”から”両立させる”に変わるのでお楽しみに!!
![性能評価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でスループットとクエリ種類別のレイテンシを計測](https://image.slidesharecdn.com/deim-110323105222-phpapp01/85/DEIM2011-C3-3-12-320.jpg)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
- 2. クラウドストレージ:RDBMSに代わる大規模な分散データストアC3-3NoSQL, ｋ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. クラウドストレージとしてのRDBMSC3-3あらゆるワークロードにおいて新しいクラウドストレージが従来のRDBMSより優れているわけではないRead-HeavyなワークロードはMySQLの方が優れている Write-Heavyワークロードの更新遅延 Read-Heavyワークロードの参照遅延NoSQLBetterMySQLBetterKVS as MySQLNoSQLMySQLKVS as MySQL YCSB, SOCC ’10
- 4. C3-3永続型クラウドストレージの設計書き込み性能重視 vs. 読み出し性能重視既存の永続型クラウドストレージはwrite/read片方の性能に偏っている同じデータストアで様々なワークロードに対応したいCassandraの特徴を持った読み出し性能重視クラウドストレージ=> 他のソフトウェアとの組合せ・自分で新たに実装が現状
- 5. 研究の概要C3-3成果同じクラウドストレージ内で書き込み性能と読み出し性能を選択可能にしたApache Cassandraに実装し、実証した手法分散データストアを分離分散の仕組み + ストレージエンジンストレージエンジンを別のものに選択可能に
- 6. Apache CassandraC3-3Facebook, Diggに導入されているクラウドストレージ特徴単一故障点の無い非集中型分散データストア高速な書き込み処理複数データセンターにまたがる数百ノードでの動作を想定Consistent Hashing(非集中分散アルゴリズム)データの主キーHash値により、そのデータの担当ノードが一意に定まる全ノードが全部やる Request Proxy
- 8. 別DataのSecondary NodeGoogle Bigtable由来のストレージエンジン~書き込み~C3-3永続性を保ちつつ, 書き込み性能を重視Bigtable: 行の差分をDiskにはSequential WriteDiskへのランダムI/Oは発生しないので非常に高速Always WritableDiskに書かれた内容はWrite-Lockが不要CassandraノードMap<key,ColumnFamily>MemtableMemoryDiskwriteSSTableCommitLogSequential
- 9. Google Bigtable由来のストレージエンジン~読み出し~C3-3指定されたkeyに対して, Memtable上の最新valueSSTable上の複数の古いvalueをマージ読み出し性能は犠牲になる複数回のDisk I/OCompactionやIndex, Bloom Filterで性能の劣化をカバーCassandraノードMap<key,ColumnFamily>readMemtableMemoryDisk複数回のDisk Random I/Oが必要SSTableCommitLog<k, CF1><key, CF2><key, CF3>
- 10. C3-3MyCassandra~Cassandra with Modular Storage Engines~東京工業大学情報理工学研究科数理・計算科学専攻中村俊介Cassandraのストレージエンジンを差し替え可能にCassandraの分散のしくみ/データモデルはそのまま様々なワークロードに適した分散データストアを構築可能InnoDBMyISAMMemoryMySQL: 用途によってストレージエンジンが差し替え可能なRDBMSMyCassandra: 用途によってストレージエンジンが差し替え可能なクラウドストレージ
- 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種類を測定WriteHeavyReadHeavy(※) Zipfian分布: データ鮮度とは関係なく人気が持続一部がヘッド / 大多数がテール
- 14. レイテンシ: Bigtable vs. MySQLC3-3(Original)Write: BigtableがMySQLの41.4%(オンメモリKVS)Better0%50%100%5%Read: MySQLがBigtableの36.3%Better0%50%95%100%(ms)
- 15. C3-3スループット: Bigtable vs. MySQLQPS for Read-Heavy: MySQLがBigTableの2.35倍QPS for Write-Heavy: BigtableがMySQLの5.32倍(original)(オンメモリ)Better0:10050:505:95100:0想定通り、ストレージエンジンの入れ替えで、書き込み/読み出し性能の性質が大きく変わる(query/sec) Write Heavy Read Heavy
- 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
- 20. 組合せで両立も可能 (今後・評価済)Cassandra: 遅延の分布【予備1】writeとreadを同比率のワークロードで100万件測定レプリカ数: 3データロード数: 2,000万件Write vs. Read (YCSB Benchmark)Read平均6.16msBetterリクエスト数Write平均0.69ms0100101000Latency (msec)
- 21. MyCassandra: Storage Engine Interface【予備2】各ストレージのJava APIを用いて初期化(DBの接続)とput / get関数を実装するだけ
- 22. スループット: HDD vs. SSD【予備3】(qps)(qps) HDDとSSDで性能の傾向は同じ今後: read/write性能の両立~MyCassandra Cluster~【予備4】 W: 書き込み性能重視
- 23. R: 読み出し性能重視
- 24. RW: メモリベースClientClientProxyProxyWrite ReadRWRWRR W WWW非同期で整合性をチェックRRW RRW２ノードの書き込みACKを確認して成功とみなす整合性をチェックして結果を返す非同期書き込みRRWRRWW WWWRRRWRWdata担当ノードストレージの異なるノードを組み合わせてクラスタを構成異なるストレージノードにレプリカを配置参照は読み出し性能重視 / 更新は書き込み性能重視に同期的にその他のレプリカには非同期でクエリを実行非集中分散の為、互いのストレージ情報を定期的に交換し合う
- 25. MyCassandra Clusterの課題【予備5】レプリカの一貫性Quorum ProtocolW(書き込み合意数) + R(読み出し合意数) > N(全レプリカ数)例: W = R = N/2 + 1これを満たすにはread/write両方を同期的に行うノードが必要=>両方速いメモリベースのストレージエンジンを使う書いてすぐ読むような場合書き込みの全体の整合性がとれず、読み出しは書き込み性能重視の結果待ち=> クライアント側の引数で制御(優先度付きキュー)Network Proximityとの両立読み出し先のプライマリノード選択同一ラック/DC内の書き込み性能重視ノード別ラック/DC内の読み出し性能重視ノードストレージ依存のアクセスによる負荷不均一=>各ホストに異なるストレージのノードを複数配置