Contenu connexe Similaire à Cassandraとh baseの比較して入門するno sql (20) Cassandraとh baseの比較して入門するno sql2. 中の人。
• 本スライド:Ver1.3
• HN : 豊月(Yutuki)
• Twitter : @yutuki_r
• Wiki : http://lunarium.info/arc/
• 今日のハッシュタグ : #casstudy10th
• Google Group : Cassandra勉強会
2
3. 改訂履歴
• 1.1 公開
• 1.2 誤記修正 Chunk→Tablet
• 1.3 内容を追記、修正しました。
– CAP定理が証明論文が公開
– Cassandraを利用したアプリ「PARTAKE」が公開
– Cassandra勉強会グループと日本Cassandraユーザ会が統合
– Cassandra0.7で実装されるのはVersionedClock
– その他、わかりにくい箇所に説明追加等の修正
3
6. NoSQLとは
• Not Only SQLの略称です。
• 意訳:「SQLだけじゃないぜ!」
• 意味1:SQLを利用しないデータベースの事
• 意味2:上記の様なデータベースを積極的に使っていこう
という動き、運動を指す。
6
7. NoSQLはこんなにたくさんあります
BigTable HBase SimpleDB Dynamo
(Google) (Yahoo!) (Amazon) (Amazon)
ROMA Cassandra Kai
CouchDB
(楽天) (FaceBook) (goo)
BerkeleyDB Flare
MongoDB Kumofs
(Oracle) (Gree)
WAS
TokyoTyrant Velocity Voldemort
eXtremeScale
(mixi) (Microsoft) (Linkdin)
(IBM)
7
8. NoSQLの特徴
ノード数に ノード数に
• RDBと比べて利用目的や 素直に比 比例しない
利用範囲を絞っている 例する性能 運用コスト
• RDBが搭載している機能
を省いている
伸縮自在 障害耐性
8
11. DataStore
【FileSystem】
NTFS
ext4
XFS
Database UDF
Google FileSystem
Hadoop Distributed
FileSystem
11
12. DataStore
Database
SQL
【RDB】
Oracle
DB2
MySQL
FS
SQLite
SQL Server
PostgreSQL
JavaDB
12
13. DataStore
Database
【NoSQL】 SQL
KeyValueStore
列指向型 Database
Document Database
RDB FS
13
14. DataStore
Database
NoSQL SQL
【KeyValueStore】
Dynamo
Memcached RDB
Voldemort
FS
【列指向型Database】
BigTable
HBase
Cassandra
14
17. DataStore
Database
NoSQL SQL
KeyValueStore
FileSystem
列指向型
RDB
Database
Document
Dataabse
17
21. Web1.0 と Web2.0
■Web1.0
• 基本的に情報は一方通行
• 通信回数は基本的に一回
• 更新頻度が低い静的HTML
■Web2.0
• 双方向通信
• 複数通信~常時通信 AJAX通信
• コンテンツはDB上、毎度読み出して動的表示
• ユーザ毎に違うページ
21
22. Databaseの進化 (ディスクでの応答からメモリでの応答へ)
Memory (20GB/秒) Disk (0.2GB/秒)
Web1.0 Write
Web1.0 Read
Web2.0 Write
Web2.0 Read Memcached
Cassandra / HBase
Write
非同期書込
Cassandra / HBase
Read
22
24. ブリュワーのCAP定理
とあるシステムでは 可用性
・一貫性
・可用性
・NW分断耐性
ネットワー
の内、二つまでしか 一貫性 ク分断耐
満たす事が出来ない
性
証明された訳ではないので「CAP原則」と呼んだ方が正確ではある
証明された様です→CAP定理の証明論文(PDF)
各種DBの特性を説明するのに非常に役立つ
24
25. CAP定理 一貫性 (Consistency)
• 一貫性がある
– ZEROか100か
– YESかNOか
– 白か黒か
– 生か死か
• 重要なのは、「何も出来ない状態」も一貫性が担保された状態である事
• 中途半端な状態が存在しない
25
26. CAP定理 可用性 (Availability)
• 文字通り、そのサービスが利用出来る事
• そのサービスが動いていた所で利用出来なければ意味がない
• Webで言えば、混雑していてもキチンと応答が返ってくる事
– ■残念な例
– iPhone4発売時のSoftBankとか
– W杯の時のTwitterとか
– ラピュタが放映してる時の2chとか
– ■良い例
– Amazon、Google、Facebookとか
– 新商品発売時のAppleStoreとか
– 最近のmixiとか
– モバゲーとか
26
28. RDBをCAP定理で理解する
• RDBは高い一貫性を最大の特徴とする
– 厳密なトランザクション
• 可用性も基本的に高い
• ネットワーク分断耐性は低い
– 分散化は可能である。しかし技術的に難易度が高い
• 故にスケールアウトよりもスケールアップ
– Exadataの登場等
• ネットワーク分断耐性(P)を犠牲にして一貫性(C)と可用性(A)を
とるCA型
28
29. CAP定理によるデータベースの分類
Oracle Dynamo
MySQL Voldemort
可用性 KAI
PostgreSQL
AsterData TokyoCabinet
Greenplum Cassandra
Vertica SimpleDB
ネットワーク
一貫性
分断耐性 RDB
KVS
列指向
BigTable MongoDB BerkeleyDB ドキュメント
HBase Terrastone Memcached
Hypertable Scalaris Redis
29
34. Amazon Dynamo
• 本業はEコマース
– 大量の商品情報の表示、大量のユーザからのリクエスト
• 殆どのデータや処理が独立している
– 基本的には新規登録、追加のみ
– 購入行為は1ユーザで完結(例外:在庫)
• Web応答速度の遅延は売り上げ低下に直結
– 応答速度が0.1秒遅延すると、1%の売り上げを逃す→blog
• 大量データに対する大量アクセス x ダウンタイムなし
一貫性(C)を犠牲にして、可用性(A)とNW分断耐性(P)を選択
AP型
34
35. NoSQLの系譜(BigTable族、Dynamo族)
Google クローン Amazon
FileSystem Apache S3
Google Hadoop Amazon 派生
MapReduce Dynamo
Google
BigTable 派生 Amazon
SimpleDB
クローン 混合
クローン
Apache Facebook
HBase Cassandra
Linkedin goo
HyperTable
Voldemort Kai
35
37. 基本的な構造
BigTable HBase Cassandra Dynamo
CAP CP CP AP AP
データ
分散方法
シャーディング コンシステントハッシング法
データモデル 列志向 KeyValue
MemTable
ストレージ MySQL
CommitLog / SSTable
37
43. CommitLog / Memtable / SSTable
Memory
MemTable
MemTable
読込はメモリで応答
3.一定サイズに
2.メモリへ展開 なったらDisk保存
SSTable
CommitLog
SSTable
1.まず SSTable
CommitLog Disk
4.Disk保存したら
CommitLog削除
43
44. CommitLog / Memtable / SSTable
【データ復旧時】 Memory
MemTable
MemTable
メモリへ展開
Disk保存されてな
い分を読込
SSTable
CommitLog
SSTable
SSTable
Disk
44
46. HBaseの構成要素
• HBaseMaster (HM)
– リージョンファイルのロードバランシング H
• HRegionServer (RS) M
– リージョンファイルの保持
– 読込書込 RS
RS
• ZooKeeper (ZK) RS RS
– Rootテーブルの位置情報保持
– HBaseMasterの情報保持
• Hadoop Distributed
FileSystem (HDFS)
– 分散ファイルシステム Cli
– ここでデータの複製保存
46
47. root / meta / UserTableの関係
root
meta meta meta meta meta
UT1-a UT2-a UT3-a UT4-a UT5-a
UT1-b UT2-b UT3-b UT4-a
UT4-a
UT1-c UT3-c UT4-a
UT4-a
UT4-a
UT3-d UT4-z
UT3-e
データはシャーディング
して複数ノードで保持
47
48. HBaseの読み出し / 書き込み
Cli ZK
1. ZKからrootテーブル持つノードを知
る
2. rootから目的のmetaテーブルを保
持するノードを知る root RS
3. Metaテーブルから目的のテーブルの
Regionを持つノードをしる
4. 目的のデータの取得する meta RS
・途中で取得した情報はClientがキャッシュ
・この仕組みを利用する事で、ノードがどれだけ
UserTable RS
増加しても同一の手順数でデータ取得が可能
である
48
51. 結果整合性
• 「データが一時的に矛盾した状態になるが、結果的には整合性
の取れたデータになる」
• Cassandraが犠牲にした一貫性を補完する為の技術
– Gossip Protocol
• ノード同士が常に行う状態確認。データの整合性も確認する
– Read Repair
• 読み出したデータが一致しない場合、データを修正する
– Hinted HandOff
• 本来データを保持すべきノードが応答しない時、データを預かる
– Consistency Level(一貫性強度の選択)
• 速度優先か、一貫性優先かを選ぶことが出来る
51
52. 一貫性強度の選択 (複製数3の場合)
B
• 「幾つの複製データに処理を施すか」の選択
Aという値をBに書き換え、読み出す処理の例
B B
A A B
B
Write
B
A A B A B B A B B
Read B
A A B
W:書込数 R:読込数 N:複製数 B B B
W+R>N
の時、「強い一貫性」を得られる B
52
55. 仕様的な差異
HBase Cassandra
SPoF HDFSにあり なし
同一行(同一データ)に
単独ノード 複数ノード
対する読込/書込
ロック単位 Row Column
データ競合解消方法 競合発生なし 時間解決 (Gossip)
データ分散方法 自動分散 手動分散
CAS操作 可能 不可能 (0.7から可能)
データ複製実行層 ディスク層(HDFS) メモリ層
Hop数 1~3 1
55
56. 障害発生時(ノードのダウン)
HBase Cassandra
欠落ノードが持つデータ 自動で別ノードへ 欠落
欠落ノードが持つデータへの 別ノードへのデータ移動 別ノードが受け付け
読込/書込 が終わるまで待たされる データ読込不可の可能性
一貫性強度の低下
残存ノードへの影響 処理能力低下 複製数の減少
データの消失
待たされるがErrorは
ユーザからみた動作 Errorが返ってくる事がある
返ってこない
分断した島の動作 小さい方が自動ダウン それぞれ動作
多重ネットワーク障害 復旧時間の長期化
全体クラッシュの可能性
(後述) データ不整合の可能性
56
57. 復旧作業
HBase Cassandra
追加方法を選択
・同一Tokenで復帰
・新規Tokenで復帰
ノード復旧 ノード追加
・新規ノードとしてToken指定追加
・新規ノードとして新規Tokenで追加
v0.6.8で改善された
57
59. HBaseの多重ネットワーク分断
• HBaseでネットワーク分断が起きると、
ZKが「自分の所属する島が多数側か
少数側か」を判断し、少数側が「自殺」
する事で一貫性の確保を図る RS
RS
• ならばもし短時間に連続して分断が発 RS
RS
生し、多重分断状態に陥り、全員が「
少数側である」と判断をしたら・・・?
RS RS
RS
• root / metaテーブルが壊れる可能性
がある。壊れると全体データに問題が発 RS RS
生する可能性が高まる RS
59
62. 選定基準
結果整合性の
想定データ規模
許容度
Cassandraは予想
HBaseの安定稼働
以上に古いデータを
は5ノード以上?
とってくる
受容して問題ない
Or
0.6.4でかなり改善?
アプリで防げる
62
63. 得意分野(得手不得手であって出来る出来ないではない)
■Webフロント寄り
■トランザクション処理 商品情報
金融分野 可用性 ユーザ情報
在庫管理 権限情報
マスター原本 各種Log
OLTP
ネットワーク
一貫性
分断耐性
■バックエンド / Batch処理
給与計算 会計計算
各種BI Hadoop OLAP
63
67. Powered by & Special Thanks!
• @mayahjp氏
• @ashato氏
• @2t3氏
• 日本Cassandraユーザー会
• Hadoopソースコードリーディング
67