Your SlideShare is downloading. ×
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

1,785

Published on

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

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

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,785
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
18
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. C3-3
    読み出し性能と書き込み性能を選択可能なクラウドストレージ
    中村俊介 首藤一幸
    東京工業大学
  • 2. クラウドストレージ:RDBMSに代わる大規模な分散データストア
    C3-3
    NoSQL, key-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に実装し、実証した
    手法
    分散データストアを分離
    分散の仕組み + ストレージエンジン
    ストレージエンジンを別のものに選択可能に
  • 6. Apache Cassandra
    C3-3
    Facebook, Diggに導入されているクラウドストレージ
    特徴
    単一故障点の無い非集中型分散データストア
    高速な書き込み処理
    複数データセンターにまたがる数百ノードでの動作を想定
    Consistent Hashing(非集中分散アルゴリズム)
    データの主キーHash値により、そのデータの担当ノードが一意に定まる
    全ノードが全部やる
    • Request Proxy
    • 7. DataのPrimary Node
    • 8. 別DataのSecondary Node
  • Google Bigtable由来のストレージエンジン~書き込み~
    C3-3
    永続性を保ちつつ, 書き込み性能を重視
    Bigtable: 行の差分をDiskにはSequential Write
    DiskへのランダムI/Oは発生しないので非常に高速
    Always Writable
    Diskに書かれた内容はWrite-Lockが不要
    Cassandraノード
    Map
    <key,ColumnFamily>
    Memtable
    Memory
    Disk
    write
    SSTable
    CommitLog
    Sequential
  • 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
    1ノードの話で、分散環境を対象としていない
    Cloudy: A Modular Cloud Storage System, VLDB ’10
    実験評価はされていない
    ストレージエンジンを選択可能なデータストア
    RDB: MySQLストレージエンジン
    分散データストア: Amazon Dynamo, SOSP ’07
    全体の性能と永続化の対比はあったが、読み出し vs. 書き込みという観点はなかった
    C3-3
  • 18. Any Questions?
    C3-3
    東京工業大学情報理工学研究科数理・計算科学専攻
    中村俊介
    • モジュラーなクラウドストレージ
    • 19. ワークロードに応じて足回りを変更可能
    • 20. 組合せで両立も可能 (今後・評価済)
  • Cassandra: 遅延の分布
    【予備1】
    writeとreadを同比率のワークロードで100万件測定
    レプリカ数: 3
    データロード数: 2,000万件
    Write vs. Read (YCSB Benchmark)
    Read
    平均6.16ms
    Better
    リクエスト数
    Write
    平均0.69ms
    0
    100
    10
    1000
    Latency (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: メモリベース
    Client
    Client
    Proxy
    Proxy
    Write
    Read
    RW
    RW
    R
    R
    W
    W
    W
    W
    非同期で整合性をチェック
    R
    RW
    R
    RW
    2ノードの書き込み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内の読み出し性能重視ノード
    ストレージ依存のアクセスによる負荷不均一
    =>各ホストに異なるストレージのノードを複数配置

×